User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 My bug search found lots of requests to prevent HTML display of *incoming* mail (and I'd like that too), but this is the opposite: If I reply to a message that came in HTML, I can't find any way to avoid replying in HTML. I want a preference option that says "never, ever, under any circumstances, use HTML in my outgoing mail!" Reproducible: Always Steps to Reproduce: 1. Have someone send you mail with HTML. 2. Try to reply. 3. Actual Results: Your reply will be in HTML format. Expected Results: It should have sent the reply in good old ASCII. As a side note, the display of my message as I'm composing it has the cursor in the wrong place, with an ever-increasing amount of space between the end of the text and the cursor. I'm guessing this is because you're using the same font that the incoming message used, which isn't the fixed-width font my preferences say to use.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060316 Firefox/1.6a1 This is a clear usability issue. Out of the box MAS should default to sending ASCII mail. If someone wants to send HTML mail then that person could go to the Preferences and select ()Always or ()In reply to HTML mail. I would guess that for historical reasons the latter option was considered somehow more friendly. What does Thunderbird do?

sounds reasonable to me

I don't know by heart what Brian's Mozilla 1.7.10 does, but I'm pretty sure the behaviour is very much the same as in my SM 1.0.4 (in fact, I believe the behaviour hasn't changed significantly for years): MailNews main window, Edit->Mail&News Account Settings, choose the account you're using for replying, choose the pref panel Composition&Addressing, remove the checkmark from "compose as HTML". This turns on the plain text editor. If you want to still use the HTML editor but send as plain text only, open the regular preferences (Edit->Preferences), choose Mail&News->Send Format and check [x] convert to plain text. So, this is bug is WFM, right?

(In reply to comment #3) > So, this is bug is WFM, right? I'd say more WontFix than WFM. There are several steps to the process. Brian is apparently complaining about the "out of the box" setup, which defaults to HTML compose. He also says: > Actual Results: > Your reply will be in HTML format. > > Expected Results: > It should have sent the reply in good old ASCII. The first is, I presume, complaining about the compose window being HTML; the second, if he checks the Sent folder, probably actually did occur (or would have): unless he used formatting in the HTML compose window, or specifically listed the recipient in the Address Book and designated him/her as "Prefers HTML," the message should have gone out as plain text, without even prompting. The 'Send Options' actually only applies to those HTML-composed messages (1) sent to unknown-preference recipients, and (2) which contain enough formatting to trigger the 'Send Options' questions. As for clearing the Compose As HTML flag: That needs to be done for each new account, I think (also for any identities that might have been created for the account before the setting is turned off on the primary identity). Bug 115439 addresses the best solution to that "out-of-the-box" aspect, one that I think is very reasonable but has yet to be implemented. We could argue for years on the default -- in fact, we have; I think the pro-HTML forces at this point outnumber the rest of us. Even with that set: Edit As New on an HTML message will compose as HTML -- and someday, I hope, so will Forward Inline (there should at least be the option to follow the original message's format on Forward Inline). There are arguments both for and against composing in HTML with the intent of sending in plain, having to do with various bugs in the two composer windows. HTML compose allows you to save and reopen a draft without losing the ability to reflow lines as you edit a previously-entered paragraph, but then sends out plain text mail as "format=flowed" without properly implementing the RFC. (There's an old, old bug for each of those cases, which I'm too lazy to look up at the moment.)

> We could argue for years on the default -- in fact, we have; true enough :( > I think the pro-HTML forces at this point outnumber the rest of us. I'm not sure the current balance of preference is easy to ball park : - people have been saying for years it's inevitable that everyone will want or just live with html - the balance may have changed after many moved to FF+TB. However, I think a more important point is "choice", which has been a hallmark of suite. Shouldn't plain text / html be one of those great choices offered and indeed facilitated? (marketing point for suite) see also bug 288209 (TB equivalent to Bug 115439), bug 140800