R. David Murray <rdmur...@bitdance.com> added the comment:

It does appear as though parseaddr is dropping quoting information from the 
returned parsed address.  Fixing this is likely to create backward 
compatibility issues, and I'm very curious to know why parseaddr drops the 
quoting info.

Note that I do not observe the change from test\com to test.com, so I'm 
assuming that was a typo and ignoring that part (or it represents a bug that is 
already fixed).

The "weird" example is actually consistent with the rest of parseaddr's 
behavior, if you understand that behavior as turning quoted pairs inside quoted 
strings into their literal value, but leaving the quotes around the quoted 
string(s) in place.

Consider the example:

  parseaddr('"\\\\"test\\\\" test"@test.com')

If we remove the Python quoting from this input string we have:

  "\\"test\\" test"@test.com

Interpreting this according to RFC rules we have a quoted string "\\" 
containing a quoted pair (\\).  The quoted pair resolves to a single \.  Then 
we have the unquoted text
 
   test\\

This parseaddr copies literally (I'm not sure if that is strictly RFC 
compliant, but given that we are supposed to be liberal in what we except it is 
as reasonable a thing to do as any.)  Finally we have another quoted string

   " test"

So putting those pieces together according to the rules above, we end up with:

   "\"test\\" test"@test.com

which is the observed output once you remove the Python quoting.  So, parseaddr 
is working as designed.  The question is, what is the design decision behind 
resolving the quoted pairs but leaving the quotes?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1050268>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to