[New-bugs-announce] [issue37492] should email.utils.parseaddr treat a at b. as invalid email ?

jpic report at bugs.python.org
Wed Jul 3 06:12:20 EDT 2019


New submission from jpic <jpic at yourlabs.org>:

Following up bpo-34155[0] PR#13079[1], which changes:

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

>From returning:

    ('', 'a at 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 at b.')

>From returning:

    ('', 'a at b.')

To return a tuple of empty strings as well.

We have not found RFC to back up that `a at 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

----------
components: email
messages: 347207
nosy: barry, jpic, r.david.murray
priority: normal
severity: normal
status: open
title: should email.utils.parseaddr treat a at b. as invalid email ?
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37492>
_______________________________________


More information about the New-bugs-announce mailing list