[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