I have the preference mail.strictly_mime set to true to force Content-Transfer-Encoding to quoted-printable or 7bit, because one of my accounts is AOL, i.e. Yahoo-type. I've checked the source (Ctrl+U) in my sent messages. This is with TB 68.2.1, and the solution has been known since at least as early as TB 60, so I'm not sure why the workaround isn't working for you.

sfhowes said

I have the preference mail.strictly_mime set to true to force Content-Transfer-Encoding to quoted-printable or 7bit, because one of my accounts is AOL, i.e. Yahoo-type. I've checked the source (Ctrl+U) in my sent messages. This is with TB 68.2.1, and the solution has been known since at least as early as TB 60, so I'm not sure why the workaround isn't working for you.

Thanks for the reply! The reason I'm not satisfied with the "mail.strictly_mime" workaround is that it causes Thunderbird to insert the extra three characters "=A0" in any place that my message contains a double space. Using TB version 52.2.1, with 7bit encoding, no extra characters are inserted in place of a double space, either by Thunderbird or by Yahoo mail. (Using the current version of TB with the "mail-strictly_mime" workaround, I always get "quoted-printable" encoding, and I've never been able to get "7bit" encoding.)

I don't see any extra three characters when I read a message sent from my AOL account. In Tools/Options/Display/Formatting/Advanced I have Text Encoding for Outgoing Mail set to Unicode (UTF-8) and Western (ISO-8859-1) for Incoming Mail. Some users have Unicode for both. My AOL account shows 'quoted-printable' for the Content header, like another non-Yahoo account, but Hotmail shows '7bit', but they mean the same, as far as I know.

sfhowes said

I don't see any extra three characters when I read a message sent from my AOL account. In Tools/Options/Display/Formatting/Advanced I have Text Encoding for Outgoing Mail set to Unicode (UTF-8) and Western (ISO-8859-1) for Incoming Mail. Some users have Unicode for both. My AOL account shows 'quoted-printable' for the Content header, like another non-Yahoo account, but Hotmail shows '7bit', but they mean the same, as far as I know.

One clarification is that to see the extra "=A0" characters in Thunderbird, I need to view the source of the message (Ctrl-U), but it sounds like you already tried that, so I'm puzzled why you aren't seeing them too. I tried it again just now with my AOL account in TB 68.2.1 and still see the extra characters "=A0" at each double space in the source when I set mail.strictly_mime to true and use Western (ISO-8859-1) for both outgoing and incoming. If I then change to Unicode (UTF-8) for outgoing, I actually see six extra characters "=C2=A0" inserted at each double space in the message source. The characters are added by TB (not by AOL), because I tried "Send Later" and saw the extra characters already there in the source of the message in my Outbox before sending, and they remained there exactly the same after the message was sent through AOL. To illustrate, below are the actual final headers and body of a message source in my Outbox before sending:

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US

This is a test.=C2=A0 This is a test.=C2=A0 This is a test.

The =A0 characters do appear in the source, but not in the message body, no matter what is set for View/Message Body As. This is with messages composed in TB, not copied from an external app.

sfhowes said

The =A0 characters do appear in the source, but not in the message body, no matter what is set for View/Message Body As. This is with messages composed in TB, not copied from an external app.

Thanks for clarifying; then we're both seeing the same thing.

I actually would prefer that TB not insert the =C2=A0 at every double space, because they appear as clutter if someone is viewing it on a system that isn't MIME compliant, and the MIME codes are completely unnecessary for me because 99% of my messages are entirely 7-bit ASCII text. Therefore, I'm still looking for an answer to my original question:

Is there any way to send messages with the Content-Transfer-Encoding header set to "7bit" in the current version of Thunderbird, as was possible in versions 52.2.1 and earlier?

I use BT which uses yahoo server. Using TB version win32 68.2.1 Windows 10 64bit

My settings: 'about:config' mail.strictly_mime_headers;true mail.strictly_mime.parm_folding;1 mail.strictly_mime;false

I use 'Western (ISO-8859-1)' for both outgoing and incoming.

selected: 'use fixed width font for plain text messages' unchecked: 'When possible use the default text encoding in replies'

Fonts for Latin: Proportional : Sans serif Serif: Cambria Sans Serif: Default Arial Monospace : Consolas

Also set up same for 'Fonts for' Other writing systems'

Plain text setting using Style: Regular Size: regular

HTML: Variable width: size: Medium

Source in Draft: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit

this is a test. this is a test yehar

View> Text Encoding says 'Western'

When I set outgoing to unicode (utf-8) Source in draft: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit

this is a test. this is a test

View> Text Encoding says 'Unicode'

I'm not getting same issue so far.

Toad-Hall, thank you; I tried your settings and carefully double-checked them. However, in both cases (with Outgoing set either to ISO-8859-1 or to UTF-8), I'm getting a message with Content-Transfer-Encoding: 8bit in my Outbox, instead of 7bit as you obtained. One other difference is that my Content-Language header is en-US rather than en-GB, so I wonder if this could be a bug in the en-US version of Thunderbird that doesn't exist in the en-GB version. Later when I have time, maybe I'll try installing the en-GB version and see if it works any better for me.

There's also one other possible difference: I viewed my message source in my Outbox after selecting "Send Later," but you wrote you were viewing the source in Draft. When I save my message to my Draft folder, it's in HTML format (converted to plain text upon sending), unlike yours which is plain text format in the Draft folder, so is this another difference between the en-US and en-GB versions?

As you were sending in Plain Text, I presumed you composed in Plain Text and sent as Plaintext. Hence, I created it in Plain Text.

So, changed setup to mirror you. Composing in HTML. Sending only as Plain Text. Used 'Send Later' to put in Outbox. First test Using Outgoing Mail encoding as 'Unicode(UTF-8)

Outbox and Received Source looks like this: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB

This is a test. This is a test. Yehar again. Two spaces between each sentence.

Outbox and Received message look like: This is a test. This is a test. Yehar again. Two spaces between each sentence.

Second test Using Outgoing Mail encoding as 'Western (ISO-8859-1) Outbox Source and REceived source looks like this: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB

Testing the double space after sentence. Testing again. This time I'm inserting 3 spaces. That's all folks.

outbox and Received message look like: Testing the double space after sentence. Testing again. This time I'm inserting 3 spaces. That's all folks.

Test in Safe Mode to ensure nothing could be effecting results Outgoing and Incoming as Unicode: Same result with outgoing a Unicode and incoming as Western. Outbox email content looks ok. Outbox source: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB

This is a line. Double space break.  that last one a triple.

REceived email looks ok. Source of received email same as in Outbox source see above.

Outgoing and incoming as Western (ISO-8859-1)' Emails look good in view both in Outbox and Received. Source code in both in Outbox and Received. MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB

this is a single space. This is a double space. This is a triple. See.

Findings: When composing and sending in Plain Text 7bit is used. It does not matter if using Unicode or Western - Same result. There are no additional characters appearing in Source code when there is a double space between sentences.

When composing in HTML but sending only as plain text 8bit is used due to conversion. When using 'Unicode(UTF-8)' as outgoing and 'Western (ISO-8859-1)' as incoming. Also same result when using 'Unicode(UTF-8)' as outgoing and incoming. There is single  character inserted in source code for each additional space.

But the characture is removed in the Message Pane view when reading emails.

Suggestion: If you want to send an email in Plain Text and you want to use 7bit, then you must compose the message in Plain Text.

I only get additional characters in source code if I use 'Unicode' AND compose in HTML AND send as Plain Text. Although in my case those additional characters are stripped when reading the email.

Thank you for the excellent help. I've successfully confirmed your finding that composing in plain text gives me 7bit CTE. In the past I've always composed in HTML and had forgotten there was even an Account Setting to compose in plain text, but I guess that composing in plain text is a satisfactory workaround for me to get 7bit CTE, assuming it doesn't cause me any unexpected new problems.

However, TB version 52.2.1 and earlier produced 7bit CTE even when composing in HTML, so this is at least a change if not a bug in newer versions of TB including the current release. I don't have any experience using Bugzilla but wonder if there would be any use in my submitting this as a possible bug.