net/mail: Empty quoted display name should be allowed in email address #14866
Description
- What version of Go are you using (
go version)?
1.5.3.
- What operating system and processor architecture are you using (
go env)?
Linux, amd64
- What did you do?
Pass an email address with an empty quoted name, like:
"" <[email protected]>
to mail.Parse()
- What did you expect to see?
The email address should parse without error
- What did you see instead?
Error returned: mail: missing word in phrase: mail: empty quoted-string
- Further info
We don't experience this problem on Go 1.4. I found that the offending change was in commit bd1efd5. The first release containing this change was 1.5, which corroborates the difference I've seen between the behavior in 1.4 and 1.5.
The change in consumeQuotedString, given the tests that were added along with the change, intends to disallow an empty quoted string in the username part of the email address. However, it unintentionally also disallows an empty quoted string as the display name part of the email address -- but as far as I can tell, an empty quoted string there is perfectly valid. Since the tests did not address the case of an empty quoted name, I assume that it was an oversight. consumeQuotedString is used in these different contexts, and should not always disallow an empty quoted string. It should allow an empty quoted string when it's a part of the display name portion of an email address.
RFC5322 section 3.2.4 defines quoted string as:
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
Given that qcontent is attached to a *, which allows for zero or more occurrences, then the zero occurrences case results in an empty quoted string, which is allowed by this definition. Thus, Go should allow empty quoted strings in email addresses, at least in the case of the display name.
For what it's worth, we're using the github.com/go-gomail package to create the message. If you pass it an empty name, it always puts "" before the <address> part (see responsible function here), and while this is annoyingly triggering this bug in Go, it does seem to be perfectly valid as far as the RFCs are concerned.
Even if my interpretation of the RFC were wrong and current Go behavior is right, the tests are clearly not thinking about this specific case, and they should be expanded to do so.
Here is a play.golang.org reproduction of the bug: http://play.golang.org/p/iSjSINU-Dm