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.

Author jpic
Recipients barry, jpic, r.david.murray
Date 2019-07-03.10:12:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1562148740.76.0.680982453684.issue37492@roundup.psfhosted.org>
In-reply-to
Content
Following up bpo-34155[0] PR#13079[1], which changes:

    >>> parseaddr('a@malicious@good')

From returning:

    ('', 'a@malicious')

To return:

    ('', '')

As such, parseaddr behaves more like documented:

email.utils.parseaddr(address)
Parse address – which should be the value of some address-containing field such as To or Cc – into its constituent realname and email address parts. Returns a tuple of that information, unless the parse fails, in which case a 2-tuple of ('', '') is returned.

The pull request discussion suggested that it would be good to open a new bpo to discuss changing the following behaviour:

    parseaddr('a@b.')

From returning:

    ('', 'a@b.')

To return a tuple of empty strings as well.

We have not found RFC to back up that `a@b.` was not a valid email, however RFC 1034 states that dots separate labels:

    When a user needs to type a domain name, the length of each label is
    omitted and the labels are separated by dots (".").

As such, my understanding is that a valid domain must not end with a dot.

[0] https://bugs.python.org/issue34155
[1] https://github.com/python/cpython/pull/13079
History
Date User Action Args
2019-07-03 10:12:20jpicsetrecipients: + jpic, barry, r.david.murray
2019-07-03 10:12:20jpicsetmessageid: <1562148740.76.0.680982453684.issue37492@roundup.psfhosted.org>
2019-07-03 10:12:20jpiclinkissue37492 messages
2019-07-03 10:12:20jpiccreate