New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/mail: ParseAddress should support UTF-8 (RFC 6532) #14260
Comments
/cc @dsymonds @alexcesaro |
RFC 6532 is really an extension of RFC 5322, which we claim to support, so it seems fine to permit the extensions that RFC 6532 defines. I'm not keen on net/mail going out of its way to parse broken mail messages; it just makes it harder to use for the non-broken cases. |
Ok, sounds good. I'll take a stab at updating the parser to accept UTF-8 multibyte-characters too. (I'm happy for serialization to continue using q-encoding for such names). |
I agree. I don't think the stdlib should handle broken input. Fixing broken emails should be the role of third-party packages. |
I've submitted a CL https://go-review.googlesource.com/19687, would appreciate any feedback you have. |
CL https://golang.org/cl/19687 mentions this issue. |
I'm using go v1.5.3, and parsing emails found in the wild (from senders like Linkedin and Gmail).
They expect to be able to include UTF-8 in email headers without q-encoding, but this is not currently supported by
mail.ParseAddress
.There are two possible solutions:
My experience from working on the
mail
gem for ruby would suggest that the second approach is the most pragmatic — often times email is badly formed, and it's really useful to be able to provide a "best-effort" parsing of badly formed email headers. However it seems like the go project tends a little bit more towards correctness, in which case the first approach may sit better in the standard library, and people who want the fuzzy behaviour can do it themselves.The text was updated successfully, but these errors were encountered: