250187 - Reply all automatically converts multiple TO recipients to CC (should preserve original destination fields)

Status: RESOLVED FIXED

(MailNews Core :: Composition, enhancement)

Description

[Ian King]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Thunderbird version 0.7 (20040616)

When I recieve a message in which I am one of multiple recipients in the TO
field, if I hit "Reply All" the original sender will be set as a TO recipient
while the rest are made CC recipients.  If I recieve a message where everyone is
in the TO field and hit "Reply All", all recipients should still be in the TO
field and not converted to CC.  Each recipient other than the original sender
must be then set back to TO by hand.  In messages with a large list of
recipients this is a pain!

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Ben]

Mozilla's behaviour is the suggested (but not imposed) one as stated in RFC2822,
section 3.6.3. "Destination address fields":

«If a reply is sent to a message that has destination fields, it is often
desirable to send a copy of the reply to all of the recipients of the message,
in addition to the author.  When such a reply is formed, addresses in the "To:"
and   "Cc:" fields of the original message MAY appear in the "Cc:" field of the
reply, since these are normally secondary recipients of the reply.»

Comment 2

[Werner]

same on windows XP (using Thunderbird version 1.0)

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 6

[Tao Peng]

People report this bug repeatly. Do not the developers think this necessary?

Comment 7

[Magnus Melin [:mkmelin]]

Confirming RFE.

Comment 8

[Simon Sheppard]

I can confirm this still happens on thunderbird (OS X)

It may not conflict with RFC2822 but it conflicts with every other email client I've ever used. I think people would appreciate at least having an option to get some better behaviour. 
Do Mozilla really expect people to copy and paste EVERY email address every time they do a Reply All?

maybe this should be a feature request rather than a bug?

Comment 10

[rsx11m]

Note that bug 484212 states the following (valid) use case:

> I'm part of a large group of people that brainstorms via email. Many people in
> this list receive dozens of e-mails a day and filter them based on if we're
> listed as a To: recipient or a CC: recipient. Since CC is assumed to be a less
> direct communication, they are given a lower priority and may be overlooked by
> the recipient.
> 
> I would like to be able to set an option where Reply To All keeps the original
> recipient delivery structure (i.e. whoever was 'To:' remains 'To:' and whoever
> was a 'CC:', 'BCC;', etc remains so in the Reply To All).

Comment 11

[gweedoh]

Confirming that to date this "bug" still exists and has not yet been addressed with version updates.

Comment 12

[Dingding]

require this feature too, especially in a discussion thread with multiple participants. the rfc does not have to be conformed to necessarily.

Comment 13

[Bob]

I am also struggling with this problem, as everyday, I have to reply to dozens of emails, where people do not open an email unless their name is in the To: field.

This is a very important option to have despite what the RFC said. We should at least have an option. Either a static configuration or per message, I don't mind either. I will always set it contrary to what the RFC says: keep the current To: list as someone took care to address a group of people, and they need to continue to be addressed!

Btw, I have googled and searched mozilla for this issue for weeks, until I finally found this bug today. That maybe a reason why this bug is not getting attention; it is not easy to get the search for the right token or words as they are all common.

Comment 14

[Frank Farance]

I am having a related problem, see bug 759018.  The problem is that Reply-All doesn't include the sender in the To:/Cc: line, so I don't get a copy of the message.  The Eudora behavior got this right:

(1) first, the person you are responding to (From:, not Sender:) is added to the To: list (at that point it only has one address, the original From:) ... this step needs to be first so when viewing the Sent folder ordered by Recipient, it makes sense; second, all the To: recipients would be added to the To: for all the people on the To: line in the original E-mail; third, all the people on the Cc: line in the original E-mail would get added to the Cc: line

(2) if I were on the original Cc: list, I would get added as the last entry on the Cc: line, otherwise I would get added on the last entry on the To: line (which covers both To: and Bcc:); see bug 759018

There should be two options available in the Tools-> Options-> Composition GUI (so non-technical people can set this): a checkbox "preserve To:/Cc: on Reply-All", and a checkbox "include me on Reply-All".

As for the comments on RFC 2822, it says: 

        When a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" field) or mailboxes specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" field of the reply since these would normally be the primary recipients of the reply.  If a reply is sent to a message that has destination fields, it is often desirable to send a copy of the reply to all of the recipients of the message, in addition to the author.

I note that RFC 2822 makes the semantic distinction between To: (primary recipient) and Cc: (other recipient) and Thunderbird should preserve this distinction (i.e., the Eudora behavior).  Changing people to Cc: demotes their status to a non-primary recipient.

Right now, *every* E-mail I must correct *every* envelope.

Comment 15

[Magnus Melin [:mkmelin]]

Just to be clear, the RFC says what we do now is a MAY.
E.g. Outlook does perserve the To/Cc semantics.

Comment 16

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

This preserves the To/Cc semantics, and adds tests for our various reply modes.
(no whitspace patch to come)

Comment 17

[Magnus Melin [:mkmelin]]

Attachment: proposed fix (no whitespace changes)

Comment 18

[Blake Winton (:bwinton) (:☕️)]

Hey Magnus, sadly the patches you attached seem to have bitrotted.  Would you mind attaching new versions?

Thanks,
Blake.

Comment 19

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v2 - unbitrotted

Unbitrotted. (No new no-wwhitespace patch, the bitrot was very minor).

Comment 20

[Blake Winton (:bwinton) (:☕️)]

The new patch didn't build for me.  :(
Errors at http://pastebin.mozilla.org/1874844

Comment 21

[Magnus Melin [:mkmelin]]

Comment on attachment 673962 [details] [diff] [review]
proposed fix, v2 - unbitrotted

Review of attachment 673962 [details] [diff] [review]:
-----------------------------------------------------------------

I had an external api build, an apparently there's a trap hidden :/ - http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/glue/nsStringAPI.h#1455

sed -i 's/nsCAutoString/nsAutoCString/g' on the patch file should probably help, i'll attach that once i have the time to test it.

Comment 22

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v3 - unbitrotted

s/nsCAutoString/nsAutoCString/

Comment 23

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 674278 [details] [diff] [review]
proposed fix, v3 - unbitrotted

Okay, having played with the behaviour, I think this makes sense, since we aren't losing the original distinction between To-ed and Cc-ed addresses.  So ui-r=me.

>+++ b/mailnews/compose/src/nsMsgCompose.cpp
>@@ -2009,137 +2009,16 @@ nsresult nsMsgCompose::CreateMessage(con
>+      // Remove my address from Reply fields.
>+      nsCAutoString resultStr;

This needed to be switched to "nsAutoCString" before it would build for me, as you mentioned in your comment.

Thanks,
Blake.

Comment 24

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 674278 [details] [diff] [review]
proposed fix, v3 - unbitrotted

Review of attachment 674278 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry it's taken me so long to get to this. :/

Mostly, this looks good. I don't think I'm qualified to give a thorough review of nsMsgCompose.cpp (you might want to talk to rkent or irving about that), but I can tell you that nsMsgCompose.cpp does not compile for me with this patch. I get this:

/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp: In member function ‘virtual nsresult QuotingOutputStreamListener::OnStopRequest(nsIRequest*, nsISupports*, nsresult)’:
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2798:7: error: ‘nsCAutoString’ was not declared in this scope
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2798:21: error: expected ‘;’ before ‘resultStr’
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2811:51: error: ‘resultStr’ was not declared in this scope
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2816:49: error: ‘resultStr’ was not declared in this scope
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2859:58: error: ‘resultStr’ was not declared in this scope
/media/Projects/mozilla/thunderbird/mailnews/compose/src/nsMsgCompose.cpp:2867:67: error: ‘resultStr’ was not declared in this scope
make[3]: *** [nsMsgCompose.o] Error 1
make[3]: Leaving directory `/media/Projects/mozilla/objdir-thunderbird-patches/mailnews/compose/src'
make[2]: *** [src_libs] Error 2
make[2]: Leaving directory `/media/Projects/mozilla/objdir-thunderbird-patches/mailnews/compose'
make[1]: *** [compose_libs] Error 2
make[1]: Leaving directory `/media/Projects/mozilla/objdir-thunderbird-patches/mailnews'
make: *** [default] Error 2

My other comments are style - but I'm mostly happy with this.

Thanks,

-Mike

::: mail/test/mozmill/composition/test-reply-addresses.js
@@ +21,5 @@
> +
> +const myEmail1 = "[e-mail]";
> +const myEmail2 = "[e-mail]";
> +
> +Components.utils.import("resource:///modules/mailServices.js");

You should be able to use Cu instead of Components.utils from within a Mozmill test - I believe you inherit that alias.

@@ +80,5 @@
> +
> +    for (let i = 0; i < expected.length; i++) {
> +      if (!obtained || obtained.indexOf(expected[i]) == -1) {
> +        throw new Error(expected[i] + " is not in " + type + " fields; " +
> +                        "obtained=" + JSON.stringify(obtained));

If obtained is an Array, you don't need to stringify it. the toString of the Array will do this for you.

@@ +85,5 @@
> +      }
> +    }
> +    assert_equals(obtained.length, expected.length,
> +                  "Unexpected number of fields obtained for type=" + type +
> +                  "; obtained=" + JSON.stringify(obtained) + 

As above, you shouldn't need JSON.stringify. Same below for expected. Also, nit - trailing whitespace

@@ +94,5 @@
> +  for (let type in obtainedFields) {
> +    let expected = expectedFields[type];
> +    let obtained = obtainedFields[type];
> +    if (!expected) {
> +      throw new Error("Didn't expect a field for type=" + type + 

nit - trailing white space, and JSON stringify again.

@@ +100,5 @@
> +    }
> +  }
> +}
> +
> +/** Tests that a normal reply is ok. */

Nit - our tests generally have headers like:

/**
 * Tests that a normal reply is ok.
 */

Also, the comment is a little vague. What does it mean to be "ok"?

Comment 25

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v4

Gah, i'd forgot to actually attach the version with nsAutoCString switched.

Fixed an issue with replying to .eml files.
Addressing mconleys review comments, carrying forward ui-r=bwintin, sr=standard8

Irving, can you have a look at the nsMsgCompose.cpp changes, as mconley feels he's not qualified?

Comment 26

[:Irving Reid (No longer working on Firefox)]

Comment on attachment 672446 [details] [diff] [review]
proposed fix (no whitespace changes)

Review of attachment 672446 [details] [diff] [review]:
-----------------------------------------------------------------

Leaving this as r? until we decide what to do about the early exits from QuotingOutputStreamListener().

::: mailnews/compose/src/nsMsgCompose.cpp
@@ +2437,5 @@
>      NS_ENSURE_SUCCESS(rv, rv);
>    }
>  
> +  nsCOMPtr<nsIMsgCompose> compose = do_QueryReferent(mWeakComposeObj, &rv);
> +  NS_ENSURE_SUCCESS(rv, rv);

QueryReferent() *should* never return NS_OK and a null pointer, but it might be worth keeping the null check here - something like NS_ENSURE_TRUE(compose, NS_ERROR_NULL_POINTER)

@@ +2538,5 @@
> +
> +      nsCString  ccEmailAddresses;
> +      rv = parser->ExtractHeaderAddressMailboxes(NS_ConvertUTF16toUTF8(cc),
> +                                                 ccEmailAddresses);
> +      NS_ENSURE_SUCCESS(rv,rv);

I'm concerned with all the places we exit early from this function - I'm not sure under which conditions ExtractHeaderAddressMailboxes() could fail, so I can't tell for sure whether this means someone could send a message with a malformed To: or CC: header such that Thunderbird was unable to reply, because it makes us fail out of this method. Can you convince me that these early returns are safe?

@@ +2548,5 @@
> +                         &replyToSelfCheckAll);
> +
> +      nsCString originalMsgURI;
> +      compose->GetOriginalMsgURI(getter_Copies(originalMsgURI));
> +      

Trailing white space

@@ +2549,5 @@
> +
> +      nsCString originalMsgURI;
> +      compose->GetOriginalMsgURI(getter_Copies(originalMsgURI));
> +      
> +      nsCOMPtr <nsIMsgDBHdr> msgHdr; 

White space

@@ +2701,5 @@
>          {
>            // handle Mail-Followup-To (http://cr.yp.to/proto/replyto.html)
> +
> +          compFields->SetTo(mailFollowupTo);
> +          compFields->SetCc(EmptyString()); 

Trailing white space

@@ +2805,5 @@
>            mIdentity->GetEmail(email);
> +        // We need to remove dups for the Reply fields.
> +
> +        // If it's a reply to self, self should not be removed. 
> +        // 

Trailing white space (two lines)

Comment 27

[Magnus Melin [:mkmelin]]

(In reply to Irving Reid (:irving) from comment #26)
> QueryReferent() *should* never return NS_OK and a null pointer, but it might
> be worth keeping the null check here - something like
> NS_ENSURE_TRUE(compose, NS_ERROR_NULL_POINTER)

Do you want that in addition, or just instead of the ensure success?

> @@ +2538,5 @@
> > +
> > +      nsCString  ccEmailAddresses;
> > +      rv = parser->ExtractHeaderAddressMailboxes(NS_ConvertUTF16toUTF8(cc),
> > +                                                 ccEmailAddresses);
> > +      NS_ENSURE_SUCCESS(rv,rv);
> 
> I'm concerned with all the places we exit early from this function - I'm not
> sure under which conditions ExtractHeaderAddressMailboxes() could fail, so I
> can't tell for sure whether this means someone could send a message with a
> malformed To: or CC: header such that Thunderbird was unable to reply,
> because it makes us fail out of this method. Can you convince me that these
> early returns are safe?

ExtractHeaderAddressMailboxes only returns an error for NS_ERROR_OUT_OF_MEMORY - and it's also moved code so i think it's safe.
http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/nsMsgHeaderParser.cpp#1097

Comment 28

[:Irving Reid (No longer working on Firefox)]

Comment on attachment 681622 [details] [diff] [review]
proposed fix, v4

Review of attachment 681622 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Magnus Melin from comment #27)
> (In reply to Irving Reid (:irving) from comment #26)
> > QueryReferent() *should* never return NS_OK and a null pointer, but it might
> > be worth keeping the null check here - something like
> > NS_ENSURE_TRUE(compose, NS_ERROR_NULL_POINTER)
> 
> Do you want that in addition, or just instead of the ensure success?

In addition. It's a bit paranoid to do both, but rkent recently fixed a few other crash bugs where NS_OK came with a null pointer...

> 
> ExtractHeaderAddressMailboxes only returns an error for
> NS_ERROR_OUT_OF_MEMORY - and it's also moved code so i think it's safe.
> http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/
> nsMsgHeaderParser.cpp#1097

OK, r=me after you add the one extra null pointer check.

Comment 29

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v5

For posterity.

Made the NS_ENSURE_TRUE(compose, NS_ERROR_NULL_POINTER); change and used the non-rv version of do_QueryReferent. No point checking rv if we don't trust it.

Comment 30

[Magnus Melin [:mkmelin]]

https://hg.mozilla.org/comm-central/rev/931f0547903c -> FIXED

Comment 31

[Juan Pablo]

Hi Magnus,

I've been a Thunderbird user for years and really liked the way "Reply All" used to work up until last week when it was changed.  I think that when you receive an email having you and other people in the TO field the reply should be addressed ONLY TO the sender and CC'ed to the others just like TB would do in all its previous versions.

I really dislike this behavior in Outlook for instance but at least in Outlook you can easily select the whole string of addresses and cut it out of TO and paste it into CC.  However, with TB this is hard to do because the addresses are one by line so changing TO to CC must be done in a per address basis which can be pretty time consuming.

I agree with the RFC2822 cited above.  I find that normally when replying to an email I'm normally addressing the sender and not directly the other people the sender put in the TO field.  Of course the others should be aware of my response, which is why they should be in the CC field, but in most cases I'm replying TO the sender and not TO every person.  So, these days after the change I find that more than 90% of the time I want to switch people to CC or I just don't bother with it but just keep repeating the name of the person I'm writing *TO* to make clear I'm talking to that person and not necessarily to every one who is in the TO field.

Anyway, please make this configurable in the config editor or somewhere if you can.  I don't mind if the old behavior is no longer the default one, but it should be available for those who prefer it.

Thank you,
Juan Pablo.

Comment 32

[rsx11m]

Juan, this bug is closed. Please file a new one with reference to this bug, requesting a configuration option.

Comment 33

[rsx11m]

Comment #31 was filed as bug 933472.

Comment 34

[Kevin Buhr]

On a related noted, I'd like Thunderbird to automatically translate all quoted messages to German.  Could we silently make this major change to functionality with limited user input and then demand that anyone who complains file a "feature request" to make it a configuration option?

Seriously, in the future, could reviewers of patches that are likely to impact long-time users' email workflow think about REQUIRING a configuration option (at least an about:config option) before introducing such a change.  I mean, I'm glad that people who can't get their coworkers attention now have yet another tool besides putting the subject in all-caps, marking everything they write as high priority, and texting people to ask if they got the phone message that let them know they received an email, but some of us were happy with the old behavior.

Changing status to RESOLVED NOWBROKEN.

Comment 35

[Juan Pablo]

Kevin,

That's exactly what I've noticed.  I use TB for my work emails and in most cases people just put everybody in TO because they don't bother checking who the actual recipient should be and then when you reply it seems you're addressing everybody when you actually intend to address just the sender.

By the way, I still see the status of this topic as RESOLVED FIXED.  Thanks.

Comment 36

[rsx11m]

Looking at the history of this bug report, note that the title at the time when it was confirmed was "Reply all automatically converts multiple TO recipients to CC (option to preserve original destination fields)" with the apparent intention to add such a configuration option. That last part was later changed to "(should preserve original destination fields)" after comment #25, unfortunately without any reason given.

Anyway, while I agree with the sentiment of comment #34, making it configurable is now bug 933472. Thus, please comment there.

Comment 37

[Filip Konvička]

I agree totally with comment #31.

Please show your appreaciation for long time users and make sure not to introduce such breaking changes without adding a configuration option at the same time.

Comment 38

[Bob]

I am sorry, but I disagree with #31 and that RFC. I do see that there are different types of user preferences, so maybe a configurable, or on the fly choice should be added ( "reply all cc ing to" vs reply all keeping current structure, with better wording).

In some settings, where people get a lot of emails, and only tend to read the emails addressed to them, and when the initiator intends to ask someone to address and read the thread, that person should stay in the to list throughout the thread, especially if he answered at one point. Some threads run 10s and hundreds of emails, and some get revived months later. So when I  get cced on these emails when I expect to be in the to list, I tend to miss on important emails.

Comment 39

[Tony Mechelynck [:tonymec]]

(In reply to Bob from comment #38)
> I am sorry, but I disagree with #31 and that RFC. I do see that there are
> different types of user preferences, so maybe a configurable, or on the fly
> choice should be added ( "reply all cc ing to" vs reply all keeping current
> structure, with better wording).
> 
> In some settings, where people get a lot of emails, and only tend to read
> the emails addressed to them, and when the initiator intends to ask someone
> to address and read the thread, that person should stay in the to list
> throughout the thread, especially if he answered at one point. Some threads
> run 10s and hundreds of emails, and some get revived months later. So when I
> get cced on these emails when I expect to be in the to list, I tend to miss
> on important emails.

If you never read anything where you're "only" on the CC list, then you _will_ miss important emais no matter what. OTOH spam emails will usually be addressed "To" you and by the same logic you'll read them instead of trashing them.

The latest RFC on any given subject is supposed to be the standard. As long as it is, that's what we ought to implement. We may extend it but not run straight against it.
If we're convinced that the RFC is deficient, we should work toward having it amended by a newer and better RFC.

Comment 40

[rsx11m]

http://tools.ietf.org/html/rfc5322#section-3.6.3 represents the current version as RFC2822 was obsoleted by RFC5322. As such, it reads

   When such a reply is formed, addresses in the "To:" and "Cc:" fields
   of the original message MAY appear in the "Cc:" field of the reply,
   since these are normally secondary recipients of the reply.

in the context of "it is often desirable to send a copy of the reply to all of the recipients of the message, in addition to the author." Thus, the spirit of that paragraph preferring "Cc" for any additional recipient other than the author(s) seems to be violated by what was implemented here; but on the other hand, it was carefully enough phrased (MAY vs. SHOULD or MUST) to leave it up to the e-mail client what to implement.

Having said that, and supporting an on-the-fly option myself, this bug is closed and further discussion here not necessarily useful. Bug 933472 - Provide a configuration option to allow "Reply All" behavior of moving "To" recipients to "Cc" field again - was filed for the purpose to introduce such an option, thus please continue there.

Comment 41

[Takaaki Higuchi]

I also prefer the sender is only in TO, and others in CC.

By the way, as a temporary workaround, I found a plug-in to change all TO to CC. I am using this to set all to CC, and select one to TO by hand now. It seems the web message is in Japanese, but the plug-in itself supports en locale.
https://addons.mozilla.org/ja/thunderbird/addon/all-to-cc-bcc/reviews/

Comment 42

[Markus Kuhn]

I strongly vote for reverting this "fix" for what clearly was a non-bug. Thunderbird was perfectly fine before this patch. If you want to emulate Outlook's very annoying, undesirable and anti-RFC behaviour of putting anyone other than the sender of the message to which a message replies into the To: field, than that behaviour should be an extension, configuration option, or even a new "Reply-to-all-as-To" button. But by default, Thunderbird should really follow the very well-established and time-honoured behaviour recommended by the RFCs.

The semantics of being in the To: field of a reply is that this is a reply to *my* message. Gmail does the same, every Unix mailer I have ever used does the same.

The right thing to do is to reopen this bug, remove the patch, and close as WONTFIX. The behaviour desired by Ian King can then be added as an option or extension or alternative reply button.

Comment 43

[rsx11m]

Well, that won't happen. If you care to read the previous comments here, they contain references to open bugs on that matter and a workaround (which I agree is not a solution, especially as apparently only the Japanese locale is supported).

Comment 44

[Frank Farance]

It's been over a decade since I switched to TB from Eudora and EVERY OUTGOING MESSAGE HAS TO BE FIXED. Yeah, EVERY EVERY EVERY message. I gave suggestions on how to fix this, so did others. See comment above: https://bugzilla.mozilla.org/show_bug.cgi?id=250187#c14

Why can't someone fix this problem?

-FF