GNOME Bugzilla – Bug 469007
Specific header|* filter never fires
Last modified: 2007-09-07 08:22:23 UTC
Please describe the problem: My filter rule: Specific header "X-UKC-SpamCheck" starts with "spam" is not firing. Simple actions like colouring are not performed, and nothing is printed to the filter log when running under /apps/evolution/mail/filters/log TRUE, even with manual filtering, although other filters with different conditions print there fine. Steps to reproduce: 1. Create a rule to filter on a specific header 2. Execute it on a mail Actual results: Nothing Expected results: Filter instructions to be followed. Does this happen every time? Virtually. I've only seen it not-occur once, but it has occurred every time since. Other information: Screenshot and mail source to follow.
Created attachment 94077 [details] Problematic rule See also bug 379308 - 'forking' this due to the specifics I've found beyond that bug. Return-path: <urfriendamit2004@spss.com> Received: from xxx ([129.12.21.35]) by xxx (Sun Java System Messaging Server 6.2-9.02 (built Apr 20 2007)) with ESMTP id <0JN500KN93PAQ9B0@xxx> for xxx; Tue, 21 Aug 2007 21:03:11 +0100 (BST) Received: from [89.31.90.31] (helo=mksng) by xxx with smtp (Exim 4.63) (envelope-from <urfriendamit2004@spss.com>) id 1INZvy-0000kZ-If for xxx; Tue, 21 Aug 2007 21:02:38 +0100 Received: from arbjgeon by mksng with local (Exim 4.62 (FreeBSD)) id 1IOkwT-0005AU-7E for xxx; Wed, 22 Aug 2007 00:02:22 +0400 Date: Wed, 22 Aug 2007 00:02:22 +0400 From: Mobile Fun <urfriendamit2004@spss.com> Subject: User Verification Sender: User arbjgeon <arbjgeon@mksng.xxx> To: ojc4@xxx Message-id: <1IOkwT-0005AU-7E@mksng> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: spam, SpamAssassin (not cached, score=8.543, required 5, autolearn=disabled, DNS_FROM_RFC_ABUSE 0.48, NORMAL_HTTP_TO_IP 0.00, RCVD_IN_BL_SPAMCOP_NET 2.00, RCVD_IN_NJABL_DUL 1.71, RCVD_IN_SORBS_WEB 1.24, RCVD_IN_XBL 3.11) X-UKC-SpamScore: ssssssss X-UKC-MailScanner-From: urfriendamit2004@spss.com Original-recipient: rfc822;ojc4@xxx X-Evolution-Source: imap://ojc4@imap.xxx/ Mime-Version: 1.0 Greetings, Welcome To Mobile Fun. Account Number: 516912817137 Temp Login ID: user8255 Temp Password ID: cf742 For security purposes please login and change the temporary Login ID and Password. Follow this Link: http://201.235.120.192/ Thank You, New Member Services Mobile Fun
^^ that's about IMAP. i could not reproduce this here with local folders
Probably you are not fetching that Header. Goto Edit->Preferences-><IMAP-Account>->edit-button Then go to IMAP Headers tab and add your header as the custom header and try again. It will work. Reopen if it is not working even tehn, You might need a restart.
I tried adding X-UKC-SpamCheck to the custom headers - no effect. NB, manual running of the filters doesn't work either, even after I've viewed the source on the mail and seen the full headers.
Seeing some additional filter weirdness - see bug 469251.
Has there been any development on this bug? It's basically making Evolution unusable for me :(
Hello Oliver, based on observation of http://tools.ietf.org/html/rfc822 , chapter 3.1.2, the problem here is a space right after a ':' after header name. The RFC says that the header body starts immediately after the ':', and when you compare on "start with", then you compare these two values: a) " spam, SpamAssassin (not cac..." (read from the message) b) "spam" (you entered in a rule) and so a) didn't start with b) :) You can either persuade developers to add here an improvement to ignore first space at the header body or add a space at the beginning of your rule text. I hope that helps. (Feel free to close the bug, because I think the devs will not be happy to do such change, even the mail you provided here shows that all header body starts with a space.)
Aha, we thought of trying with a space in the filter, but discarded it as pointless :) The 'workaround' works great, thanks. I agree, the RFC says the value starts immediately after the ':'. However, Evolution isn't really following the Robustness principle here - I can't find a single email in my inbox that doesn't have whitespace between the ':' and the 'value'. In fact, Evolution itself generates mails with spaces between the ':' and the 'value'. Literally, in an outgoing mail: Reply-To: user@isp.com Evolution is stating that my reply-to address is " user@isp.com". If other clients rigidly followed the RFC, they would reject that address when their user hit Reply. It wouldn't be a great stretch for Evolution to be more flexible regarding leading space characters in the header value. This could be a rule applied to every header, or it could do a quick analysis of the mail to see whether the majority are: Header:value or Header: value.
I've come to the conclusion that [Starts With] and any other string comparison filter needs to ignore all leading lwsp characters in the actual raw header (unless, perhaps, leading lwsp appears in the match text?) I kinda feel like a God here, declaring my decree. "Thou shalt ignore leading lwsp. And bring me a shrubbery!" Anyways, I think this will make everyone happy.
Created attachment 94849 [details] [review] proposed eds patch for evolution-data-server; The funny part of this bug is that the code for removing starting white-space(s) was already there, only didn't work properly. Notice also compiler warnings like this: warning: passing argument 1 of 'camel_utf8_getc' from incompatible pointer type The attached patch fixes this warning and causes the code to work again. To Oliver: Please remove from your rule that preceding space in a value for header, it was only a workaround.
The solution makes sene. Sankar, can you review this with high priority?
I tested this patch and it works fine. However, in my 32-bit machine without this patch also the space-stripping is working fine. Please commit it.
On similar lines, I will say : camel_ustrcasecmp should be accepting a unsigned char as the argument.
Committed to trunk. Committed revision 8042.