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 r.david.murray
Recipients eric.araujo, r.david.murray
Date 2010-10-01.16:21:00
SpamBayes Score 7.553606e-07
Marked as misclassified No
Message-id <>
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 (, 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@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 :)
Date User Action Args
2010-10-01 16:21:02r.david.murraysetrecipients: + r.david.murray, eric.araujo
2010-10-01 16:21:02r.david.murraysetmessageid: <>
2010-10-01 16:21:01r.david.murraylinkissue9286 messages
2010-10-01 16:21:00r.david.murraycreate