Repository navigation
EmailMessage bad encoding for international domain #83938
Description
| BPO | 39757 |
|---|---|
| Nosy | @warsaw, @bitdancer, @Julien00859, @iritkatriel |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2020-02-26.09:36:15.270>
labels = ['3.11', 'type-bug', 'expert-email', '3.10', '3.9']
title = 'EmailMessage bad encoding for international domain'
updated_at = <Date 2021-12-13.17:50:29.456>
user = 'https://github.com/Julien00859'bugs.python.org fields:
activity = <Date 2021-12-13.17:50:29.456>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['email']
creation = <Date 2020-02-26.09:36:15.270>
creator = 'Julien Castiaux'
dependencies = []
files = []
hgrepos = []
issue_num = 39757
keywords = ['patch']
message_count = 5.0
messages = ['362687', '362801', '362802', '362906', '408472']
nosy_count = 4.0
nosy_names = ['barry', 'r.david.murray', 'Julien Castiaux', 'iritkatriel']
pr_nums = ['18667']
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39757'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
Julien00859 commentedon Feb 26, 2020
Affected python version: 3.5 and above (did test them all except 3.9)
Steps to reproduce:
It prints
But it should be
While b64/qp can be used to encode most non-ascii headers, the domain part of an email address is an exception. According to IDNA2008 (rfc5890 , rfc5891), non-ascii domain should be encoded using the punycode algorithm and the ACE prefix.
Julien00859 commentedon Feb 27, 2020
Duplicate of https://bugs.python.org/issue39757
Julien00859 commentedon Feb 27, 2020
Woops wrong copie/paste, here is the correct link: https://bugs.python.org/issue11783
bitdancer commentedon Feb 28, 2020
This is not actually a duplicate of 11783. Rereading (parts of) that issue, we decided we currently have no good way to do automatic conversion between unicode and internationalized domains, so the user of the library has to do it themselves. This means that the bug *here* is that the new email API is *wrongly* encoding the non-ascii in the domain by using an encoded word. I'm surprised at that; I thought I'd guarded against it.
What should be happening here is that an error should be raised when that header is set (or possibly when it is accessed/serialized, but when set would be better I think) saying that there is non-ascii in the domain part.
[-]EmailMessage wrong encoding for international domain[/-][+]EmailMessage bad encoding for international domain[/+]iritkatriel commentedon Dec 13, 2021
Reproduced on 3.11.
gh-83938, gh-122476: Stop incorrectly RFC 2047 encoding non-ASCII ema…