User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5 Steps to reproduce: In our organisation we have about 50 Thunderbird users and 400 Zarafa users. We use Thunderbird mainly for the Laptop users. We also have Altermime running in combination with Postfix to add a HTML disclaimer to the email if that email is send from certain domains. This work perfectly with Zarafa, but with Thunderbird we have some issues with it. i've tested several combination to get it working, but it seems TB is cocky In the setting in Thunderbird, I've set the parameter: "Send the messages in both plain text and HTML" When I do not add the recipients domain in the tab "HTML domains" (so leave it empty), the following happens. Sending an email from TB to one email-address -> No HTML disclaimer is added (twiiter, facebook icons etc) Adding one domain to the "HTML domains" tab, say xyz.com: Sending an email from TB to domain xyz.com AND gmail.com -> No HTML disclaimer is added (twitter, facebook icons etc) Adding two domains to the "HTML domains" tab, say xyz.com AND gmail.com: Sending an email from TB to domain xyz.com AND gmail.com -> HTML disclaimer IS added (twitter, facebook icons etc) It seems the domains where to sends emails to have to be listed in the send options "HTML domains" tab ~:) This is weird, isn't it?? This is not manageable!! Another test. So I thought, what the heck i'll add the HTML disclaimer in the signature part of the account, so it will always be send. Did that, but now the HTML disclaimer is added twice?? to the email!!?? (no domains are listed in the sending options "HTML domains" tab) Oke...if you really want to joke with me, I only added an empty html line as signature in TB in the hope is will add an empty line, but with the HTML disclaimer from altermime/Postfix. Unfortunatly it didn't (ofcourse). Only the empty line was visible.. There are two ways to get is working: 1) List every domain which you want to sends an email to to the sending options "HTML domains" tab. 2) For every email you write, set explicity to send the mail as "Rich Text (HTML) Only". Btw...in Zarafa we don't see this problem with the disclaimer, so Altermime/Postfix isn't the problem. I've tested this with TB 10.02 and 13.01 (latest) on Ubuntu 10.04 LTS Actual results: Please see forum: http://forums.mozillazine.org/viewtopic.php?f=31&t=2491079&p=12083369#p12083369 Expected results: The email should be send and the HTML disclaimer should be added to the email. In config editor i have the parameter: mail.html_compose -> default -> boolean -> true. In my English this means that the mail should always be send as HTML and not as plain text.

Roland, thank you for your problem report. I think the UX of these settings is indeed confusing. Two related problems: Bug 136502 - can't switch off Format:Auto-Detect Bug 414299 - Format:Auto-Detect removes too much HTML I suspect there is another problem (similar to your description), that some settings are not well-described, not honoured, or their interaction with other settings is flawed or not transparent. It would be interesting if you could add the message source of your message including the HTML disclaimer as an attachment to this bug here ("Add an attachment" link on top), after removing private data as necessary, so we can better understand the problem.

As other bugs mentionet, root cause of Your problem is "clever" code to downgrade HTML mail to plain text, if TB detect that HTML have no formatting. But classifier function is so bad, so many timed good HTML is send as plain-text. As workaround, in my Stationery extension I disable this function, telling TB to always send message in HTML. It works very well for me and other Stationery users. You can download Stationery from AMO. By the way, Stationey may help You also with Your disclaimer. Stationey allow to load HTML file as template for mail, both new, replies and forwards. Basically it works like Stationery option in Outlook.

Hi Arivald, The Stationay add-on works perfectly. I only had to install the add-on and all mails are send in HTML format by default. This means for me, our company disclaimer is added to the sending email. Thanks alott!! Btw, I'll still hope Mozilla will add this by default in their future release to be able to send HTML by default.

(In reply to roland.de.lepper from comment #0) > Steps to reproduce: > Another test. > Actual results: This is exactly same case as (C-1) of table of "User Story" of Bug 1210244. (C-1) When mixed recipients, (Unknown, or two or more in "HTML domain, Text Domain, Unknown"), if HTML is considered "Convertible to text" by Tb, mail is silently sent as text/plain by Tb with unknown reason, without using Send Options setting. It looks that this bug was fortunately not closed as dup of bug 414299 merely by "auto-downgrade-to-text happened". Proposal by Bug 1210244 is "use Send Options in case (C-1)". Please watch that bug. Confirming.

Please see Bug 1204379 Comment #12 for Quick Summary of known workaround or circumvention or required action.

> Requested message source + disclaimer HTML file + extra info Some questions on composed HTML. In recent Tb, following case doesn't prodece "Convertible to text" state. <p>, <a href=...>, <img> is involved in HTML. This bug was opeed on 2012-06-20. Bug opener, do you see your problem in recent Tb with similar or same HTML? Link is <a href="https:// ... " ><img src="http:// ... " /></a>. No link text. This is relevant to problem?

FYI. Link like <a href="https:// ... " ><img src="http:// ... " /></a> can not be generated by Tb's "Insert Link", because UI of "Insert Link" of Tb doesn't accept image as data of Link Text part.

FYI. One of simplest/easiest/impact-less workaround by Tb user is "background color of #FFFFFE, #FEFEFE etc.". What kind of human being can recognize difference among #FFFFFF, #FFFFFE, #FEFEFE? :-)

To bug opener, can you attach HTML source which produces problem? 1. Compose an HTML mail which surely produces this bug if no workaround is done, with a recipient of "Prefers = Unknown Contact in Address Book". 2. Delivery Format = HTML Only 3. Send Later 4. If possible, do same test with Delivery Format=Auto-Detect, and check Content-Type: header, please. Because message header is irrelevant and personal data shouldn't be exposed, please remove message header. Content of text string is also irrelevant. Please replace it if confidential data/personal data is used in text.

(In reply to WADA from comment #7) > > Requested message source + disclaimer HTML file + extra info > > Some questions on composed HTML. > In recent Tb, following case doesn't prodece "Convertible to text" state. > <p>, <a href=...>, <img> is involved in HTML. Have there been changes to the isConvertible algorithm? Please look at Bug 414299 Comment 108. the following are considered by current TB as convertible::plain: <p> <a href=foo.bar>foo.bar</a> (only if url is identical with link text) So only <img> will not trigger convertible::plain. Maybe you just forgot to write "and"? if x, y, *and* z are involved in HTML, then it's not convertible::plain.

(In reply to WADA from comment #8) > FYI. > Link like <a href="https:// ... " ><img src="http:// ... " /></a> can not be > generated by Tb's "Insert Link", because UI of "Insert Link" of Tb doesn't > accept image as data of Link Text part. True, but you can generate image-only links with TB by using edit -> HTML command.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #12) > (In reply to WADA from comment #8) > > FYI. > > Link like <a href="https:// ... " ><img src="http:// ... " /></a> can not be > > generated by Tb's "Insert Link", because UI of "Insert Link" of Tb doesn't > > accept image as data of Link Text part. > > True, but you can generate image-only links with TB by using edit -> HTML > command. Sorry, I meant Insert -> HTML. FYI: Insert -> HTML can easily be used for *edit* HTML: Select part or all of composition body text. Then Insert -> HTML. Existing HTML source of composition can be freely edited. It's a bit inconvenient, but it works. Also good for inspecting the generated HTML.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #11) > Maybe you just forgot to write "and"? if x, y, *and* z are involved in HTML, (snip) Yes. These 3 are seen in attached data by bug opener.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #13) > Then Insert -> HTML. Aha! Insert HTML, enter <!-- ppp -->, with Unknown recipient, Send Later => following HTML mail was sent by Tb 38.2.0. Good job. Pretty important and valuable HTML comment was not lost. A newly found workaround : put HTML comment in HTML signature. <html> <head> <meta http-equiv="content-type" content="text/html; charset=windows-1252"> </head> <body bgcolor="#FFFFFF" text="#000000"> <br> <!-- ppp --> </body> </html>

If "ABC" (no quote) was put by Insert HTML of Tb 38.2.0, following HTML was sent by Send Later with Unknown recipient, with Delivery Format=Auto-Detect, in Tb 38.2.0. Newly found workareund : Use Insert HTML "Reproduce phenomenon of pretty frequent severe Format Loss in HTML mail" is pretty hard job for me... Content-Type: text/html; charset=windows-1252 <html> <head> <meta http-equiv="content-type" content="text/html; charset=windows-1252"> </head> <body bgcolor="#FFFFFF" text="#000000"> ABC </body> </html>

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #12) > (In reply to WADA from comment #8) > > FYI. > > Link like <a href="https:// ... " ><img src="http:// ... " /></a> can not be > > generated by Tb's "Insert Link", because UI of "Insert Link" of Tb doesn't > > accept image as data of Link Text part. > True, but you can generate image-only links with TB by using Insert -> HTML command. FYI. If image only link is geerated by Insert HTML of Tb with existent image data(existent http://, file://), Tb embeds image data in mail(multipart/related for HTML part), and uses cid: url in HTML(<img src="cid:...">). To avoid this, Unchecking of "Attach this image in the message" is needed at Image Location after Insert HTML, In both cases, I couldn't observe auto-downgrade-to-text by Tb 38.2.0.

Thomas D., when Insert HTML is used, Tb doesn't look to consider it Convertible. Is Insert HTML => Save As Draft => Edit Draft is needed to force auto-downgrade-to-text?

(Off-Topic) (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #11) > (In reply to WADA from comment #7) > Have there been changes to the isConvertible algorithm? > Please look at Bug 414299 Comment 108. I looked into aceman's patch proposed in that bug. As for Tag processing part, it looks essentially 2-liner patch : Remove <tt> from <html>, <head> ... group, Add <tt> to <b>, <i>, <strong> ... group. Thomas D., why war on <tt> continued so long time? For developers, <tt> is tag which should be ignored? Or it's merely that no one proposed patch because pretty small issue?

To bug opener, please see comment #7 and comment #10.

(In reply to WADA from comment #18) > Thomas D., when Insert HTML is used, Tb doesn't look to consider it > Convertible. > Is Insert HTML => Save As Draft => Edit Draft is needed to force > auto-downgrade-to-text? No, I think something was wrong with your test case, maybe recipient set to prefers-html Message to recipient of "prefers-unknown", insert HTML > "ABC" (without quotes) > Send later. Auto-Downgrade occurs, msg in outbox seen as format-flowed. (In reply to WADA from comment #19) > (Off-Topic) > > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #11) > > (In reply to WADA from comment #7) > > Have there been changes to the isConvertible algorithm? > > Please look at Bug 414299 Comment 108. > > I looked into aceman's patch proposed in that bug. > As for Tag processing part, it looks essentially 2-liner patch : > Remove <tt> from <html>, <head> ... group, Add <tt> to <b>, <i>, <strong> > ... group. > Thomas D., why war on <tt> continued so long time? For developers, <tt> is > tag which should be ignored? As I told you, just one stubborn developer who was not willing to listen to anything we said, with a clear interest to not change a jota of what he wrongly considers "his" code. Also, Ben has insisted (to this day) on this logically flawed argument: a) because <tt> in HTML format is typically rendered in fixed width (that's true) b) and under the assumption that plaintext is typically rendered as fixed-width by recipient (that's not quite right, either). c) => we can just ignore HTML formatting of <tt> and send entire message in plaintext without any loss of formatting (that's wrong) He was not able to realize that b) and c) are wrong, for multiple reasons: b) many mail readers will render plaintext-f-f in variable font width. So even for a message only containing single <tt>intended fixed width text</tt> and no other text or tags, there's a formatting dataloss because recipient mail reader has no way of knowing that text was intended to be rendered in <tt> teletype style with fixed width. b)c) The fact that some mail readers like gmail do not render <tt> correctly in fixed width is irrelevant because TB must send the correct markup even when recipients *might* not be able to read it as intended. Pre-emptively sending braille because the recipient *might* be blind is obviously nonsense and, if taken as an absolute, you could never send any formatted message to anyone, which is obviously nonsense. This train of thought also forgets that even a recipient who is unable to see the received message with all formatting as intended using one certain mailreader might still have other mailreaders, other devices, or other ways of rendering the same message, either immediately, or at some later point in time. c) in HTML message, using <tt> with some other text outside <tt> will typially render as *alternation* of variable width for normal text and fixed width for <tt>. Which is the whole point of <tt>, to make it look like teletype(tt)-typewriter and thus stand out from the rest. Deliberate and distinct alternation of different font widths is LOST when sending entire msg as plaintext-f-f. > Or it's merely that no one proposed patch > because pretty small issue? I think the aggressive blanket resistance from Ben was so strong that nobody ever tried actual patches. At that time, it was also still very hard for me to do patches, and maybe I wasn't willing to spend hours on something which Ben could have fixed in 30 minutes. Plus he aggressively changed bug summaries in order to deceive anyone coming across such bugs that the issues were very small and not worth attention. Also, by not responding or responding nonsense, he forced users and QA people into more extensive comments to try and get their message across, which made bugs hard to read. I don't care if small issue or not. It's legimate issue, and several users complained about it. And as you know, being unprincipled in small issues can easily cause big problems for software behaviour. When Auto-Downgrade was born, developer probably thought, ahhh, it's just a tiny bit of formatting which I remove, almost invisible, so no need to ask the user. Turns out that decades later, when all the circumstances requiring downgrade (enforce plaintext bias, prevent ASK-nagging) have entirely disappeared, we're still suffering big time from the consequences of that small unprincipled design decision, because it was very hard to find for users and QA people, and turns out that removing small tags like <tt> will also remove all the inline styles associated with them, which is no longer lossless, but d....ownright different. Phew. Almost used the evil d-word. I like the irony of history that because Ben was unwilling to improve anything in auto-downgrade and auto-detect, we are now hearing voices of active and influential developers/QA people openly discussing if recipient-centric Auto-Detect can be ripped out altogether, because the "prefers-plain" usecase is practically obsolete (and can still be covered by message-centric delivery format plain text, or plaintext editor for emergencies). I've told Ben at an early stage that only improving his algorithms and making them optional would actually help to preserve them, but he preferred to ignore me and not answer to anything I said. Another little irony (against myself) is that while Auto-*Detect* looks indeed mostly dispensible (although new usecases like smart watches might need consideration), I have actually come to advocate for the *expansion* of recipient-scope for auto-*downgrade* to include allHTML case, for reasons of consistency and simplicity...

(In reply to roland.de.lepper from comment #0) > Adding two domains to the "HTML domains" tab, say xyz.com AND gmail.com: > Sending an email from TB to domain xyz.com AND gmail.com -> HTML disclaimer IS added (twitter, facebook icons etc) > It seems the domains where to sends emails to have to be listed in the send options "HTML domains" tab ~:) > This is weird, isn't it?? > This is not manageable!! I think so. It's mystery for us. When I want to get pretty simple text/html source for testing, if I forgot to do workaround or forgot to choose Delivery Format=HTML at menu, text/plain source is generated, so I have to create the pretty simple HTML again :-) "Prefers=Unknown recipent in HTML Domain/Text Domain setting" is currently treated as "one similar to Text Domain recipient" for histrical reason and for safety in email world. "Prefers=Unknown in Address Book Contact" can be called main culprit of user's confusion. Bug opener, please see Bug 1215791 and pointed documents for detail of phenomenon, problems in it, known workarounds, possible solutions for Tb users. Solution in that bug may be called; Prefers=Unknown for small mobile phone era => Prefers=Unknown for Smart Phone, iPhone, iPad era. By the way, a big fault in bug processing for this issue in the past was : Put all complaints on this kind of phenomenon(never for proposal of proper solution) to Bug 414299 which is for "<tt> and <a> with link text=link url" case only. I guess that a cause of such not-so-well action was misleading by someone in bug report at B.M.O for the phenomenon. In the past, many peoples perhaps believed that culprit is Convertible check logic.

Let's get this out of Untriaged component.

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #23) > Let's get this out of Untriaged component. Yeah, sounds time to me that this bug found its proper Product/Component. :-) Is there really no pref to completely disable auto-downgrade to text? When I compose a message as plaintext, I want it sent as plaintext, and the rare times when I compose a message as HTML, I want it sent as HTML. No format changes behind my back, please. There are hacks described in the preceding comments (such as setting a vaguely grey fg/bg: <body style="color=#010101; background-color: #FEFEFE">) but that, and the other tricks mentioned, are just hacks working around a problem which, IMHO, ought never to have existed. Ah well…

Ah, there: mailnews.sendformat.auto_downgrade (but the default is "true" !!!)

(In reply to Tony Mechelynck [:tonymec] from comment #24) > compose a message as plaintext, I want it sent as plaintext, and the rare > times when I compose a message as HTML, I want it sent as HTML. No format > changes behind my back, please. That's a reasonable user's expectation (ux-principle of wysiwyg). > There are hacks described in the preceding comments (such as setting a > vaguely grey fg/bg: <body style="color=#010101; background-color: #FEFEFE">) > but that, and the other tricks mentioned, are just hacks working around a > problem which, IMHO, ought never to have existed. +100 (In reply to Tony Mechelynck [:tonymec] from comment #25) > Ah, there: mailnews.sendformat.auto_downgrade (but the default is "true" !!!) Yes, setting this pref to "false" will disable unexpected downgrading for the typical scenario of default settings (recipient-prefers-unknown; send both plaintext and HTML). Tony, feel free to file a new bug to request defaulting the pref to "false" and provide reasons why. I'm not sure which is better; as it was hard enough to get the pref into the app, the default value appeared less important. Alternatively, we could keep defaulting to "true" but make the pref more discoverable in the primary UI (see below). I implemented UI for this pref as well: Tools > Options > Composition > General > Send Options > [x] Send messages as plaintext if possible So this pref and UI will land with TB 45. I think it should be much more exposed on primary UI (in composition window: Options > Delivery Format menu), but at least we now have a pref with UI so hacks and addons are no longer necessary to prevent this nuisance / mystery behaviour.

(In reply to roland.de.lepper from comment #0) > Expected results: ... > In config editor i have the parameter: mail.html_compose -> default -> > boolean -> true. In my English this means that the mail should always be > send as HTML and not as plain text. Another instance of where users just expect that their HTML-composed messages should just get sent as HTML no matter what, without surprise changes of format behind their back. I think the surprise element is still not fixed, but at least after Bug 136502 it's now controllable (see comment 26), so users can actually enforce sending HTML always via options. So I'll mark this as a duplicate of that bug. Bug 584313 will furthermore reduce the mystery/surprise element by making the algorithm smarter to preserve more HTML/CSS styles. Any remaining mystery/surprise issues (Auto-Downgrade defaults to true, sends HTML formatted message as plain text) may need new, clean bugs if they aren't filed already. Roland, thanks for filing this and responding with further information.