1324039 - Multi recipient email where one recipient is to a plain text domain sends as HTML

Status: RESOLVED DUPLICATE of bug 1222176

(Thunderbird :: Untriaged, defect)

Description

[hussey]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161017194814

Steps to reproduce:

Under preferences -> composition -> send options -> plain text domains add a domain for any email address in the address book.  Select 'send the message in HTML anyway' under when sending messages as HTML....

Under account settings -> composition and addressing (for the relevant account) select composer messages in HTML.

Now create a message with the recipient being an address under the domain you added as plain text before.  Send the email.

Compose another email to the same recipient, but this time add one or more CC to an email for a domain not set as a plain text domain.  Send the email.


Actual results:

The first email sends as plain text which is correct, but the second email sends as HTML to all recipients, including the plain text recipient.


Expected results:

Behaviour should be that if one recipient of a multi recipient email is under a plain text domain, all recipients should receive the email as plain text, not the plain text recipient receives the email as HTML.

Comment 1

[Jorg K (CEST = GMT+2)]

Thomas, this is your speciality. Would that have been fixed by bug 1222176?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #1)
> Thomas, this is your speciality. Would that have been fixed by bug 1222176?

Yes.


(In reply to hussey from comment #0)

> Expected results:
> 
> Behaviour should be that if one recipient of a multi recipient email is
> under a plain text domain, all recipients should receive the email as plain
> text, not the plain text recipient receives the email as HTML.

Not exactly. Reporter set "When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML": "Send the message in HTML anyway".
There's a plaintext recipient (and unknown recipients), so technically TB did the correct thing and sent as HTML only per pref setting.

However, unfortunately, there's no sane alternatives for reporter to achieve the desired behaviour.
The major problem of current design, for which bug 1222176 is the best solution, is this (as explained a dozen times in those other bugs, but maybe still not understood by some of the powers that be):
Above option de facto combines two things which are orthogonal:
- conflict resolution for mixed cases involving prefers-plaintext AND prefers-unknown/prefers-html
- default format for cases of prefers-unknown
The irony being that for what is arguably the main usecase of prefers-plain, namely to send plaintext-only, with TB's single pref there's no way to do that without also spoiling your default HTML configuration, which is reporter's case:
- For the default case of prefers-unknown, user must set an option including HTML, i.e. "Send HTML only" or "Send html and plaintext" (you can't set "send plaintext only" because then you'll never send HTML for prefers-unknown, which is nonsense).
- For the conflict resolution case, a minority of users like reporter might want "send plaintext only", thus deliberately overriding (implicit/explicit) HTML preference of others of type prefers-unknown or prefers-html.
Because we combine those orthogonal needs into a single option, the default setting of "Send both plaintext and html" is the only possible compromise setting for users like reporter. Meaning that the current implementation of this option is totally useless for conflict resolution and could just as well be removed and replaced by a message-centric default setting.

Having said which, conflict resolution of "send plaintext only" does not make much sense, and would also require a "downgrade this msg to html and loose all of your formatting" confirmation prompt (another bug). It doesn't make sense to compose in HTML and then loose all of your formatting when sending, because of a single prefers-plain recipient. Even plaintext recipients of age-old systems like Pine are able to correctly receive and decode the plaintext part of multipart messages (even rudimentary HTML). So if user insists on composing plaintext, he should use plaintext composition mode deliberately and explicitly. The truth is that recipient-centric format determination has outlived its purpose, and should be removed, as Magnus said in bug 222176.

Until then, I still think we should fix bug 222176, to have a bug-free and more sane status quo.

Comment 3

[Thomas D. (:thomas8)]

(In reply to Thomas D. (needinfo?me) from comment #2)

> Having said which, conflict resolution of "send plaintext only" does not
> make much sense, and would also require a "downgrade this msg to html and
> loose all of your formatting" confirmation prompt (another bug).

Typo: ...would also require a "Downgrade this msg to *plaintext* and loose all of your formatting?" confirmation prompt.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Thomas D. (needinfo?me) from comment #3)
> Typo: ...would also require a "Downgrade this msg to *plaintext* and loose
> all of your formatting?" confirmation prompt.

Typo: ...would also require a "Downgrade this message to plaintext and *lose* all of your formatting?" confirmation prompt.

lose (verb) vs.
loose (adjective)

Comment 5

[Jorg K (CEST = GMT+2)]

to lose, lost, lost (verb) - that's the one where something goes missing ;-)
to loose (verb)
loose (adjective)
to loosen (verb)

Comment 6

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #5)
> to lose, lost, lost (verb) - that's the one where something goes missing ;-)

An o goes missing ;) Schöne Eselsbrücke, verlieren ist wo das o verloren geht...

> to loose (verb)

loslösen, aha!

> loose (adjective)

lose (that's German now, for complete confusion... :p)

> to loosen (verb)

lösen, lockern

Die spinnen, die Engländer... thanks for the linguistic update, indeed!

Comment 7

[Jorg K (CEST = GMT+2)]

And don't forget the pronunciation: "to lose" has a soft "s", "(to) loose(n)" has a sharp "s".

Comment 8

[hussey]

Thomas, I understand what you have put, but those who prefer to receive messages as plain text only typically have a much stronger preference/reason for wanting this format than those who 'prefer' HTML.  To me, it's much more that HTML is the default that people are just used and might not even know there is a text only alternative, but those who prefer text only have a solid, possibly security related reason for this.  The recipients who prefer plain text will object far more readily if they receive HTML than HTML recipients if they receive plain text.  As you note "Send the message in HTML anyway" is the only way to have contacts who have no preference set receive HTML, and to me it would make sense if a plain text domain recipient overrides this default, which is what happens if they are the only recipient of the email, even in the case of the multi recipient email.  If I set to send a plain text and HTML how does that work exactly?  It sounds like that would send 2 emails, one as HTML, and one as plain text which would not be a good default.