Repository navigation
email.Utils.parseaddr fails to parse valid addresses #40889
Description
Activity
email.Utils.parseaddr() does not successfully parse a
field value into a (comment, address) pair if the
address contains a source route with more than one hop.i.e., it is successfully parses this:
"God" <@hop1.org:jeff@spec.org>
to get the address <jeff@spec.org>, but it fails to do
the same if supplied with a 2-hop source route:"God" <@hop1.org,@hop2.net:jeff@spec.org>
In this case, it gets the comment ("God") right, but
fails to extract the address.Multi-hop source routes, while deprecated, are still
valid in rfc2822.- addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Sep 9, 2004 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Sep 9, 2004 - addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Jan 10, 2008 # A quick and very dirty fix for common broken cases, with test cases.
import rfc822 def parseaddr(t): """Split email into Fullname and address.
>>> parseaddr('user@example.com') ('', 'user@example.com') >>> parseaddr('"Full Name" <foo@example.com>') ('Full Name', 'foo@example.com') >>> parseaddr('spam@viagra.com <foo@example.com>') ('spam@viagra.com', 'foo@example.com') >>> parseaddr('"God" <@hop1.org,@hop2.net:jeff@spec.org>') ('God', 'jeff@spec.org') """ #return email.Utils.parseaddr(t) res = rfc822.parseaddr(t) # dirty fix for some broken cases if not res[0]: pos = t.find('<') if pos > 0 and t[-1] == '>': addrspec = t[pos+1:-1] pos1 = addrspec.rfind(':') if pos1 > 0: addrspec = addrspec[pos1+1:] return rfc822.parseaddr('"%s" <%s>' % (t[:pos].strip(),addrspec)) if not res[1]: pos = t.find('<') if pos > 0 and t[-1] == '>': addrspec = t[pos+1:-1] pos1 = addrspec.rfind(':') if pos1 > 0: addrspec = addrspec[pos1+1:] return rfc822.parseaddr('%s<%s>' % (t[:pos].strip(),addrspec)) return resOk, I see the '@' is technically not allowed in an atom. But it either
needs to throw an invalid syntax exception, or heuristically return
something reasonable.Repeating because previous real life test case was rejected as 'spam':
It also fails to parse: >>> from email.Utils import parseaddr >>> parseaddr('foo@spammer.com <bar@baz.com>') ('', 'foo@spammer.com')
Getting the wrong part as the actual email to boot! Checked 2.4 and 2.5.
Same or related issues: bpo-1221, bpo-1409460
Test cases so far: >>> parseaddr('user@example.com') ('', 'user@example.com') >>> parseaddr('"Full Name" <foo@example.com>') ('Full Name', 'foo@example.com') >>> parseaddr('spam@spammer.com <foo@example.com>') ('spam@spammer.com', 'foo@example.com') >>> parseaddr('God@heaven <@hop1.org,@hop2.net:jeff@spec.org>') ('God@heaven', 'jeff@spec.org') >>> parseaddr('Real Name ((comment)) <addr...@example.com>') ('Real Name', 'addr...@example.com') >>> parseaddr('a(WRONG)@b') ('', 'a@b')An example from bpo-1221:
>>> email.Utils.parseaddr("a(WRONG)@b") ('WRONG WRONG', 'a@b')tiran: yes, but that is the wrong answer, and that example is already in
the testcase list (with what I believe is the right answer).4 remaining items
from 3.6: >>> AddrlistClass('John Smith <john.smith(comment)@example.org>').getcomment() '' >>> AddrlistClass('John Smith <john.smith(comment)@example.org>').getdomain() 'JohnSmith'
totally messed up :)
looks like these were meant to be internal methods, retracting new issues
- added 4 commits that reference this issue
on Aug 25, 2024
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:
bugs.python.org fields:
Linked PRs
email.utils.parseaddrto handle multiple hops #123311