Django generates invalid address on unicode characters in the local part of an e-mail address

[Mike Edmunds]

#25986 attempted to add support for non-ASCII characters in the local-part (username) of an email address, by encoding it as an RFC 2047 encoded-word. ​PR#6377 landed in Django 1.10.

However, RFC 2047 ​specifically prohibits using an encoded-word in an addr-spec (the username@domain portion of an email address). Encoded-words are only allowed in address display-names.

The resulting email address is not supported by any known MTA or email client, and the message will either bounce or just disappear undelivered.

To reproduce:

from django.core.mail import EmailMessage
email = EmailMessage(to=["jörg@example.no"])
print(email.message().as_bytes().decode())  # examine generated message
# ...
# To: =?utf-8?b?asO2cmc=?=@example.no
# ...
email.send()  # if you've set up a mailbox for jörg at example.no

Actual results: as above (no errors)

Expected results: no =?utf-8?... encoded-word in the generated To addr-spec. And an error on the call to send() (or message()) saying that a non-ASCII local-part is not supported.

There is no supported way to send to non-ASCII usernames using 7-bit email headers. That requires using 8-bit headers with the SMTPUTF8 extension under RFC 6530/6531/6532. (That new feature request is ticket #35714; this ticket is solely about removing the current buggy behavior.)

For more details see #25986 comments 12-13.

[Claude Paroz]

Looks legitimate.

[Mike Edmunds]

The patch for #35581 ​raises an error for non-ASCII local-parts in send() when using the SMTP EmailBackend.

Catching the error earlier, in message(), would require additional work.

[Mike Edmunds]

This was fixed when sending through Django's SMTP EmailBackend via #35581.

The ​Python bug affecting EmailMessage.message() serialization in general was recently ​fixed upstream and will be in Python 3.15 final. (Though it won't be backported to earlier Python versions.)

I don't think there's anything more Django reasonably can or should do about this, so I'm marking this fixed.