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: Provide Address.String() alternative which only converts to RFC 5322 and does not encode as RFC 2047 #27908

Open
epelc opened this issue Sep 27, 2018 · 8 comments
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@epelc
Copy link

epelc commented Sep 27, 2018

The Address.String() method sometimes encodes as RFC 2047 after the 5322 formatting depending on the characters in the address. However some services (Ala sparkpost transmission api header fields) want RFC 5322 formatted addresses in UTF8 and not encoded as RFC 2047.

I'm not sure if the [quoting](
I don't think you can easily or safely reverse the 2047 encoding via the mime package because the code has two paths for quoting.
I think you'd want a String() method which basically returned before this.) is a part of rfc 2047 or not.

I know this isn't required to the use the api but I'm wondering if there are any other use case which wouldn't require RFC 2047 encoding as well. If so it might be worthwhile to add an additional string/format function.

@epelc
Copy link
Author

epelc commented Sep 27, 2018

For reference here are the sparkpost docs requiring no RFC 2047 encoding of header fields. I believe they do this because they are allows template/substitution variables within their headers.

Each header value is expected in the UTF-8 charset without RFC2047 encoding.
https://developers.sparkpost.com/api/transmissions/#header-header-notes

@katiehockman katiehockman added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 27, 2018
@katiehockman
Copy link
Contributor

/cc @bradfitz

@bradfitz
Copy link
Contributor

Could you provide some examples?

Any suggested method name?

@epelc
Copy link
Author

epelc commented Sep 27, 2018

I just looked through the rfc(5322) a bit and it refers to this syntax as name-addr

name-addr = [display-name] angle-addr
Section 3.4 https://tools.ietf.org/html/rfc5322#section-3

Maybe func (*Address) NameAddr() string I'm pretty sure go is against putting rfc numbers in names of things besides the time formatting vars and I don't think there are competing standards since rfc 2044 is just an encoding and not a formatting rfc afaik.

@bradfitz
Copy link
Contributor

bradfitz commented Oct 2, 2018

Name sounds fine. Feel free to send a change.

@gopherbot
Copy link

Change https://golang.org/cl/139077 mentions this issue: net/mail: adds NameAddr() stringmethod to return UTF8 RFC 5322name-addr formatted addresses

@andrius4669
Copy link
Contributor

RFC 6532 section 3.2 specifically allows this, so I believe it should be documented as such; RFC 5322 on itself doesn't specify raw UTF-8 in addresses.

@smasher164
Copy link
Member

@epelc Any update on this? Is there still a desire for this to get in 1.14? I see some unaddressed comments on the CL.

@smasher164 smasher164 added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 8, 2019
@bradfitz bradfitz added this to the Backlog milestone Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

6 participants