If I just write text and I don't apply any format (font, size, italic, bloc...) the message is sent in plain text. The config is set as follows: - Mozilla->Prefences->Mail & Newsgroups->Send Format->Send the message in HTML anyway. // Both domain lists are blank. - Mail & News->Account Settings->Account Name->Compose messages in HTML format - Compose->Options->Format->Auto-Detect Build: 2002061104 (Mozilla 1.1 Alpha, fresh install)

Confirming with 2002071208/win2k, pref set to "send HTML anyway", although not sure if it is really a bug. We automatically convert to plain text, if there's no special formatting in the message. Ducarroz, what do you say on that?

To me, "send in HTML format anyways" means that the messages allways will be sent in HTML. Maybe that "auto-conversion" to plain text is there isn't any formating should be an option? Anyway, I think this situation can be very confussing for some users. And, the problem I have with this is when I write text in russian (cyrilic), the message is sent plain text without detecting the correct charset. As consequence, neither reciever's mail client, neither Mail & News are capable of interpreting the resulting message. [I'm using Mozilla in English and Windows in Spanish]. Here's and example of the king of "uninterpretable" message: From - Thu Jul 11 23:10:41 2002 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <3D2DF450.7080004@domain.com> Date: Thu, 11 Jul 2002 23:10:40 +0200 From: "troodon@domain.com" <troodon@domain.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: recipient@domain.com Subject: test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ????, ?????, ???? ??? ???????????????????????????????????????????????? ??? ?????? ??? These "?" characters where cyrilic characters. If this message is sent in HTML, all is fine (charset, format). Maybe this is just a charset-related bug?

I forgot to add that I have the same problem if I include in the message romanian-specific characters. And yes, it dispays the message saying the message cointains characters not found in the selected charset, but shouldn't auto-detect Mail & News the correct charset in plain text messages, like it does in HTML messages? Anyway, all those charset-related problems wouldn't appear if all messages would be sent in HTML formal.

Even when "send the message in both plain text and html" is selected, Mozilla (now I'm using build 2002101708) only sends plain text if there isn't any formating in the message.

Troodon: in 1.3 Final, sending unformatted HTML mail as HTML ONLY or BOTH does in fact send it as directed; so I'm marking this message WorksForMe. I don't know much about how alternate encodings. If I paste Unicode characters in from the Character Map, then click Send, Mozilla prompts me to change the message coding; if I select UTF-8 and send it, the mail comes across as desired. If you set the message's encoding via the menu, can't you use plain text and get the results you want?

Please see comment #3 . I'm using 1.4b and it still sends messages in text format by default. That isn't the behavior I expect. I want it to send messages in HTML format always, without having to select Compose->Options->Format->HTML only, because I already selected Prefences->Mail & Newsgroups->Send Format->Send the message in HTML anyway.

Mike, Troodon is right. The behaviour hasn't change since when this bug was filed. See comment #2. With the additional note that "send HTML anyway" in Preferences doesn't change the behaviour. A text without formatting is always sent as Plain Text. Re-opening and marking as new. I might be wrong but I think there is some inconsistency here.

OK, I misread something; I thought the issue was that even the override (compose window, Options|Format) wasn't working, and it is. I noticed a comment at some point while reading bugs this weekend that the conversion of unformatted HTML to plaintext was a deliberate design decision. Troodon wrote: > it dispays the message saying the message cointains characters not found > in the selected charset, but shouldn't auto-detect Mail & News the correct > charset in plain text messages, like it does in HTML messages? My understanding is that warning appears when Unicode characters requiring two or more bytes have been entered into a message encoded with a single-byte charset. If you select a default message encoding of Unicode/UTF-8, you won't get that problem, and still be able to send iso-8859-1 messages. The HTML messages I tried sending with Unicode characters converted them all to entities -- such as &#260; -- so there is really no auto-detection of the charset being used here. On the other hand, if you want to use an alternate 8-bit encoding, it doesn't seem that much to ask that you change the encoding of the message (say, to KOI8-R) before composing. But I don't know how to compose mail in that mode.

Thanks for the character suggestions, I'll try them. Anyway, the main problem is with the sending format settings not working as expected. If it's a designs decision, at least, the captions of the compose in HTML options should be changed (I'm speapking about the preferences dialog).

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

Reproduced on 1.4b RC2 Fully agreed with comment #7 Actually it works when doing "Compose->Options->Format->Rich Text (Html) only" But it seems that there is no room in Preferences to set this properly to a default behaviour different from "Auto-detect" Is it ? And setting this manually for each message is really a pain, especially when settings seem to promise the opposite (there is no value in preferences to set "Auto-detect" actually)

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

I've done some testing with this using 1.4 (regarding bug 187064). If no formatting is used during HTML composition *and* recipient's preference is unspecified, preference is ignored and message is sent plain; but if the recipient is specified as "prefers HTML," that's what gets sent. I'm not sure if that's how it was working in 1.3. Nearly any use of formatting will result in HTML being sent (unless the preference or recipient's preference is against that).

After #13 comments: first, thanks for reminding us about this setting in the address book However, I would consider that this is part of the old times specifics that are now pretty obsolete. Couldn't we have a less conservative behavior, where HTML messages are sent in plain text only, only when all recipient have an explicit preference for plain text ?? Or, even more radically different: always send in the format selected in "Preferences / Mail & Newsgroups / send Format" Actually, there are also HTML/plain text preferences per domain in these settings. How do they interfere ? How do they combine with user level preferences ? This looks to offer a huge complexity, creating a lot of opportunity for bugs, with really few benefits !?

This is a truly annoying bug for users of Hebrew and Arabic, as even setting a different formatting (dir="rtl" for the body of the email) isn't enough, and the mail gets sent as plain text. As a workaround, I italicize a single space. This forces Mozilla to send the mail as HTML. Prog.

I discovered a bit of a workaround for this issue: if you change the default colors for HTML composition from black-on-white, that will count as an "HTML element" and the mail will not be downconverted to plain text -- unless the recipient is listed in the address book as Prefers Plain. If all recipients are listed as Prefers HTML, with an unknown preference, or unlisted, the mail will go out as HTML. This is true with 1.5 Final and 1.6b; I don't know about earlier versions. I also read on a newsgroup that, even if the default colors are used, if the message is saved to the Drafts folder and then reloaded, or created from an HTML template, then the message is sent as HTML (except to Prefers Plain recipients). One problem is that if only one recipient of several is listed as Prefers Plain, the message is still downconverted. This is properly part of bug 187064, since that conversion occurs even with substantial HTML content (such as an inline image).

I recall seeing the same problem on Mac and Linux. Please change Hardware and OS to All. Prog.

The same problem is apparent on my system. 2 different profiles. The setting to send email in HTML format does not hold (save) under "Send Format" preferences regardless of what is selected (HTML). If I select and change it it seems to accept the change and when you begin to compose a message it appears to format/write in HTML, but then sends in text and strips the HTML of any images, colors, font styles, etc. To work around this I have to first go to the options > format menu where it indicates "auto detect" as the default then have to select HTML/RTF each time a message is sent. No specific recipient's preferences are specified. FYI: The prefs.js file seems correct respective to the preference selected. Is there a permanent workaround for this? or can the compose menu Option > Format selection be saved somehow so it defaults to HTML/RTF? Driving me Batty!!! Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

As I have written in comment 17, this bug is not Windows-specific. Marking as such. Prog.

> One problem is that if only one recipient of several is listed as Prefers Plain, > the message is still downconverted. No other way. If you set "prefers plain", that tells us that this recipient can't receicve HTML mail, so we *must* send plaintext to him. We can't send plaintext to *him only*, because only one mail for all recipients is sent to the SMTP server. As to this bug: It's a very concious decision to send plaintext only for msgs without formatting, but I don't know, if there was a concious decision about this particular combination (HTML preference, no formatting). One case is when users want to send HTML when needed (when they used formatting), without being asked every time, but still want to (or should) send plaintext in case where it's not needed (no formatting). This use case would break when fixing this bug. OTOH, I wasn't aware of the problems Hebrew users are facing (in fact, left-to-right-support didn't exist back then), so this may be an argument. The russion characters are no argument in my view, set the charset correctly (or better yet file a bug why it wasn't set correctly automatically).

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

> "Send Format" preferences > sends in text and strips the HTML of any images, colors, font styles, etc. Not what I see. If I select HTML in prefs, the msg gets sent as HTML, if there is formatting. If there is none, it's sent as plaintext. That is with a recipient with unknown format preference in the address book. (Be sure to read the Source of the sent mail, not just look at the display.)

About the bidi issue: shouldn't the dir="rtl" BODY attribute count as formatting? I don't see a separate bug on this.

Correction to comment 23: this was filed and resolved (bug 228720).

(In reply to comment #20) > OTOH, I wasn't aware of the problems Hebrew users are facing (in fact, > left-to-right-support didn't exist back then), so this may be an argument. The > russion characters are no argument in my view, set the charset correctly (or > better yet file a bug why it wasn't set correctly automatically). You're right, they aren't an argument and using UTF-8, as suggested in comment #8 , that is solved. But that situation uncovered the MAIN point of this bug: an option doesn't work as one would expect from its name and description. Also, there is a really chaotic situation with the send format options, as there are many options distibuted across many different places/menus, which may lead some users to confusion.

> there is a really chaotic situation with the send format options, as there are > many options distibuted across many different places/menus, which may lead some > users to confusion. Undoubtly

Guys - the "if Seamonkey doesn't see any reason to use HTML, convert to Plain Text despite user's preference (or lack of preference)" is one of those nice, well-meant "the tool knows best" optimizations that causes endless nightmares because it is unanticipated behavior. It really shouldn't be the default, and I'm guessing that removing this check should be a fairly easy and benign thing to do. (Easy, because you just have to make the "can I convert to plain text?" check always fail, and benign, as no one who sets the preference (or has no preference) -expects- the message to go as plain text (no preference = no expectations)). So why not just remove the "can I convert this to plain text anyway" check for now. Later, you could add an option to the Send Format options. /j