Skip to content
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

Closed
ConradIrwin opened this issue Feb 8, 2016 · 6 comments
Closed

net/mail: ParseAddress should support UTF-8 (RFC 6532) #14260

ConradIrwin opened this issue Feb 8, 2016 · 6 comments
Milestone

Comments

@ConradIrwin
Copy link
Contributor

@ConradIrwin ConradIrwin commented Feb 8, 2016

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:

  • We can update the parsing functions to allow only valid UTF-8 as defined by RFC 6532,
  • OR, we can allow arbitrary 8-byte strings, and allow the caller to decide whether it cares about the encoding of the returned string.

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.

@bradfitz bradfitz changed the title mail.ParseAddress should support UTF-8 (RFC 6532) net/mail: ParseAddress should support UTF-8 (RFC 6532) Feb 8, 2016
@bradfitz bradfitz added this to the Unplanned milestone Feb 8, 2016
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 8, 2016

@dsymonds
Copy link
Member

@dsymonds dsymonds commented Feb 8, 2016

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.

@ConradIrwin
Copy link
Contributor Author

@ConradIrwin ConradIrwin commented Feb 8, 2016

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

@alexcesaro
Copy link
Contributor

@alexcesaro alexcesaro commented Feb 9, 2016

I agree. I don't think the stdlib should handle broken input. Fixing broken emails should be the role of third-party packages.

@ConradIrwin
Copy link
Contributor Author

@ConradIrwin ConradIrwin commented Feb 19, 2016

I've submitted a CL https://go-review.googlesource.com/19687, would appreciate any feedback you have.

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 19, 2016

CL https://golang.org/cl/19687 mentions this issue.

@bradfitz bradfitz modified the milestones: Go1.7, Unplanned Apr 5, 2016
@gopherbot gopherbot closed this in 7f52b43 Apr 15, 2016
@golang golang locked and limited conversation to collaborators Apr 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.