Author r.david.murray
Recipients barry, jfinkels, r.david.murray, sdossey
Date 2010-10-01.17:31:54
SpamBayes Score 1.58282e-11
Marked as misclassified No
Message-id <>
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, 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"')

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

  "\\"test\\" test"

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

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"

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?
Date User Action Args
2010-10-01 17:31:56r.david.murraysetrecipients: + r.david.murray, barry, sdossey, jfinkels
2010-10-01 17:31:56r.david.murraysetmessageid: <>
2010-10-01 17:31:55r.david.murraylinkissue1050268 messages
2010-10-01 17:31:54r.david.murraycreate