email.Utils.parseaddr() gives arcane result

[msapiro]

BPO	1409460
Nosy	@warsaw, @msapiro, @devdanzin, @merwok, @bitdancer
Dependencies	bpo-1464708: fixed handling of nested comments in mail addresses

^{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 = 'https://github.com/warsaw'
closed_at = <Date 2009-03-20.23:51:04.861>
created_at = <Date 2006-01-18.22:19:07.000>
labels = ['library']
title = 'email.Utils.parseaddr() gives arcane result'
updated_at = <Date 2010-07-17.14:36:48.131>
user = 'https://github.com/msapiro'

bugs.python.org fields:

activity = <Date 2010-07-17.14:36:48.131>
actor = 'eric.araujo'
assignee = 'barry'
closed = True
closed_date = <Date 2009-03-20.23:51:04.861>
closer = 'ajaksu2'
components = ['Library (Lib)']
creation = <Date 2006-01-18.22:19:07.000>
creator = 'msapiro'
dependencies = ['1464708']
files = []
hgrepos = []
issue_num = 1409460
keywords = []
message_count = 7.0
messages = ['27314', '27315', '83892', '110548', '110556', '110558', '110562']
nosy_count = 5.0
nosy_names = ['barry', 'msapiro', 'ajaksu2', 'eric.araujo', 'r.david.murray']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1409460'
versions = ['Python 2.4']

[msapiro]

email.Utils.parseaddr('Real Name ((comment))
<addr...@example.com>')

returns

('comment <addr...@example.com>', 'Real')

Granted the string above is invalid as RFC 2822 does
not allow parentheses within comments, but most mail
agents seem to at least take the contents of the angle
brackets as the address in this case.

rfc822.parseaddr() returns the same result in this case.

If these functions aren't going to return their
respective failure indication in this case, I think
they should at least return 'addr...@example.com' as
the second item of the returned tuple.

Note that

parseaddr('Real Name <addr...@example.com> ((comment))')

does return

('Real Name', 'addr...@example.com')

as 'expected'.

[msapiro]

Logged In: YES
user_id=1123998

It looks like this is addressed by patch 1464708
http://sourceforge.net/tracker/index.php?func=detail&aid=1464708&group_id=5470&atid=305470

[devdanzin]

Fixed in trunk, so bpo-1464708 was probably forward ported.

[merwok]

I wonder if this bug should be reopened. This behavior does not seem right to me:

parsing 'merwok'
expected ('merwok', '')
got ('', 'merwok')

parsing 'merwok wok@rusty'
expected ('', 'wok@rusty')
got ('', 'merwokwok@rusty')

(Generated with a twenty-line script just doing a loop and prints, not attached because boring.)

Are my expectations wrong? I don’t know if a string like “merwok” in my first example is a legal address in the relevant RFCs, nor do I know if the folding done in the second example is okay.

For background, the thing I’m trying to achieve is to take a string and parse it into name and email address, and print a warning if there is no email. It’d be nice if I could always test for “not parseaddr(s)[1]”, or pass an argument to the function to get an exception. Maybe I’ll have to restrict my format and do my own parsing with str.[r]partition.

[msapiro]

parsing 'merwok'
expected ('merwok', '')
got ('', 'merwok')

I think ('', 'merwok') is the correct result. I think most if not all MUAs/MTAs will interpret an address without an '@', albeit invalid, as a local-part in the local domain, thus parsing 'merwok' as the address 'merwok' with no real name is probably the right thing to do with this input. The alternative would be to return ('', '') indicating failure.

parsing 'merwok wok@rusty'
expected ('', 'wok@rusty')
got ('', 'merwokwok@rusty')

Here, I think failure is a more appropriate return.

In any case, I think this is a new bug deserving of a new report. It is not really relevant to this issue which has to do with nested parentheses.

[merwok]

Thank you for the reply. The problem is that parseaddr is designed to not fail IIUC, that’s why it may return empty strings. Client code has to check for these values instead of catching an exception—a mere style issue, weren’t it for the second bug. So I’m going to report that separately, and restrict the format in my project so that my code can just use string methods. I think I won’t open a feature request for a parameter to get exceptions, since parseaddr is designed not to.

[merwok]

Copied my inquiry and part of your reply in bpo-9286.