User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20060426 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124) Gecko/20060426 Firefox/126.96.36.199 Attempting to use filter to auto-file messages based on 'for email@example.com' portion of Received: header because I get kids email also and sometimes messages are addressed to all three of us. Unfortunately, my tests all have failed. This could be due to multiple instances of Received: in a message and program is taking last field as final result. Better solution might be or'ing the results of repeat fields if this is indeed the problem or including an "multiples: and/or" option for each rule. Reproducible: Always Steps to Reproduce: 1.Enter filter to match known 'for firstname.lastname@example.org' phrase in a Received: field and set to move message to another folder 2.Select "Run selected filter(s) on that folder 3.Click Run Now. Message won't move. Actual Results: Nothing Expected Results: Message should have moved
Are you sure it's not because we don't look at the second line of the Received: header if it contains multiple lines, as opposed to not paying attention to any but the last Received: header? The code looks to me like it looks at all of the headers, but only at the first line of each header.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 222702 [details] [diff] [review] handle continued headers
Attachment #222702 - Flags: superreview?(mscott)
oops, pressed return too quickly - this patch makes us check if a line is a continuation of the current header, in which case we should still look at it...not sure if this is what the reporter was seeing, but it's obviously broken (and perhaps a dup...)
Attachment #222702 - Flags: superreview?(mscott) → superreview+
fixed on trunk - will let bake for a little bit.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 222702 [details] [diff] [review] handle continued headers plussing for branch - will checkin later.
Attachment #222702 - Flags: approval-branch-1.8.1+
Dupe of bug 124641, no?
ah, yes, it is - and that points out that I should really have coalesced the lines into one big line for the purpose of matching (though the checked-in behaviour is a lot better than what we were doing before). Maybe best to leave this fixed, and leave bug 124641 open for handling searches where the search string spans lines. I'll go update that bug with a comment.
I can confirm that David's fix works for Search Messages. With filters, it's not so simple. Testing with TB 1.5 and the filter IF X-Spam-Status, contains, "autolearn" THEN Mark Message Flagged this works on messages where "autolearn" is in the folded part of the header. However, something else has changed. One thing not mentioned in this bug or in bug 124641, which confused me for a minute while testing, is that MailViews (at least since TB 1.5) have been able to search across folded headers, even when Search Messages would not. But now, a view based on a custom header (e.g., Content-Type or X-Spam-Status) doesn't work at all -- even if the searched-for test appears in the first line of the header. TB 3a1-0529, Win2K Do you want me to open a new bug on that, David? See also bug 209488 comment 4.
sure, open a bug on the view issue - is that a regression, or an existing problem? It sounds familiar. I don't know why mailviews would have been able to handle multi-line headers - they all go through the same code.
(In reply to comment #9) > sure, open a bug on the view issue Bug 339985 > is that a regression, or an existing problem? regression > I don't know why mailviews would have been able to > handle multi-line headers - they all go through the same code. Well, I sure don't know.
(In reply to comment #8) > With filters, it's not so simple. Testing with TB 1.5 and the filter > IF X-Spam-Status, contains, "autolearn" THEN Mark Message Flagged > this works on messages where "autolearn" is in the folded part of the header. What I missed here is that the report is about after-the-fact ("Run Now") filtering on any given folder, rather than operating on arriving messages. This indeed was not working before, but is working on 3a1-0529.
Status: RESOLVED → VERIFIED
Summary: Message Filter not Working on Received: Header → Message Filter "Run Now" not Working on (folded) Received: Header
fixed for 2.0, along with Bug 339985
Component: General → MailNews: Backend
OS: Windows 2000 → All
Product: Thunderbird → Core
QA Contact: general → backend
Hardware: PC → All
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.