Closed Bug 40934 Opened 21 years ago Closed 14 years ago
"From" misrepresented as "Sender"
3.57 KB, text/email
23.23 KB, image/jpeg
428 bytes, patch
|Details | Diff | Splinter Review|
621 bytes, text/plain
624 bytes, patch
|Details | Diff | Splinter Review|
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).
Added to summary line.
QA Contact: lchiang → laurel
Summary: Sender? → Sender? (message filters)
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...
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]
See also bug 47738.
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?
> 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).
> the user is propably more interested in the author unless (s)he specifically means "Sender", in which case the current naming is misleading, too.
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.
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 owner-um-linux@Glue.umd.edu 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.
> 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" = firstname.lastname@example.org, "Sender" = email@example.com (the person responsible for the generator). Note that in timeless' example, as I understood the RFC, it should be "Resent-Sender", not "Sender".
(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.
Assignee: alecf → mozilla
Component: Filters → Mail Window Front End
Summary: We misrepresent From as Sender. (message filters/search mesages, thread pane) → "From" misrepresented as "Sender"
Target Milestone: M20 → M18
*** Bug 47738 has been marked as a duplicate of this bug. ***
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?
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..
<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>
"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.
btw, it makes no sense to nominate this for nsbeta3 because ben does not work for netscape. nsbeta3 is there to shepard netscape resources
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).
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'.
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.
> 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.
mass-accept to stop annoying bugzilla spam.
Status: NEW → ASSIGNED
Marking nsbeta3- per pdt review.
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...
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.
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.
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
*** Bug 63076 has been marked as a duplicate of this bug. ***
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 <firstname.lastname@example.org>, if you don't want to work on them.
Assignee: mozilla → sspitzer
Status: ASSIGNED → NEW
QA Contact: laurel → esther
Whiteboard: [nsbeta3-] relnote-user → relnote-user
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.
There's no fix attached to this bug. The attachment above is a testcase.
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.
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").
> 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.
This is still affecting my ability to properly filter mailing lists.
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 <email@example.com> To: Bobby <firstname.lastname@example.org>, Sally <email@example.com> Sender: firstname.lastname@example.org 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.
*** Bug 105715 has been marked as a duplicate of this bug. ***
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?
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.
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?
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.
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 ... <email@example.com>; Mon, 8 Jul 2002 17:21:00 +0200 (METDST) Date: Mon, 08 Jul 2002 17:17:12 +0200 From: Michael R... <r....@gsf.de> To: firstname.lastname@example.org In the list of my messaages in the folder Inbox I see as sender "email@example.com" (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
This bug is about the filters dialog, not the message summary window.
*** Bug 167295 has been marked as a duplicate of this bug. ***
*** Bug 191256 has been marked as a duplicate of this bug. ***
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" == "firstname.lastname@example.org", but this does not work, since Mozilla does not look into the "Sender" field (where the string "email@example.com" 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).
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 <GPF_TASKFORCE@LISTSERV.COMPANY.COM> 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,GPF_TASKFORCE@LISTSERV.COMPANY.COM)" I guess the workaround is to manually edit the msgFilterRules.dat file to change the above line for: condition="OR (\"Sender\",contains,GPF_TASKFORCE@LISTSERV.COMPANY.COM)"
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" :-)
*** Bug 201285 has been marked as a duplicate of this bug. ***
*** Bug 258208 has been marked as a duplicate of this bug. ***
*** Bug 221724 has been marked as a duplicate of this bug. ***
*** Bug 261904 has been marked as a duplicate of this bug. ***
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.
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".
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.
Or you could use "Author". That's semantically equivalent to From per spec, and just as easy to understand as "Sender" for naive users.
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
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 <firstname.lastname@example.org> Sender: Michael Jones <email@example.com> To: Mary Smith <firstname.lastname@example.org> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <email@example.com>
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
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.
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.
Why is "From contains firstname.lastname@example.org" unfriendly? pi
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.
'"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.
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?
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).
(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".
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!
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.
" 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!
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!
(In reply to comment #74) > PLEASE fix this bug! Seems to be fixed in the latest nightly build of Thunderbird: version 1.0+ (20050513)
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.
(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).
This was fixed for thunderbird in bug 221724.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #223235 - Attachment description: cute little patch to replace "Sender" by "From" → cute little patch to replace "Sender" by "From" [checked in on trunk]
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
Attachment #223235 - Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
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 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.
Attachment #223235 - Attachment description: cute little patch to replace "Sender" by "From" [checked in on trunk] → cute little patch to replace "Sender" by "From" [checked in on trunk and branches]
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Patch which will fix that (for seamonkey also) awaiting sr in bug 338753.
Bug 338753 has landed, marking fixed.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.