User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Build Identifier: thunderbird 1.5.0.7 (20060909) email headers contain sections like: Received: from recluse.mozilla.org (recluse.mozilla.org [63.245.208.164]) by xxxxx.xxxxx.xxx (Postfix) with ESMTP id xxxxxxxx for <email@address>; Tue, 10 Oct 2006 06:36:20 -0700 (PDT) i'd like to be able to make a rule such as: "received" contains "email@address". but this rule doesn't match, because the section is spread over multiple lines. also a rule like "for" does not work. i can't use the "to" field, because (legit) emails tend to fill in nonsense things in the "to" field, such as the *from* address (which is unpredictable), mailinglist addresses, etc. suggested fix: make a header line/section rule match all lines belonging to the section (in the above example, "received:" would match the above 3 lines) the reason why i'd like this filtering is because i have a catchall and i want to separate the emails sent to a set of aliases from the tons of "i'm out of office" and "your spam was rejected" emails sent to random other aliases. Reproducible: Always Steps to Reproduce: 1. add a message filter, 2. make a custom header field type: "received" 3. add a rule "received" contains (your email address), and an action such as moving to a temporary folder. 4: "run now". Actual Results: it will only move emails which contain your email address on the first line of a "received", which is probably none. Expected Results: it should move all emails with your email address in the receive section, possibly all emails.

*** This bug has been marked as a duplicate of 124641 ***

I'm removing the duplicate notation because the other bug was a more comprehensive bug that has mostly been fixed and hasn't seen a lot of activity. Makes more sense to have an open bug left over for this, at least for visibility.

Note that this bug is fixed for TB 2.0/SM 1.1 and later, see bug 338310 comment 12 (which also fixed almost all of bug 124641, see bug 124641 comment 68).

Duping to the correct bug, which was already fixed at the time this bug was opened :(