Closed Bug 1379096 Opened 7 years ago Closed 7 years ago

mail.strictly_mime=true should be the default (it currently isn't)

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ferry, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170613080647

Steps to reproduce:

I'm getting replies from more and more mail servers that
  "Diagnostic-Code: smtp;554 5.6.1 Body type not supported by Remote Host"

This is resolved in Thunderbird by setting
  mail.strictly_mime=true

I propose that this setting becomes the default.

My best guess is that these servers are M$ servers on which something was upgraded/changed.
Component: Untriaged → Preferences
So the effect of setting this option is that BODY=8BITMIME will be sent as part of the HELO response, right?
https://dxr.mozilla.org/comm-central/rev/aa2b50ea86596b917d59ba5f6f9385b2d0a35bf2/mailnews/compose/src/nsSmtpProtocol.cpp#786

What effect does that have?
The effect is obvious: the email is accepted by the destination server and I no longer get the error :-)
(In reply to Jorg K (GMT+2) from comment #1)
> So the effect of setting this option is that BODY=8BITMIME will be sent as
> part of the HELO response, right?
> https://dxr.mozilla.org/comm-central/rev/
> aa2b50ea86596b917d59ba5f6f9385b2d0a35bf2/mailnews/compose/src/nsSmtpProtocol.
> cpp#786

Looking at that code it's the opposite of what you say.
Right, if mail.strictly_mime==true, BODY=8BITMIME will not be sent.
(In reply to Jorg K (GMT+2) from comment #4)
> Right, if mail.strictly_mime==true, BODY=8BITMIME will not be sent.

It should be RFC-conform. So first of all, it is a server bug.

As a result of 'mail.strictly_mime=true', quoted-printable is used as content-transfer-encoding. Together with today's usual UTF-8 encoding, this is not a good idea. Especially not as a standard.

with mail.strictly_mime=false we use 8bit as content-transfer-encoding. But with ASCII only bodies it is 7bit. Perhaps that is the cause.

Firstly, we need to pinpoint what the real reason is.

@Ferry Huberts: Can you provide such a rejected mail?
The problem is not new.

<https://social.technet.microsoft.com/Forums/office/en-US/89abe56e-bebf-4b66-b235-9bbd3efb02fa/body-type-not-supported-errors?forum=exchangesvradminlegacy>

The comment from 'Rich Matheisen' describes what the problem is:
| It happens because Exchange 2003 will not try to encode a message into
| 7-bit MIME after it's accepted it in 8-bit MIME format. If the system
| to which you're sending the email doesn't advertise the 8bitmime
| keyword then Exchange has only two possibilities (per the RFCs):
[Here something is missing] 
| as undeliverable.
(In reply to Alfred Peters from comment #5)
> It should be RFC-conform. So first of all, it is a server bug.

Agreed, I'd vote against forcing quoted-printable encoding by default. Per discussion in bug 1032302, some servers don't advertise 8BITMIME but accept it anyway, so the question is if Exchange is even trying before deciding that it can't relay the message to the next MTA. Especially if it's happening down the road, not much the client can do other than switching to q-p encoding given that the relaying server isn't doing it for us, but it's the exception and not the rule.

Maybe relnote as a known issue with Exchange 2003 servers, assuming other servers aren't affected?
(In reply to rsx11m from comment #7)
> (In reply to Alfred Peters from comment #5)
> > It should be RFC-conform. So first of all, it is a server bug.
> 
> Agreed, I'd vote against forcing quoted-printable encoding by default. Per
> discussion in bug 1032302, some servers don't advertise 8BITMIME but accept
> it anyway, so the question is if Exchange is even trying before deciding
> that it can't relay the message to the next MTA. Especially if it's
> happening down the road, not much the client can do other than switching to
> q-p encoding given that the relaying server isn't doing it for us, but it's
> the exception and not the rule.
> 
> Maybe relnote as a known issue with Exchange 2003 servers, assuming other
> servers aren't affected?

Should be?
Yes, however, _reality_ says it doesn't work that way.
I've filed this bug to put your attention on it, and as I've said I'm seeing this error more and more.
It started a few weeks ago, and is happening more and more. So I'm assuming that it is not only exchange 2003.
I've never had this problem before, but now it is happening more and more.

Not fixing it makes the experience for the user unfriendlier.
Me, I will just always switch the config for all my TB instances because I know of the issue.
A regular user will have a hard diagnosing the problem.
(In reply to Ferry Huberts from comment #8)
> Should be?
> Yes, however, _reality_ says it doesn't work that way.
> I've filed this bug to put your attention on it, and as I've said I'm seeing
> this error more and more.
> It started a few weeks ago, and is happening more and more. So I'm assuming
> that it is not only exchange 2003.

Well, "my" reality that I haven't seen this error happening anywhere with any e-mails that I'm sending to, neither historically nor recently, with plenty of Exchange servers in-between (likely newer than 2003 though), and I don't want to send out UTF-8 e-mail messages bloated by q-p encoding.

Looking at this from another perspective, the question is what has changed on your installation or with your provider that may have prompted this issue. We have been sending the 8BITMIME keyword since the Thunderbird 45.x releases (and 8-bit bodies by default before), so it's surprising that suddenly a large number of servers seem to reject 8-bit encoding.

Did recipients you've sent messages fine before start to experience the rejection recently, and possibly at the same time, or are these all new recipients?

Does the same happen when you send to the same people, let's say, using a Gmail account?

> @Ferry Huberts: Can you provide such a rejected mail?

The undeliverable report (assuming that it was sent by e-mail) might be helpful for diagnosis as well, to see which servers were involved on the way (you can XXX over any identifying information that you do not want to post publicly).
(In reply to Ferry Huberts from comment #8)

> Should be?
> Yes, however, _reality_ says it doesn't work that way.

> Not fixing it makes the experience for the user unfriendlier.

Just for understanding:
There is no bug that we could fix. It is rather a chain of unfortunate circumstances.

In this mail transport are at last three servers involved.
A: Your provider to which you submit the email. This server has set the 8BITMIME keyword, otherwise we would not do it on our part.
(B: Some servers more)
C: The Exchange-Server that attaches too much importance to the keyword.
D: A historical server which could presumably still process 8-bit messages, but does not know the keyword.

Finally, a server that announces 8BITMIME should be able to convert an 8-bit message into a 7-bit message.
One of the servers in the chain does not. This plus the overzealous Exchange-Server are the real problem.

> Me, I will just always switch the config for all my TB instances because I
> know of the issue.
> A regular user will have a hard diagnosing the problem.

Returning to the Stone Age and sending only 7-bit messages is not a reasonable solution.

'mail.strictly_mime=true' does this.
(In reply to Alfred Peters from comment #5)
> As a result of 'mail.strictly_mime=true', quoted-printable is used as
> content-transfer-encoding.
Please always include some sort of reference, so others don't have to do the same research again. In this case
https://dxr.mozilla.org/comm-central/search?q=mime_use_quoted_printable_p
takes us to the interesting places.

I agree that setting QP as default is not desirable. Since this is the request here, this bug is a WONTFIX.

We're happy to discuss other solutions to the rejected e-mail problem in another bug.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
When I send an email the following servers are involved:
- My (very old CentOS 5) internal mail server takes care of the mail, and forwards it to
- My ISP's mail server, which then delivers it to
- The destination mail server.

Unfortunately I cannot provide a mail response with the error since I recently cleared out my trash box.

I'm a bit disappointed in the resolution here, but I'll just switch the config to suit me.
At least the information is now in a bug report so that others can find it :-)
See Also: → 1435903
You need to log in before you can comment on or make changes to this bug.