[#104004] [Ruby master Feature#17883] Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile — mame@...
Issue #17883 has been reported by mame (Yusuke Endoh).
21 messages
2021/05/24
[ruby-core:103829] [Ruby master Feature#17047] Support parameters for MAIL FROM and RCPT TO
From:
bugs.ruby-lang.org@...
Date:
2021-05-13 08:55:21 UTC
List:
ruby-core #103829
Issue #17047 has been updated by c960657 (Christian Schmidt). 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. Regarding SMTPUTF8: 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. Regarding REQUIRETLS: 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. ---------------------------------------- Feature #17047: Support parameters for MAIL FROM and RCPT TO https://bugs.ruby-lang.org/issues/17047#change-91947 * Author: c960657 (Christian Schmidt) * Status: Open * Priority: Normal ---------------------------------------- ## Proposal In `Net::SMTP`, add support for parameters for `MAIL FROM` and `RCPT TO`, such as [SMTPUTF8](https://tools.ietf.org/html/rfc6531) and [REQUIRETLS](https://tools.ietf.org/html/rfc8689). I suggest extending `Net::SMTP#mailfrom` and `Net::SMTP#rcpto` so they accept an additional optional Array or Hash of parameters. For `Net::SMTP#send_message` and `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 `EHLO`, so `capable?` should be made public. Pull request: https://github.com/ruby/ruby/pull/3359 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>