221724 - Thunderbird filter on "sender" actually filters on "from"

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Tom Porterfield]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

Here is relevant info from e-mail header:

From: "Bill Sanderson" <[e-mail]>
Sender: [e-mail]

Create a filter where "Sender" is "[e-mail] move to Folder.

Apply the filter and the message is not moved.

Change the filter where "Sender" is "[e-mail]" move to Folder.

Apply the filter and the message is moved.  The filter uses the word Sender but
actually filters on the From message header.  I need a filter on the Sender
header.  Having the ability to filter on either makes the most sense, but the
current filter should at least be more descriptive in what it is actually
filtering on.

Reproducible: Always

Steps to Reproduce:
See Details
Actual Results:  
No message was moved.

Expected Results:  
Message should be moved based on Sender header for Sender filter.  Add
additional filter to move message based on From header.

Comment 1

[Matt Mower]

I can confirm that filtering on Sender does not work as expected. 

Comment 2

[Braden]

One can, at least, add "Sender" as a custom header. But this creates a 
confusing UI, since default and custom headers are listed together.

"Sender" is a less common header than "From" (which is ubiquitous), so "From" 
is probably what most people want. So the fix to this is easy: just relabel 
the default "Sender" selection to "From".

Comment 3

[D R Evans]

The fix suggested by #2 is not really a fix. It is more of a feature change
("Filter on From:" instead of "Filter on Sender:").

I am in the same position as the original poster: I need to filter on the
Sender: header. One should be able to filter on either From: or Sender:.

In addition, I found that the suggestion by #2 does not work. Creating a custom
"Sender" header and switching the filter so that it filters on the custom
"Sender" instead of the pre-defined "Sender" still does not cause filtering to
occur on that header (at least, it doesn't in tbird 0.5).

Comment 4

[jwq]

Thunderbird Version 0.6 (20040502; Mac OS 10.2.8

I see this bug and agree with Braden (comment #2) that fix is simply
to change the name of this menu item from "Sender" to "From".

Re: Comment #3: I have had no problems adding a filter for the Sender: 
header. Works like a treat for me.

Comment 5

[jwq]

Note: Bug 40934 identifies the same problem in MailNews.

Comment 6

[Lorenzo Colitti]

*** Bug 217673 has been marked as a duplicate of this bug. ***

Comment 7

[Robert Harvey]

Well, this explains why I can't filter out a particular noxious troll from
various usenet groups

Comment 8

[Mike Cowperthwaite]

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

Comment 9

[Braden]

Reopening. Bug 40934 is against MailNews, not Thunderbird.

Comment 10

[Braden]

*** Bug 263342 has been marked as a duplicate of this bug. ***

Comment 11

[J. Raines]

I have duplicated this bug in a WinXP system using Thunderbird.  The solution of
adding a custom field for "sender" works for me.  It works this way in both the
current release and the nightly build.

However, it is noted that the current set-up of Thunderbird is illogical.  Since
the fields "from" and "sender" are distinct in the header, it doesn't make any
sense to label a pre-defined filter choice as "Sender" when it really is
filtering on the "from" field in the header.  Certainly, as Firefox is
approaching the critical time in the market where it has a real chance to be
established as a market leader, this type of sloppy programming error should be
given a high priority.  Especially when the person most likely to be looking for
that level of precision in their filter is most likely to be a tech savey person
who will either become a Thunderbird advocate or detractor that others will
follow.  Therefore, I think this change is a "fix" and not a "feature change".

Changing the drop down choice label to "from" which the matches the field being
filter seems like a logical and relatively simple fix, since, as noted in
earlier postings on this bug, that is what most users are expecting anyway. 
Certainly the unsophisticated will not have a problem with this change.

I believe whatever change in priority that is needed should be made on this bug
so that it is fixed before the next release of Thunderbird.

Comment 12

[Mike Cowperthwaite]

See also bug 221054, which suggests changing the header display to show the 
Sender information when the header is present.

Comment 13

[Mike Cowperthwaite]

*** Bug 288179 has been marked as a duplicate of this bug. ***

Comment 14

[David :Bienvenu]

Attachment: change Sender to From

Comment 15

[chris hofmann]

Comment on attachment 182224 [details] [diff] [review]
change Sender to From

a=chofmann

Comment 16

[David :Bienvenu]

fixed on trunk, so fix will be in 1.1

Comment 17

[Tom Metro]

Renaming the filter label seems like the best short term fix.

However, before closing this out, consider...

When I first saw "Sender" in the list of filters, knowing it isn't a common
RFC822 header, and with the absence of a "From" option, I had assumed it was a
pseudo header, much like "To or cc" or "Age In Days" are. I presumed there would
be some logic to apply the rule against several headers that indicate the
message author/sender. Apparently others were thinking along the same lines:

Bug #40934 Comment #18 describes a possible order in which headers would be
searched. Bug #263342 comment #2 mentions how the message browser UI applies
such rules for determining the contents of the Sender column, and thinks they
should similarly apply to filters. Bug #167295 is entirely about this issue, but
is incorrectly marked as a dupe of Bug #40934.

Bug #221054 Comment #4 raises a related issue of an authenticated sender.
Perhaps not an immediate concern, but when/if such authentication becomes
common, it would be as relevant to filter rules as to the data displayed in the UI.

I also had hopes of it being a pseudo header as there currently isn't a way to
filter on the contents of the mbox "From " message separator line (for which I
filed bug #292967), because it technically isn't a header, but may carry the
same information (more reliably) as found in a "Sender:" or "Return-Path:" header.

Finally I'd like to reiterate what was said in Bug #40934 Comment #60, which is
essentially that the "pseudo headers" ought to be visually distinguished from
the filters (custom or built-in) that correspond with literal headers. Though
this probably should be in its own bug report as it is only tangentially related.