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.

# 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 res

Ok, 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: Issue1221, Issue1409460

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 #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).

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