Closed Bug 1653953 Opened 4 years ago Closed 4 years ago

Plain Text Domains not working for a certain profile

Categories

(Thunderbird :: Message Compose Window, defect)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: n1ck.h0w1tt+bugzilla, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

In Options > General > Send Options > Pain Text Domains, add a domain. Send an e-mail to the said domain.

The account Composition & Addressing composition option is set to "Compose messages in HTML format"

Actual results:

The e-mail should have been sent as plain text

Expected results:

The e-mail was sent as HTML. This is the received body and a bit of the header:
Date: Mon, 20 Jul 2020 11:00:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Feedback-ID: 19067468

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
test
</body>
</html>

Severity: -- → S4
Component: Untriaged → Message Compose Window

Hey Nick, I have just tested your scenario and this worksforme on TB 68.10.0 (32-Bit), Win10.
This is what I did:

  1. Tools > Options > Compose > Send Options > Plain Text domains > Add:
    Plaintext domain name: foo.com, confirm
  2. Compose message using default identity of account having "Compose messages in HTML format" checked (active)
  3. Compose to test-plaintext-domain@foo.com (with or without some HTML formatting like bold)
  4. Ctrl+Shift+Enter to "Send Later", inspect message source (Ctrl+U) in Outbox folder of Local Folders

Actual result = Expected result

  • both with and without HTML formatting, sent message was formatted as plaintext as expected. Bold was correctly converted to *bold *.

We do have known bugs in this corner, and settings that may interact in unpredictable/intransparent ways.

  • Are you able to reproduce this bug with "Help > Restart with Addons disabled" (TB Safe mode)?
  • Please check the contact card of your recipient in address book: What is set on card for "Prefers to receive messages as: ..."?
  • Did you send to several recipients (including auto-cc/bcc, reply-to etc.)? What are their format preference settings?
  • What's your setting for Send options > Text format > "Send messages as plaintext if possible"?
  • What's the exact structure of your plaintext domain entry and the domain structure of the recipient? Any subdomains?

I've upgraded to 78.0 - I don't know what the story is there, but it is not for this bug - and it is the same.

In safe mode:

  • no change to sending. Message is received as HTML
  • set to "Unknown"
  • no. Single recipient (another account of mine, but was originally noticed posting to a list)
  • not checked so not enabled.
  • Not sure what you mean here. I see the same sending to samba@lists.samba.org and to XXXXX@clearcenter.com (my own work account handled by GMail), so Samba has a subdomain, my work account does not.

(In reply to Nick Howitt from comment #2)

Thanks for answers. Please quote each question you're answering to, thanks.

I've upgraded to 78.0 - I don't know what the story is there, but it is not for this bug - and it is the same.

In safe mode:

  • no change to sending. Message is received as HTML

Can you please use exactly my STR with domain foo.com, write to john@foo.com and "send later" to your Thunderbird outbox, and then check the message in outbox of local folders.

  • set to "Unknown"
  • no. Single recipient (another account of mine, but was originally noticed posting to a list)
  • not checked so not enabled.

Also worksforme without "Send messages as plaintext if possible"...

I wanted to compare the plaintext domain/subdomain exactly as you entered it in preferences, and domains/subdomains of recipients.
In my tests, having foo.com as plaintext domain in prefs and sending to john@sub.foo.com still works.
Of course, having www.foo.com as plaintext domain in prefs and sending to john@foo.com would NOT work.

First message (no formatting) is a pass:

From - Mon Jul 20 16:32:10 2020
X-Mozilla-Status: 0801
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
FCC: imap://mail-nick@***.lan/INBOX/Sent
X-Identity-Key: id2
X-Account-Key: account4
To: john@foo.com
From: ***
Subject: Test
Message-ID: <dcd49ab5-b2fa-b948-5343-86caa66e990a@***>
Date: Mon, 20 Jul 2020 16:32:10 +0100
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0;
 attachmentreminder=0; deliveryformat=4
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB

Test

So is second with formatting:

From - Mon Jul 20 16:35:40 2020
X-Mozilla-Status: 0800
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
FCC: imap://mail-nick@***.lan/INBOX/Sent
X-Identity-Key: id2
X-Account-Key: account4
To: john@foo.com
From: ***
Subject: test2
Message-ID: <68af07a9-ca48-c2e2-2187-ee839092b190@***>
Date: Mon, 20 Jul 2020 16:35:40 +0100
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0;
 attachmentreminder=0; deliveryformat=4
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB

*Test2*

Perhaps it is worth saying that I run my own SMTP/IMAP server on my LAN that the messages should be sending through.

Just to clarify, the last (working) test is using your steps with "send later". My initial report and tests were sending from TB via my SMTP server.

AIUI, the message in outbox is exactly the message which will be sent.
My conclusion is that plaintext domain feature seems to work as expected for the Thunderbird side.
Not sure there's anything we can do for you beyond that.
So can we close this bug as worksforme?

I'm afraid I don't agree. To me there is still an issue. I now have a repeating failure with a test similar to yours.
As you did, create an e-mail to john@foo.com. For the text use "test" and bolden the es so you see test. Then "Send later". I see the following in the Outbox:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.0
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    t<b>es</b>t
  </body>
</html>

And it has not degraded.

(In reply to Nick Howitt from comment #7)

I'm afraid I don't agree. To me there is still an issue. I now have a repeating failure with a test similar to yours.
As you did, create an e-mail to john@foo.com. For the text use "test" and bolden the es so you see test. Then "Send later". I see the following in the Outbox: [HTML message]

Wfm on 79.0b1 (32-bit), I get plaintext msg as expected.
Are you using HTML signatures?

Sorry for the double post. I was trying to do an edit.

No I am not using any signatures.

I used to have an addon, Always HTML, which got disabled for compatibility reasons. it has now been removed. Could that have set (and left) any pref which affects this behaviour?

(In reply to Nick Howitt from comment #11)

I used to have an addon, Always HTML, which got disabled for compatibility reasons. it has now been removed. Could that have set (and left) any pref which affects this behaviour?

No, I don't think so. Per my Bug 414299 Comment 125, Always HTML used to overlay DetermineConvertibility() function and hard-coded the answer nsIMsgCompConvertible.No to force HTML always. Now AIUI Addons are no longer allowed to just overlay, they can only have access through explicit APIs or WebExperiments.

I have a laptop where the degrading works. Historically it was set up using the same profile a couple of years ago but they have diverged since then. I've tried diffing the prefs.js and there is nothing at all which stands out. Ignoring things like the smtp server, account and printer settings, and ignoring things like timestamp fields, I can't see anything.

It is in the form of an Excel document which I could attach if you wanted (after sanitising it for personal info).

Anything in error console after "Send later" of message which does not degrade as expected (Ctrl+Shift+J)?

This does not look like a bug in the plaintext vs. HTML algorithm.
We're also planning to rip the recipient-centric parts of that out, because it's complex, error-prone and often self-defeating except for simple cases (think of mixed-pref recipients etc.), so we wouldn't want to spend too much time on this.

So for now, I'll close this as worksforme.
If there's new facts pointing to a bug, feel free to post that here and request reopening.
Otherwise, I think this is a support case to figure out what is going on, you can try getting support:

https://support.mozilla.org/en-US/products/thunderbird

But for this particular issue, I'm also not sure if support could do more for you.
Maybe Wayne has ideas.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Summary: Plain Text Domains not working → Plain Text Domains not working for a certain profile
You need to log in before you can comment on or make changes to this bug.