Open Bug 121214 Opened 23 years ago Updated 2 years ago

Filter mail on existence (presence OR absence) of any header

Categories

(MailNews Core :: Filters, enhancement, P3)

enhancement

Tracking

(Not tracked)

Future

People

(Reporter: johan.walles, Unassigned)

References

Details

Currently I can filter mail depending on the contents of any mail header
(including ones I make up myself).

However, our mail server adds an X-Reject or an X-Warn header to e-mail based on
some spam identification magic.  The contents of the header is an explanation of
why the e-mail has been tagged.

As I don't care why the server thinks stuff is spam, I want a filter that
matches any mail that contains an X-Reject or an X-Warn header, regardless of
its contents.
you can add a custom header for X-Reject, X-Warn.
Since this is possible through use of custom headers, marking this worksforme.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
markking verified worksforme
Status: RESOLVED → VERIFIED
I have added custom headers for X-Reject and X-Warn.  That's why I said
"including ones I make up myself".  I have also failed creating a filter that
matches any mail that has an X-Reject or an X-Warn header.

Matching mail that has an "X-Reject: foo" is not a problem, I can -- and have
done that.  Matching mail that has an "X-Reject" header, regardless of what
comes after the : is what I don't know how to do.

If that is possible, could you please tell me how instead of just claiming that
it works?
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
have you tried one space or null character? But again, we should have another
operator "doesn't matter" or something. 


Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → Future
Well, I was going to suggest a negative criteria operator, such as "isn't" or
"doesn't contain" but I see that has a bug (which was present in 4.x) where it
will come up with matches for items not having the header.

Depending on what the header content (range of values or text reasons) you might
come up with a list of "contains" criteria and OR them in a filter rule...

Sorry about the quick worksforme.  But I'm also afraid the bad news is that
custom headers is low on the priority list and this bug is likely to grow mold
anyway.
I think "Exists" would be a good wording.  Then, using my own filters for this
purpose would use this wording:

X-Warn exists

Laurel: Apology accepted.  And I will use the workaround you suggest.
Here's another way the "Exists" and "Doesn't Exist" technique would be useful.
Some of the spam I get has no "To:" header, I guess its just BCCing a huge list
of unlucky people.  I'd like to filter it to oblivion.
*** Bug 168469 has been marked as a duplicate of this bug. ***
I use Mozilla 1.3
Can you explain me how to do a custom header filter for "String:" ?
I can see only Object, Sender, and Date.
mass re-assign.
Assignee: naving → sspitzer
Status: ASSIGNED → NEW
In reference di #10, I see that after configuring an IMAP server, appear all 8
filters match possibilities. And more Custom...
Maybe is necessary to open a new bug?
Or is a nonsense to do a complex filter without configuring an IMAP server?
I had the same problem, and I tried adding a space. It worked correctly (meaning
every time, probably because the space between ':' and the real description of
the spam. But there was another problem (BUG) that the filter no longer wanted
to apply for new messages. It worked only when applied manually on the inbox. I
use Mozilla 1.3.1 and IMAP server. I solved the problem by putting the filter
"contains 's'" since I saw that every description contained letter 's'. Still
the space bug should be solved I believe. 
I'm surprised this hasn't been mentioned in the bug so far: you can filter on 
the presence of a header by setting up a pair of criteria:
  'Header' 'contains' 'X'
OR
  'Header' 'does not contain' 'X'

However, there is no equivalent means to determine if the header does not exist, 
as described in comment 8.
Summary: Filter mail on existence of any header → Filter mail on existence (presence OR absence) of any header
The workaround described in comment 14 actually doesn't work, because if there 
is no header, "[header] doesn't contain [x]" always evaluates to true.
Product: MailNews → Core
*** Bug 244311 has been marked as a duplicate of this bug. ***
Blocks: 238189
Due to the increasing frequency of fake replies from commercial companies (with subjects prefixed with "Re:") I feel this is an important enhancement, however, to be useful it must cover custom headers or be defined for e.g. In-reply-to.

My goal is to have Thunderbird filter fake-reply spam from companies I have occasional business with.
Assignee: sspitzer → nobody
QA Contact: laurel → filters
*** Bug 335863 has been marked as a duplicate of this bug. ***
How is Bug 335863 a duplicate of this one exactly? I want to search for a BLANK header that EXISTS.
(In reply to comment #19)
> How is Bug 335863 a duplicate of this one exactly? I want to search for a BLANK
> header that EXISTS.
> 
Oops, never mind. I was looking at the filter I still have defined rather than the wording of the original bug. Sorry...
Following on from Bug 375414 discussion:

Adding filter options like "there is no Cc header" shouldn't be necessary. Simpler if filters like <Cc> <is> <blank> match with no CC in the header. Currently it never matches either with or without a Cc, yet <Subject> <is> <blank> matches without a Subject in the header but not with a Subject and that is the correct behaviour in my opinion.

So the overall system is inconsistent at present with different decisions having been made on the handling of <blank> when really it ought to be the same decision. Filters like <Cc> <isn't> <blank> need adjusting too since it always matches, with or without a Cc. <Subject> <isn't> <blank> works ok.

Why add so many more options like "there is no status", "there is no priority", etc, etc, when there are unused degrees of freedom to be had using <blank>.

There ought to be a lot less work involved too since only one bit of main logic that applies to most filters should need updating.
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.