Support parameters for MAIL FROM and RCPT TO
I suggest extending
Net::SMTP#rcpto so they accept an additional optional Array or Hash of parameters.
Net::SMTP#open_message_stream, I suggest that in addition to a String email address (or arrays of Strings), these methods should accept a pair (or arrays of pairs) of
[addr, params], where
addr is the String email address, and
params is an Array or Hash of parameters.
In order for the parameters to be useful, we should expose the capabilities reported by
capable? should be made public.
Pull request: https://github.com/ruby/ruby/pull/3359
Updated by jeremyevans0 (Jeremy Evans) 8 months ago
Updated by c960657 (Christian Schmidt) 2 months ago
I must admit that I don't know how widely supported these are. I doubt they are widely used.
Introducing new standards is often a chicken-or-egg problem. Why would anybody spend time on implementing a standard that nobody else supports?
SMTP parameters is a general mechanism which is potentially useful also for future standards. If parameters were supported in Net::SMTP, early adopters could more easily start experimenting with new standards and in that way encourage others to do the same.
There has been talk about email addresses with non-ASCII characters on the left and right side of the @ sign for ages, and different approaches have been published in RFCs over the years. After a decade or two of patience, non-ASCII domains finally work in web browsers. Email is not there yet, but I feel confident that it will get there eventually, based on SMTPUTF8 or something else.
Both Gmail and Outlook.com announces support for SMTPUTF8 in their EHLO response, but AFAIK they do not allow users to create email accounts with non-ascii characters. I suspect they don't want to offer such addresses, because using such an address in practice is an uphill struggle due to lack of support in other parts of the email ecosystem (including Ruby-based applications :-)).
If Gmail started offering non-ascii email addresses tomorrow, Net::SMTP would not be able to send to those addresses in an RFC-compliant way. Gmail might just accept the addresses anyway without requiring SMTPUTF8 keyword, assuming that most SMTP servers just pass the 8-bit addresses through without validation. But trying to stick to RFCs seems like a safer choice.
This is a fairly new standard (RFC published in late 2019). That alone indicates that people in the RFC community considers this an important issue to address. I am somewhat skeptical whether REQUIRETLS will get enough traction. The issue of enforcing TLS in outgoing emails could be addressed in a simpler (but less flexible) way, e.g. using a global setting in the SMTP server.
Updated by duerst (Martin Dürst) 2 months ago
xtkoba (Tee KOBAYASHI) wrote in #note-9:
I am sorry that I cannot evaluate the importance of this proposal.
Are there any real-world use cases of
REQUIRETLSor any other optional parameters for
SMTPUTF8 is getting more and more supported. ICANN has an "Universal Acceptance" group that provides all kinds of resources. For example, you can check whether your email provider supports SMTPUTF8 at https://uasg.tech/eai-check/ (mine does, didn't know). More resources at https://www.icann.org/ua. It would be great if Ruby would support it, too. My understanding is that it gets used more and more in countries such as China and India,...