[issue9286] email.utils.parseaddr returns garbage for invalid input

[R. David Murray]

R. David Murray <rdmurray at bitdance.com> added the comment:

In the first of your examples, parseaddr is correct (a lone token is considered a 'local' address per RFC).

The second one is prossibly wrong, but if so the correct way to interpret it is not clear.  If you read the RFC carefully (http://tools.ietf.org/html/rfc5322#section-4.4), spaces are allowed between the 'local part' and the domain in obsolete syntax (which must be accepted).  However, the space being elided here is between pieces of the local part.  Note that because the address is not in '<>', the whole string is the address, there's no name field.  The "correct" parse could be:

('', '"merwok wok"@rusty')

That is, we apply a 'be generous in what you accept' rule and assume the "s were forgotten.  However, perhaps a more sensible 'generous' rule would be to assume the '<>' were forgotten and return

('merwok', 'wok at rusty')

However, it is quite possible that the reason the space is being elided here has to do with handling the obsolete 'route' syntax.  If that is the case then parseaddr is probably correct.  It may be a while before I get around to understanding that part of the spec well enough to render a judgement, so in the meantime I'll assume parseaddr is correct.  Feel free to read the spec and render your own opinion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________