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
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 wantBob 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()orRcpt()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