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)
MailNews Core
Filters
Tracking
(Not tracked)
NEW
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.
Comment 1•23 years ago
|
||
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
Reporter | ||
Comment 4•23 years ago
|
||
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 → ---
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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.
Comment 9•22 years ago
|
||
*** Bug 168469 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
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.
Comment 12•21 years ago
|
||
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?
Comment 13•21 years ago
|
||
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.
Comment 14•20 years ago
|
||
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
Comment 15•20 years ago
|
||
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.
Updated•20 years ago
|
Product: MailNews → Core
Comment 16•19 years ago
|
||
*** Bug 244311 has been marked as a duplicate of this bug. ***
Comment 17•18 years ago
|
||
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.
Updated•18 years ago
|
Assignee: sspitzer → nobody
QA Contact: laurel → filters
Comment 18•18 years ago
|
||
*** Bug 335863 has been marked as a duplicate of this bug. ***
Comment 19•18 years ago
|
||
How is Bug 335863 a duplicate of this one exactly? I want to search for a BLANK header that EXISTS.
Comment 20•18 years ago
|
||
(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...
Comment 22•17 years ago
|
||
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.
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•