Mailing Lists and Non-ASCII Addresses

Just published a few minutes ago:
<http://www.rfc-editor.org/rfc/rfc6783.txt>
Probably worth to read before pushing MM3 out.
p@rick
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich

On Nov 06, 2012, at 10:59 PM, Patrick Ben Koetter wrote:
https://bugs.launchpad.net/mailman/+bug/1076152
Cheers, -Barry

On 11/6/2012 3:59 PM, Patrick Ben Koetter wrote:
Executive summary:
There are basically three orthogonal issues to worry about:
- Do we accept messages that need SMTPUTF8 transport?
- Do we accept non-ASCII people as subscribers?
- 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: proper From
- 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
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:
- What do we do if we receive a non-ASCII mail delivered to a list?
- How do we find out if subscribers support SMTPUTF8 transport?
- What are implications for our configuration (server name and list name)?
-- Joshua Cranmer News submodule owner DXR coauthor

On Nov 06, 2012, at 10:59 PM, Patrick Ben Koetter wrote:
https://bugs.launchpad.net/mailman/+bug/1076152
Cheers, -Barry

On 11/6/2012 3:59 PM, Patrick Ben Koetter wrote:
Executive summary:
There are basically three orthogonal issues to worry about:
- Do we accept messages that need SMTPUTF8 transport?
- Do we accept non-ASCII people as subscribers?
- 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: proper From
- 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
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:
- What do we do if we receive a non-ASCII mail delivered to a list?
- How do we find out if subscribers support SMTPUTF8 transport?
- What are implications for our configuration (server name and list name)?
-- Joshua Cranmer News submodule owner DXR coauthor
participants (3)
-
Barry Warsaw
-
Joshua Cranmer
-
Patrick Ben Koetter