40934 - "From" misrepresented as "Sender"

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Ben Bucksch (:BenB)]

In the filters dialog, you can see "Sender" as criteria. Alecf says, it also
appears in the backend.

What does it mean?

If it means "From": There's a semantical difference between "sender" and
"author" and RFC822, Section 4.4.1 and 4.4.2 defines FROM = author and SENDER =
sender (required if sender != author).

Comment 1

[laurel]

Added to summary line.

Comment 2

[scottputterman]

marking M20.

Comment 3

[A. Craig West]

This is a functional difference as well as a semantic difference. I have mailing
list filters that need to filter on the Sender: header, which is somewhat
difficult now. I would prefer if the filters would just use the header name,
instead of a semantic equivalent, as this would prevent this type of ambiguity.
That would make this the 'from' header, which it is...

Comment 4

[timeless]

I was just bitten by this feature (actually I've been bitten for a long time 
but only now realized it).

Filter (or search) for "sender" "blah" failed to match the following message 
header [in nc4.7] 

  From: someone
Sender: blah

I think we should have a testcase for this. [And steps to reproduce]

The final product should have documentation explaining what a sender is and 
what from means. -> justification for slightly wrong keyword.

Adding jglick [please find the tech writer who will document this and ... ; 
thanks]

Comment 5

[Ben Bucksch (:BenB)]

See also bug 47738.

Comment 6

[jglick]

cc'ing Robin Foster from Tech Pubs.

I'm guessing most users assume "From", "Sender", "Author" are the same thing.

Out of curiosity, how would a user end up in a situation where the Sender is X 
but the From is Y?

Comment 7

[Ben Bucksch (:BenB)]

> how would a user end up in a situation where the Sender is X
> but the From is Y?

Not sure what you mean with "end up", but the user is propably more interested
in the author, so we should display that everywhere (like we do now, just that
we call it "Sender", which is confusing (or plainly wrong) in the situation you
describe).

Comment 8

[Ben Bucksch (:BenB)]

> the user is propably more interested in the author

unless (s)he specifically means "Sender", in which case the current naming is
misleading, too.

Comment 9

[robinf]

I've always assumed that the "From" in a message header and the "Sender" in the
message list window/search messages dialog are synonymous. If not, under what 
circumstances would the "From" be different from the "Sender"? One or 
more examples would help me understand what we need to tell users. Thanks.

Comment 10

[timeless]

Attachment: From != Sender. Testcase.

Comment 11

[timeless]

Robin, Good point. We have a problem there too.

Fwiw, NC4.7 shows in the message list pane Sender as "John J. Cruz"
He is the Author, but the Sender according to the attachment [this was a real 
email] is [e-mail]

IMO we need to add another column to the pane list for mozilla1.0 that is 
Sender and rename our 'Sender' to 'Author' (or something to be determined 
here/now).

I'm adding nsbeta3 kw because the most resent portion of this is a very visible 
problem.

OE solves this 'problem' by using "From" which is technically correct. [I don't 
object to that solution].

I don't know if there is ever an 'Author' field (I don't read rfcs unless I 
have to), if there is, then I think we should use 'From' like any well written 
email app.

Comment 12

[Ben Bucksch (:BenB)]

> under what circumstances would the "From" be different from the "Sender"?

1. There is more than one author (yes, this case is specifically mentioned in
RFC822), e.g. "the board of directors". In this case, "Sender" MUST be present
and "indicate who among a group of authors actually sent the message" (4.4.2).

2. A boss dictates his/her secretary an email to send. "From" = boss, "Sender" =
secretary.

3. An auto-generated mail. E.g. "From" = [e-mail], "Sender" =
[e-mail] (the person responsible for the generator).

Note that in timeless' example, as I understood the RFC, it should be
"Resent-Sender", not "Sender".

Comment 13

[Ben Bucksch (:BenB)]

(I just noted that timeless widend the subject of this bug from filters to all
of the UI. This would then be a DUP of (my) bug 47738. I'll leave this bug open,
as it has a better discussion. Taking bug.

Comment 14

[Ben Bucksch (:BenB)]

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

Comment 15

[jglick]

So, an average user is using Netscape 4.x (or Seamonkey).  How would they 
compose a mail message so that the From/Author is X and the Sender is Y?

Comment 16

[Ben Bucksch (:BenB)]

With 4.x or current SeaMonkey: Not at all. (I think, we have an RFE for this.)
But it doesn't matter, because he might get such a msg e.g. from an
autogenerator, mailinglist software (see timeless' example) etc..

Comment 17

[timeless]

<embed content-type=text/tangential>
I think someone mentioned being able to cheat by saving a draft [as a file?], 
and manually altering the file [before reinserting it into drafts?], or maybe 
they hacked the drafts [file] folder. [obviously I don't remember]

I wonder what would happen if a template also had extra fields, would we 
preserve those?
</embed>

Comment 18

[Alec Flett]

"Sender" is supposed to search on all sender-related fields, in a fallback 
mechanism - i.e. if there's no From:, then it will try to match Sender: and so 
forth.
I still maintain that "Sender" is correct, and that it should be Sender and not 
From or Author.

Comment 19

[Alec Flett]

btw, it makes no sense to nominate this for nsbeta3 because ben does not work 
for netscape. nsbeta3 is there to shepard netscape resources

Comment 20

[timeless]

ok, but what about filters?
If I need to filter for Sender (the mail header, not the from line) since there 
is almost always a from sender seems to fail [based on nc4 experience] (I 
haven't tested my message on mozmail but I don't see why it would be any 
different).

Comment 21

[Matthew T (active 1999-2002)]

So this is mainly an issue of how to describe it in the docs, yes? Why not 
something like this ...

----
<p>Sometimes, messages you receive may have <q>From:</q> and <q>Sender:</q> 
headers which are not the same. For example, if a message is dictated by a 
manager to a secretary who then sends it to you, the <q>From:</q> header of the 
message may be the e-mail address of the manager, while the <q>Sender:</q> header 
is the e-mail address of the secretary.</p>

<p>If you reply to a message where the <q>From:</q> and <q>Sender:</q> headers 
are different, your reply will be addressed to the address in the <q>From:</q> 
header, not the address in the <q>Sender:</q> header.</p>
----

I agree with timeless that where you need to use a noun to represent `From' in 
the help, you should use `author' rather than `sender'.

Comment 22

[Alec Flett]

Name me a well-known mail client that lets you do this right now (sending mail 
From: someone else with the correct Sender)

"Sender" is consistent with the behavior of the client right now.
The example that BenB tried to use in IRC: When Steve Case's secretary Ms Smith 
sends out mail that he as composed. For any current e-mail client out there, her 
name will appear in the "From" field, and thus she is also correctly the 
"Sender" of the mail message, not the author. 

If we choose to support the Sender: header while reading mail, which we 
currently do not, then Sender is what will appear in the thread pane.. that was 
the intent from the start, and that is the reason why it is labeled "Sender"

Please do not confuse the issue with unimplemented RFEs like "Ability to edit 
the from header"

I am removing the "correctness" keyword because correctness refers to objective 
behavior of the client - this seems to be a very subjective issue. 

I also do not believe this does not need to be release-noted, because in 
literally millions of corporate installations of Netscape Communicator 4.x 
(where the From vs. Sender issue would seem to be most common), we have NEVER 
recieved a single complaint about this. To the best of my knowledge, BenB, 
timeless, and perhaps mpt are the only people to have ever complained about 
this.

Let this die. I beg of you.

Comment 23

[Ben Bucksch (:BenB)]

> Name me a well-known mail client that lets you do this right now (sending mail
> From: someone else with the correct Sender)

Mozilla *g*: We have an "other header" feature: Add
user_pref("mail.compose.other.header","Sender"); to your prefs, and you should
be able to specify the content of the SENDER header in the addressing widget. It
regressed, but I could get it to work again (will submit patch).

Other mailers, e.g. mutt and I think VM (in Emacs), support this in a similar
way: you can specify arbitary headers during composition or in the "settings"
(preferences) for all or some msgs (selected via rules).

Also, there are still the mail generators (e.g. mailinglist software), which are
especially important in the filters.

> When Steve Case's secretary Ms Smith sends out mail that he as composed. For
> any current e-mail client out there, her name will appear in the "From" field,
> and thus she is also correctly the "Sender" of the mail message, not the
> author.

If she uses Mozilla, she can create a new identity with her boss as From. I
don't know, if Mozilla lets the user specify custom headers in the identity (but
I wouldn't be surprised, if somebody hacked that in), but at least the (IMO more
important) FROM is correct.

Comment 24

[Ben Bucksch (:BenB)]

mass-accept to stop annoying bugzilla spam.

Comment 25

[Michael La Guardia]

Marking nsbeta3- per pdt review.

Comment 26

[A. Craig West]

I definitely favour calling using the name 'From' instead of 'Author', although
I would prefer 'Author' to sender. As far as I have noticed, this is the only
field in which the semantic name differs from the actual header name, and it
wouldn't surprise me to find somebody out there generating mail with an actual
author: header.
It would REALLY help filtering mailing lists to be able to filter on the actual
sender: header, as that is the one header that majordomo sets unambigously in
it's mailing lists. Right now, I improvise by using the 'To or CC' filter, as
that catches most mails, but it can be ambiguous, as those fields are not set by
the mailing list software, but by the author of the mail, and there are lists
which respond to multiple names. I have also had bcc: mail get by the 'To or CC'
filter, but that is fairly rare.
On a related note, I would also like to see the 'other header' option again, as
there are mailing lists which can be unambiguously filtered based on various
x-headers. I consider using the 'other header' set to 'Sender' a rather ugly
kludge, as it results in to distinct fields named Sender in the filter dialog,
which is very ambiguous...

Comment 27

[Ben Bucksch (:BenB)]

dmose: You nominated this bug for mozilla0.9. While I like to see that you also
would like this bug to be fixed, nominating it makes no sense - I am willing to
fix this bug, I am just not allowed to. So, you need to lobby for it at the
approval powers, if you want it to be fixed.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

BenB: you're right; I didn't read closely enough.  It looks to me as though
there are actually two issues here: thread-pane UI and filter UI.  In my mind,
the thread pane UI isn't so critical, because the user is pretty unlikely to
change their action depending on the UI name chosen.  However, in the filter UI,
there is a specific semantic difference in filtering against the Sender header
versus filtering against the From header.  This is what I propose to see fixed
for mozilla0.9.

The reason this is interesting, I think, is not because any end-users ever
compose message with different Sender: headers, but because some popular
mailing-list software packages do this on behalf of the user without their
knowledge, and it turns out that for some of them, filtering on Sender: is the
easiest way to do it.

Comment 29

[laurel]

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

Comment 30

[Ben Bucksch (:BenB)]

Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <[e-mail]>, if you
don't want to work on them.

Comment 31

[A. Craig West]

Is this bug going to be fixed? That still seems to be in some dispute... I know
I want it fixed, so that I can filter my mailing lists properly. As far as I can
tell, the only thing holding up a fix is getting approval from above.

Comment 32

[Håkan Waara]

There's no fix attached to this bug. The attachment above is a testcase.

Comment 33

[Ben Bucksch (:BenB)]

There's no fix, because there's no point producing one unless we have OK to
check it in. If I produced one half a year ago, it would have been bitrotted to
uselessness.

Comment 34

[Christopher Hoess (gone)]

Why are we sending "Sender" at all?  Since "Sender" is supposed to be
authenticated, this seems like the job of the MTA (no matter what you put in
"From", MTA should add your real email address in "Sender").

Comment 35

[Ben Bucksch (:BenB)]

> Why are we sending "Sender" at all?

We don't. Even if we did, it would be irrelevant to this bug. This bug is about
our UI.

Comment 36

[A. Craig West]

This is still affecting my ability to properly filter mailing lists. 

Comment 37

[Bill McGonigle (not currently reading bugmail; please contact directly)]

It's not entirely clear in the above discussion, so for the sake of clarity:

*Many* mailing lists only set the Sender: field as the means of identifying
themselves.  So if a message is BCC'd to a mailing list you'll get:

From: Some Mailing List User <[e-mail]>
To: Bobby <[e-mail]>, Sally <[e-mail]>
Sender: [e-mail]

So the only way to filter this list is to filter on the Sender: field.  You
might try to use the Sender: field in the MailNews filter UI but that wouldn't
work because it tries to match against From: .

There is concern about most users not understanding this.  A nice UI for
comparison is in Apple's Mail.app.  In the field name pop-up you can select
'Expert...' and get a panel where you can specify any header directly.  There's
also a checkbox to keep the new header in the field list for future filters -
otherwise it's ad hoc.

Comment 38

[laurel]

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

Comment 39

[risto.kankkunen]

The wrong terminology is starting to hurt more and more. Now that we have custom
headers implemented and people start to use them (or are urged to use them, see
bug 105715), we have two identical words with two meanings. How is the user
supposed to tell them apart? I'll attach a screen shot to illustrate this. Which
field is the first rule matching?

Since you cannot change the wording of custom headers, I see no other option
than to replace "Sender" with the unambiguos "From". If it were to match both
From and Sender (which it doesn't but which alecf in one comment indicates), it
should be named "From or Sender" like we now have "To or cc" instead of
"Recipients".

"Author" would not be mixed up with Sender, but why make things complicated? All
the other fields already match the unambiguos header names that you see, when
you are composing a message. Shouldn't we try to use uniform terminology?

Comment 40

[risto.kankkunen]

Attachment: Word Sender used in two meanings in search dialog

Comment 41

[laurel]

Well, our "canned" criteria called "Sender" is matching From: -- you can check
that out by viewing the rules.dat.   If you need to match on a custom header
Sender, so be it.  You shouldn't be confused since you added the custom header,
right? (OK, we all have times of short-term memory loss.)  Since custom headers
are an advanced feature, the confusion factor should be minimal until such time
as  the change in basic UI terminology is deemed a priority.

Comment 42

[risto.kankkunen]

Why shouldn't I be confused? In the dropdown, it surely is confusing to see
Sender two times, but knowing all the guts and gory details of Mozilla I can
differentiate between the meanings of the words by their position in the list.

But how am I supposed to see the difference, if I don't pull down the list? In
the screen shot, the first rule used the first Sender, the second rule used the
other. Am I really expected to click all dropdowns in all the rules I have to
see what field I'm matching? Or to look at rules.dat?

Why is it so important to keep using wrong terminology here, and at the same
time keep using different terminology here than in other parts of the client?

Comment 43

[timeless]

At the very least, as an interim measure can we please do what nc4 did and 
lowercase 'sender'?

alternative proposal: 'Sender fields'
reason: we have To or CC which users can easily figure out means it's searching 
through more than one field. when i read attachment 55056 [details] i see 
(Contains Sender '@mozilla) which tells me that i'm checking a single field 
'Sender' for some value.

Comment 44

[timeless]

Attachment: Sender=>sender.

This is 4xp and would prevent the precise picture demonstrated in attachment
55056 [details].

Comment 45

[Andi Voss]

Hi all, whats about this bug?

We have now middle of 2002 and it looks like that this nasty bug is still alive.
I've got a severe complaint today due to this. I checked it on serveral
computers and it is on all the same failure. 

To clarify: this is the partial header of a mail I have in my folder "Inbox".

From - Mon Jul 08 17:34:08 2002
Received: from ... <[e-mail]>; Mon, 8 Jul 2002 17:21:00 +0200 (METDST)
Date: Mon, 08 Jul 2002 17:17:12 +0200
From: Michael R... <[e-mail]>
To: [e-mail]

In the list of my messaages in the folder Inbox I see as sender "[e-mail]"
(its me!) and NOT "Michael R...". As soon I move this message to any other
folder I see as sender "Michael R..." which is correct.

Thanks 

Andy Voss

Comment 46

[Bill McGonigle (not currently reading bugmail; please contact directly)]

This bug is about the filters dialog, not the message summary window.

Comment 47

[Boris 'pi' Piwinger]

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

Comment 48

[Jesse Ruderman]

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

Comment 49

[Stefan Rupp]

This bug is especially annoying when dealing with mailing lists.  I am trying to
move all mails from a certain high-traffic mailing list (gcc-bugs) into a
special folder by filtering for "Sender" == "[e-mail]", but
this does not work, since Mozilla does not look into the "Sender" field (where
the string "[e-mail]" appears), but into the "From" field,
where the Email address of the originating author of the posting appears.

So, it is not easy to filter for mailing-list postings with the current Mozilla
(1.0.2).

Comment 50

[Nicolas Pioch]

Dang, just got biten by this bug, trying to filter LISTSERV's email.

The only thing noticeable (thus "filterable") that LISTSERV inserts in
mailing lists is the
  Sender: GPF Task Force <[e-mail]>
header.

I tried setting up a Mail filter on such a list, used the "Sender" contains...
pre-defined condition, and of course it didn't work... since it doesn't find
the matching text in the From: header, which contains the real sender's
email address instead of the LISTSERV stuff.

Mozilla/1.3: looking in the msgFilterRules.dat file, I find that setting
a Mail Filter condition on "Sender" contains... actually generated this:

condition="OR (from,contains,[e-mail])"

I guess the workaround is to manually edit the msgFilterRules.dat file
to change the above line for:

condition="OR (\"Sender\",contains,[e-mail])"

Comment 51

[Nicolas Pioch]

Uh... no, that manual edit disabled this filter actually.

I'm now getting the following popup trying to activate this rule
in the Mozilla Mail Filter UI:

"This filter was probably created by future version of mozilla/netscape.
You cannot enable this filter because we don't know how to apply it."

(stylistic improvements come to mind for the above sentence, such
as changing "by future" to "by a future" :-)

Comment 52

[Mike Cowperthwaite]

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

Comment 53

[Mike Cowperthwaite]

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

Comment 54

[Mike Cowperthwaite]

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

Comment 55

[Jo Hermans]

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

Comment 56

[Carl Ponder]

I reported a problem w.r.t. Thunderbird as bug #263342, which may be the same as
this. First, the Mail window includes a "Sender" column which ought to be
re-labeled as "Author" or "Source" as is mentioned here. Second, the heuristics
that derive this field from the existing "From" or "Source" fields are pretty
good, in particular the fact that it's smart enough to ignore ""'s around the
name, whereas I always have to write two rules

       From       begins with      Adam Clayton
       From       begins with      "Adam Clayton"

and the first form will incorrectly match other stuff like

       Adam Clayton Powell

whereas

       Source     is        Adam Clayton

would have matched perfectly if this "Source" variable were available for me to
construct rules with.

Some of the other details here sound like flaws in the heuristic, however, so
the derived "Sender" may cause other problems.

Comment 57

[David :Bienvenu]

you need to add a custom header to get the "Sender" header and filter on that.
We put Sender in the filter UI drop down simply because it was felt that was
easier to understand than "From".

Comment 58

[David A. Cobb]

re: comment#57

Urm, yeah.  Knew that, did that.  Works fine.
But this bug says that the decision to call it "sender" has confused more than a
few folk.  

Especially since "From:" is what we see in the header display, I really don't
think anyone would have a problem understanding it.

Comment 59

[Ben Bucksch (:BenB)]

Or you could use "Author". That's semantically equivalent to From per spec, and
just as easy to understand as "Sender" for naive users.

Comment 60

[Aaron W. LaFramboise]

I don't think any of the header match names in the filters dialog should match
the name of any possible header field, unless the rule specified by that name is
identical to the header field name itself.

In other words, "Sender," "Author," and "PersonWhoSentStuff" are all equally
unacceptable, because all of those names might be the name of an actual header
field, yet the actual behavior of the rule would have nothing to do with any of
these fields.

Rationale:
1) Without this restriction, the exact behavior of a rule name is non-obvious,
as you can't tell whether it corresponds to the header field name, or some other
unspecified set of rules.
2) Without this restriction, confusion ensures if you actually ever want to
filter based on the rule name.  You could end up having two apparently identical
names in the rule list that have entirely different semantics, which is
obviously wrong.

My suggestion would be for the names that aren't exactly what they appear to be
(the rule name matches the header field name) the name should include a
character that couldn't possibly be part of a standards-conforming email header
field.  Parenthesis (as "(Sender)") might be a good choice, but spaces (as in
"To or CC") or a colon are other possibilities.

Aaron W. LaFramboise

Comment 61

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Attachment: RFC 2076 E-mail Headers

Can we at least agree not to step on header names specified by e-mail RFC's?

I'm attaching a list of e-mail headers 'in common use' as specified by RFC
2076.  It's a short list.  Anything on it should be considered off-limits for
creating 'helpful labels' - anything not on it should be fair game (excepting
future RFC's).

Additionally, here's a description of when "Sender" must be used, from RFC
2822:

  The originator fields of a message consist of the from field, the
  sender field (when applicable), and optionally the reply-to field.
  The from field consists of the field name "From" and a
  comma-separated list of one or more mailbox specifications.  If the
  from field contains more than one mailbox specification in the
  mailbox-list, then the sender field, containing the field name  
  "Sender" and a single mailbox specification, MUST appear in the 
  message.

And here's an example of another use of Sender:

  If John's secretary Michael actually sent the message, though John
  was the author and replies to this message should go back to him, the
  sender field would be used:

  ----
  From: John Doe <[e-mail]>
  Sender: Michael Jones <[e-mail]>
  To: Mary Smith <[e-mail]>
  Subject: Saying Hello
  Date: Fri, 21 Nov 1997 09:55:06 -0600
  Message-ID: <[e-mail]>

Comment 62

[Aaron W. LaFramboise]

Why is it necessary to enter the header field name namespace at all?  What cost
of using parenthesis might be unacceptabily prohibitive?

If we choose to allow use of names that are possible header field names, we will
create a situation--possibly a rare situation--where both of the two above
problems will manifest themselves.  I consider the above problems, especially
the second one, to be bugs.  I think pretty much any reasonable user would, if
they ran into it.

(Can you imagine having to explain to your staff, during training, that despite
the fact that two list box choices are identical, they do different things? 
What about your technically illiterate parents?)

Do we want to fix these bugs in most cases (by creating certain exclusions), or
in all cases (by prohibiting names from the header name namespace)?

Personally, I think that the above policy could be adopted, "Sender" could be
patched to "(Sender)" (or whatever), this bug could be closed, and we could move
on with our lives.  (For what its worth, while this bug is relatively tame, it
does re-irritate me about once a week.)


Aaron W. LaFramboise

Comment 63

[Braden]

Parentheses or other such decorative punctuation are distracting and obfuscatory
for text rendered as a label in the UI. Aaron, there is no demonstrated need to
solve this *specific* problem for *all* possible cases. For the purpose of this
bug report, Mozilla just needs to stop lying about "Sender". If you really feel
a more general approach is warranted, file a new bug report.

Comment 64

[David :Bienvenu]

Yes, I think just changing the dtd to use Author instead of Sender is what we'll
probably do for this. That's a fairly safe change. Using "From" breaks the way
the search and filters UI reads, e.g., Sender contains "foo" would become From
contains "foo", which isn't very friendly.

Comment 65

[Boris 'pi' Piwinger]

Why is "From contains [e-mail]" unfriendly?

pi

Comment 66

[David :Bienvenu]

It doesn't read well for non-technical users. You and I know it means the "From:
header contains" but as it reads, "From contains foo" is not valid English. From
is not a noun, in other words. But, Outlook does it, so I would consider using From.

Comment 67

[Michael Lefevre]

'"From contains foo" is not valid English'

Well, if you look at it as English, then "Sender contains foo" is also wrong
(unless the app is going to send a robot out to cut open the human that
initiated the message). It should be "Sender's address contains foo". Once you
don't any longer have a sentence that actually makes sense in non-technical
English, I'm not sure whether it reads well or not makes much difference to
understanding.

Comment 68

[Aaron W. LaFramboise]

I don't understand, Braden.  If you change the text "Sender" to "Author,"
then--in your words--isn't Mozilla now lying about "Author"?  Or is the hope
that sufficiently few people will actually care to filter based on a field named
Author?

Comment 69

[Braden]

Aaron: No. "Author" doesn't mean something else in the context of a mail header.
"Sender" does. "Author" is vague for no good reason, but not outright deceptive;
using it instead would be an acceptable fix for this bug. "From" is what it
should correctly be; though there is apparently some neurosis about using it as
an abbreviation for "From field" (even though there is apparently no problem
with omitting "field" everywhere else).

Comment 70

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #66)
>"From contains foo" is not valid English.
David , how about "From: contains foo"?
If ":" is added, I think it can be considered to be abbreviation of "From:
header" in mail related context.
Further, I think user's confusion will be reduced even when "Sender" will be
used in future as generic term for "Any of From: header, Sender: header,
Reply-To: header, Return-Path: header and so on", because user can distinguish
"Sender:" and "Sender".

Comment 71

[David A. Cobb]

David, I don't at all see why "'From' contains 'Foo'" can confuse anyone.  

"From" is a label that clearly appears at the top of the mail window, "contains'
-- well, that's pretty clear.  That leaves 'Foo'.  OK, Foo's are sometimes
confusing, but that isn't a problem we need to solve.

Why not simply the most-obvious solution?  Everyone knows 'From' is a header
field -- because it's one out of the three that sits right in front of you
staring you in the face!

Comment 72

[David :Bienvenu]

We can use From - I said I'd consider it.  We should probably change the thread
column header from "Sender" to "From" as well, while we're at it.

Comment 73

[David A. Cobb]

" We should probably change the thread column header from "Sender" to "From" as
well, while we're at it."

Makes perfectly good sense to me!

Comment 74

[bds]

Probably bad form just to add an extra voice, when all the arguments I would
want to make have already been made, but ... PLEASE fix this bug!

As a recent refugee from MS Outlook, I was appalled when I couldn't filter for
my mailing lists, especially when Outlook actually gets the Sender/From
distinction exactly right. Nor can I currently recommend Thunderbird to all my
list subscribers - how am I to explain how to filter for the list's messages?
(Using 'To:' is not reliable.)

I may be an old pedant, but 'Sender' and 'From' are *different*, and to have
indroduced this confusion in the mistaken belief it 'helps' people is not only
plain wrong, but quite bewildering. If anything, 'From' is the most obvious - to
the untrained, 'Sender' could mean anything: the name of a computer, a company,
a piece of software etc (though of course it has a specific meaning as per the
RFCs), whereas 'From' obviously means the *person* from whom the email as come.
So I strongly agree this should be comprehensively sorted, in both the
thread-pane UI and filter UI.


(In reply to comment #73)
> " We should probably change the thread column header from "Sender" to "From" as
> well, while we're at it."
> 
> Makes perfectly good sense to me!

Comment 75

[M]

(In reply to comment #74)
> PLEASE fix this bug!

Seems to be fixed in the latest nightly build of Thunderbird: version 1.0+
(20050513)

Comment 76

[David A. Cobb]

Re: Comment#75

No, I don't think so.  I'm running "version 1.0.4 (20050515)" and I still have
two 'sender' slots in the message-filter UI.  

I really don't know why this remains stuck!!  Who is the Person-In-Power who
instists it should remain WRONG?  

The quote in comment#61 gives another possibility we can spend two years arguing
about: "The _originator_ fields of the message consist of ...."  Therefore, a
test NAMED "originator" which tested FROM=<target> OR SENDER=<target> OR
Return-Path=<target> would be both lucid and in conformance with the RFC.  

It would also do, in a single step, what I suspect the users most often want to do.

Comment 77

[Grey Nicholson (they/them)]

(In reply to comment #76)
> Re: Comment#75
> 
> No, I don't think so.  I'm running "version 1.0.4 (20050515)" and I still have
> two 'sender' slots in the message-filter UI.

That's because 1.0.x releases come from the aviary-1.0.x branch; try a trunk
nightly (or a 1.1 build when they become available).

Comment 78

[Magnus Melin [:mkmelin]]

This was fixed for thunderbird in bug 221724.

Comment 79

[Cédric "chewey" Menge]

Attachment: cute little patch to replace "Sender" by "From" [checked in on trunk and branches]

Comment 80

[Ian Neal]

Comment on attachment 223235 [details] [diff] [review]
cute little patch to replace "Sender" by "From" [checked in on trunk and branches]


a=me for 1.1a and first a= for 1.0.2/3

Comment 81

[Robert Kaiser]

Comment on attachment 223235 [details] [diff] [review]
cute little patch to replace "Sender" by "From" [checked in on trunk and branches]


a=me for 1.0.3 - 1.0.2 is frozen, and I don't think anyone will let us check into a frozen tree a week before shipping the release if it's no dangerous security bug.

Comment 82

[Karsten Düsterloh]

Comment on attachment 223235 [details] [diff] [review]
cute little patch to replace "Sender" by "From" [checked in on trunk and branches]


Checked in on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH.

Comment 83

[Ben Bucksch (:BenB)]

Thanks for fixing the worst offender in the filter dialog. I had already lost hope for reason long ago.

However, this bug coveres all uses of "Sender" in the UI that are not rating the Sender: header over the From: header. The initial description did refer to fitlers only, but bug 47738 refers to the whole UI and got correctly dupped here. In 2.0alpha1, I still see "Sender" in the threadpane. So, this bug is not fixed yet. Sorry that I have to reopen it and thanks to all who fixed the filters dialog.

For information (probably already discussed above): "Sender" is defined by RFC822 as the Sender: header, if present. If not present (and only then), it can be assumed to be same as the From header.
See http://www.apps.ietf.org/rfc/rfc2822.html#sec-3.6.2

Comment 84

[Magnus Melin [:mkmelin]]

Patch which will fix that (for seamonkey also) awaiting sr in bug 338753.

Comment 85

[Magnus Melin [:mkmelin]]

Bug 338753 has landed, marking fixed.