This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Double dots in quopri transported emails
Type: enhancement Stage: resolved
Components: email Versions: Python 3.11
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: barry, drlazor8, jev2, r.david.murray
Priority: normal Keywords: patch

Created on 2021-04-23 14:36 by drlazor8, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 25562 closed drlazor8, 2021-04-23 18:05
Messages (6)
msg391698 - (view) Author: Julien Castiaux (drlazor8) * Date: 2021-04-23 14:36

We received multiple bug reports about broken links in rich html emails. Sometime, in some emails, a link like <a href=""> would become <a href=">, notice the double dot.

After multiple researches both in the Python email source code and in the RFC, it turns out that Python correctly implements the standard but that the distant (non-python) smtp server used by some of our customers doesn't.

The various email standard state the following:

1) As a single dot (".", chr(0x2e)) in a line ends the SMTP transmission, such single dots must be escaped when they are part of the message. RFC 5321, section 4.5.2 requires to escape all dots when they appear at the beginning of a line, using a dot as escape symbol. That is, when the user message contains: "\r\n.\r\n", it is escaped to "\r\n..\r\n". The other smtp side is responsible to remove the extra dot.

2) When we transport the email body using the quoted-printable encoding, RFC 2045 requires each line to have maximum 78 characters and define a single equal ("=", chr(0x3d)) as soft-warp sequence to fold lines too long. The RFC does only require to split the line outside of a quoted character (cannot split in the middle of "=2E"). Like any other character, it is allowed to split the line before a dot.

Take the following example:

    from email.message import EmailMessage
    from email.policy import SMTP

    msg = EmailMessage(policy=SMTP)
    msg.set_context("Hello there, just need some text to reach that seventy-six character,")
    #                                                                                             ^
    #                                                                                         78th char

    # Content-Type: text/plain; charset="utf-8"
    # Content-Transfer-Encoding: quoted-printable
    # MIME-Version: 1.0
    # Hello there, just need some text to reach that seventy-six character, example=
    # .com

When the message is sent over smtp, smtplib escapes the line ".com" to become "" as required by the RFC. So no problem in the python implementation, it is the other side that is buggy.

But! We have two solutions to "fix" the other side, the problem is that they do not correctly parse lines starting with a dot. A solution would be to ensure no line starts with the dot character. Two solutions : (1) quoted-printable encode dots when they are at the beginning of a line, (2) prevent the line folding code from splitting a line before a dot.

(1) is allowed by the RFC, any character can be quoted-printable encoded even those that have a safe ascii representation already. In our "example=\" example above, we can qp the code: "example=\n=2Ecom". The line starts with a "2" instead of a dot and the content is the same.

(2) is allowed by the RFC, the RFC only states that a line must be at most 78 chars long, it also states it is allowed to fold a line anywhere but in a quoted-printable sequence. It is safe to split a line earlier than the 78th character. In our "example=\" example above, we could split the line at the 77th character: "exampl=\". The line starts with a "e" instead of a dot and the content is the same.

A pull request is coming shortly.
msg391707 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2021-04-23 16:51
Since python is doing the right thing here, I don't see a particularly good reason to put a hack into the stdlib to fix the failure of third party software to adhere to standards.  (On the output side.  We do follow Postel's rule on input and try hard to handle broken but recoverable input.)  I don't actually *object* to it, though, as long as it follows the standard on output, and is a *simple* change.

Please note that you can fix this locally by implementing and using a custom content manager.
msg391718 - (view) Author: Julien Castiaux (drlazor8) * Date: 2021-04-23 18:08
Hello David, thank you for your quick answer. I tried to keep it minimal with some unittests. Could you point me some resources to learn how to properly write a custom content manager ?
msg391726 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2021-04-23 18:53
As far as I know the only resources are the context manager docs and the source code.  The stdlib content manager can serve as a model.  I have to admit that it was long enough ago that I wrote that code that I'd have to re-read the docs and code myself to figure it out :)

I'm afraid I don't really have time to do a complete review, but at a quick glance your patch doesn't look too complicated to me.  Quick observation:  the comment should explain why the dot check is done, and that it isn't needed for rfc compliance.
msg392319 - (view) Author: Julien Castiaux (drlazor8) * Date: 2021-04-29 15:24
Hello David,

The third party smtp software that causes troubles have been identified ! We are still investigating how to fix the problem at its root, ultimately this "fix" would not even be necessary. I'll keep you informed, just don't review or close the PR yet.

msg392428 - (view) Author: Julien Castiaux (drlazor8) * Date: 2021-04-30 13:18
Fix deployed in the third party
Date User Action Args
2022-04-11 14:59:44adminsetgithub: 88088
2021-04-30 13:18:23drlazor8setstatus: open -> closed
resolution: third party
messages: + msg392428

stage: patch review -> resolved
2021-04-29 15:24:44drlazor8setmessages: + msg392319
2021-04-23 18:53:46r.david.murraysetmessages: + msg391726
2021-04-23 18:08:02drlazor8setmessages: + msg391718
2021-04-23 18:05:18drlazor8setkeywords: + patch
stage: patch review
pull_requests: + pull_request24281
2021-04-23 16:51:07r.david.murraysetmessages: + msg391707
2021-04-23 14:42:00jev2setnosy: + jev2
2021-04-23 14:36:50drlazor8create