[Mailman-Developers] Mailing Lists and Non-ASCII Addresses

Joshua Cranmer pidgeot18 at gmail.com
Thu Nov 8 00:11:05 CET 2012


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 at 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)?

-- 
Joshua Cranmer
News submodule owner
DXR coauthor



More information about the Mailman-Developers mailing list