On 11/6/2012 3:59 PM, Patrick Ben Koetter wrote:

Just published a few minutes ago:

     <http://www.rfc-editor.org/rfc/rfc6783.txt>

Probably worth to read before pushing MM3 out.

p@rick

Executive summary:

There are basically three orthogonal issues to worry about:

1. Do we accept messages that need SMTPUTF8 transport?
2. Do we accept non-ASCII people as subscribers?
3. Is our address non-ASCII?

If we answer "yes" to 1, we need to either require that all of our subscribers support SMTPUTF8 [detection is nontrivial, but user-initiated confirmation can do it] or we need to downgrade messages that we receive for non-SMTPUTF8 clients. It is also important to note that there is no way to properly downgrade an email address that is non-ASCII. Alternatives listed are:

• Require subscribers to list an ASCII fallback if a non-ASCII email

address is used

• Provide an ASCII forwarding address in the list software
• Rewrite the From (Sender, etc.) with our address and don't give a

proper From

If the answer to 3 is "yes", all of the munging of headers (this includes both Reply-To and List-*) may need to be prepared in both non-ASCII and downgraded form, and notes that percent-encoding of email addresses could cause spurious rejection of email addresses as invalid.

The second issue deals primarily with needing to construct non-ASCII envelopes for some subscribers, which is necessary anyways if 1 or 3 are both true.

In terms of code impact, it probably boils down to the following:

1. What do we do if we receive a non-ASCII mail delivered to a list?
2. How do we find out if subscribers support SMTPUTF8 transport?
3. What are implications for our configuration (server name and list name)?