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/smtp: How to include friendly-from, friendly-to addresses? #32526

Closed
mcandre opened this issue Jun 10, 2019 · 2 comments
Closed

net/smtp: How to include friendly-from, friendly-to addresses? #32526

mcandre opened this issue Jun 10, 2019 · 2 comments

Comments

@mcandre
Copy link

mcandre commented Jun 10, 2019

Hi, I am trying to include "friendly" email addresses like Bob Dole <bob@web.com>, for example.

https://wordtothewise.com/2014/12/friendly-email-addresses/

However, net/smtp (or possibly Lotus Notes or Gmail) silently strips out the friendly portion. The actual, raw email in my inbox is addressed simply bob@web.com, where I want Bob Dole <bob@web.com>.

I wonder if there a specific syntax required for getting friendly addresses through the net/smtp Mail(), Rcpt() methods. Digging into the implementation code, however, it looks like the original authors may not have accounted for friendly addresses.

https://golang.org/src/net/smtp/smtp.go#L246

Looks like net/smtp's validation here is rather limited. No validation is performed for the addresses, neither the formal address nor any friendly portion. No RFC5322 regex is applied by net/smtp. Rather, only CRLF checks are applied.

https://www.ietf.org/rfc/rfc5322.txt

In any case, the email address that the Go user passes to Mail() or Rcpt() is automatically wrapped in angle brackets, mangling any friendly portion. At which point, Lotus Notes or Gmail seems to simply sanitize the address, dropping the friendly part entirely.

Third party libraries like https://github.com/emersion/go-smtp have copied and pasted code from net/smtp, and so have similar runtime behavior, unfortunately.

Can we please update the Mail(), Rcpt() code to account for optional friendly from and to addresses?

I realize that at this point in time, by having always wrapped the addresses in angle brackets, Go users will expect that to continue at least until Go v2 releases. So any patch to these methods can't simply pass the address through as written.

An updated implementation accounting for friendly addresses, would involve first splitting the argument into friendly and formal addresses, check for the existence of a friendly part, and only then insert angle brackets around the formal address, when not already present. And again, RFC5322 validation should probably be performed around each formal email address, in order to catch mistakes earlier.

Anybody know a third party library that does this better, instead of hardcoding angle brackets around these addresses? The current winner on Stack Overflow bypasses these methods and just writes the entire email as a byte array :P

https://stackoverflow.com/a/46369988/10251641

@ianlancetaylor
Copy link
Contributor

As far as I know the SMTP level just uses e-mail addresses without comments. When you talk about "friendly" e-mail addresses I think you are talking about the contents of the message, which is not the same as SMTP. SMTP is the transport layer that carries the message. Don't confuse the SMTP MAIL FROM and RCPT TO commands with what the user will actually see.

I'm going to close this issue because there is nothing to do. If you want to discuss this further, I recommend that you use a forum; see https://golang.org/wiki/Questions.

@mcandre
Copy link
Author

mcandre commented Jun 10, 2019

Thank you Ian.

Ah, I think I understand. I will try the From: ... syntax for friendly from in the message body, rather than the top level MAIL FROM header. Would be nice for the net/smtp library to provide for this out of the box. Anyway, I will give this manual way a try.

@golang golang locked and limited conversation to collaborators Jun 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants