377926 - Filter on Received header working only partially

Status: RESOLVED DUPLICATE of bug 184490

(Thunderbird :: General, defect)

Description

[hartman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 1.5.0.10 (20070221)

Filtering against the Received hedaer works against incoming mail, however it does not work when attempting to apply against the current folder.

For example, by examining headers I find that nothing but spam comes from the IP group 216.66.53.*, so I create a filter that searches for "216.66.53." in the Receive header (action mark as junk, delete).  New mail coming with a matching IP in the Received header does get trashed, but I can not use the filter to clean out the mail from that IP that is already in my inbox.

I am using an IMAP host, not POP3.


Reproducible: Always

Steps to Reproduce:
Received header is not standard, you must create one.  (this needs to be done only once)
1. Open filters dialog.  Create new filter. 
2. First column drop-down, select "Customize" to get "Customize headers" dialog.
3. type "Received" and hit "Add"
4. Now you can select "Received" for the first drop-down.  Leave "contains" in the second.
5. In the final edit field put an IP address to match against.  Since wildcards do not work, I used "216.66.53." so as to match all mail coming from any IP in that group.
6. Action 1: set Junk status to Junk
7. Action 2: Delete Message


Actual Results:  
Any new messages coming from the matching IP group will be found in the trash folder, marked as junk.

If, however, you select the filter and press "Run Now", you get either a timeout error, or "Invalid key supplied in the SEARCH command".

Expected Results:  
cleaning out (deleting) the other spam from that IP group

Spammers regularly change subject lines and return addresses.  The source IP address is one of the most reliable methods of filtering spam.  This really should be possible.

Comment 1

[WADA:World Anti-bad-Duping Agency]

> If, however, you select the filter and press "Run Now", you get either a
> timeout error, or "Invalid key supplied in the SEARCH command".

Get NSPR log for IMAP and attach log file to this bug thru "Add an attachment" link (mime-type="text/plain" if file size is accepted).
See next sites for NSPR log.
  http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
  http://www.mozilla.org/projects/netlib/http/http-debugging.html
"SET NSPR_LOG_MODULES=imap:5,nsSocketTransport:5" is recommended because "timeout error" is also involved in your case. 

Comment 2

[Magnus Melin [:mkmelin]]

This is already tracked in bug 184490.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> *** This bug has been marked as a duplicate of bug 184490 ***

To Magnus Melin ：

Because summary says "Received: header" and "partial" and IMAP, bug 184490 is suspectable (problem when multi-line header, still has problem when IMAP).
But this bug' case is filter on "IP address" in from part of Received: header, and the IP address is usually placed in first line.
(Q1) When bug 184490, problem occurs even for first line data?

This bug says "timeout error" or error of "Invalid key supplied in the SEARCH command" occurred when "Run Now" (not written in summary).
(Q2) These phenomenon are really being tracked by bug 184490?

Comment 4

[WADA:World Anti-bad-Duping Agency]

Bug 338310 and Bug 124641 are also for filtering issue when multi-line(folded) message header.

To hartman (bug opener) :
Does your problem has relation to bug 184490, Bug 338310 or Bug 124641?
See mail source thru View/Message Source(CTRL+U). Which case is your problem?

Comment 5

[hartman]

Bug 124641 is concerned with failing to handle multi-line headers.  This is not my issue (single-line Received headers fail when filter applied after-the-fact).

Bug 338310 seems to apply to incoming messages, not merely after-the-fact applications.  I have no problems w/ incoming messages.

184490 sounds similar to my problem, except using "User-agent" header instead of "Received".  Both are "custom headers" (i.e. not included as a standard header w/ Thunderbird as distributed).  As far as I can tell, 184490 does not mention multi-line issues.  It also talks about the filters not working for views, which is also the case with me.  My issue may very well be a duplicate of 184490.

Do you guys still need the NPSR logs, or are there already some filed with 1844890?

Comment 6

[WADA:World Anti-bad-Duping Agency]

> 184490 sounds similar to my problem, except using "User-agent" header instead
> of "Received".

Magnus Melin was absolutely right for problem described in summary.
Please watch bug 184490.   

> Do you guys still need the NPSR logs
My concern is "timeout error"/"Invalid key supplied in the SEARCH command".
If "Invalid key supplied in the SEARCH command" is always or many times issued when peoblem of bug summary, I recommend you to get NSPR log and attach log file to bug 184490, because I think your case is a good case for problem analysis.
If your "timeout error"/"Invalid key supplied in the SEARCH command" are independent from problem of this bug's summary, and if these are problem for you, get NSPR log and open new bug if required for you.

Comment 7

[WADA:World Anti-bad-Duping Agency]

> "Invalid key supplied in the SEARCH command"
Maybe similar issue to Bug 344290 because it's fixed by patch for Bug 79767.  
> Bug 79767 – IMAP SEARCH commands include HEADER unnecessarily
If "Invalid key supplied in the SEARCH command" is always displayed in your case while filtering, DUPing to Bug 344290 may be better.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to comment #3)
> (Q1) When bug 184490, problem occurs even for first line data?

Yes, I think i used bugmail headers to test that one.