[EAI] Comments on draft-ietf-eai-mailinglistbis-04

[SM <[e-mail]>]

Hi John,

Here are some comments about draft-ietf-eai-mailinglistbis-04.  The 
document uses a style which is easy to understand.  It tackles 
mailing lists and non-ASCII email addresses from a mail transport and 
message header perspective only.  I mentioned these points as there 
are other questions which MLM implementers take into consideration, 
e.g. for archival [1]:

   - Which identifier to use for the list [2]

   - Which identifier to use for a message

   - Compatibility with the NNTP environment [3]

There are questions such as de-duplication (how to prevent duplicate 
copies of a message), message digests, HTML downgrades, etc.  As all 
this is likely out of scope for EAI I am not suggesting that the 
document address these questions.

The main issue is what to do about mixed SMTPUTF8 and ASCII mailing 
lists (Section 2.2).  The idea of sending a probe message sounds practical.

In Section 2.2:

   "To determine whether a message needs to be downgraded for ASCII
    recipients, list software might assume that any message received via
    an SMTPUTF8 SMTP session is an SMTPUTF8 message, or might examine the
    headers and body of the message to see whether it needs SMTPUTF8
    treatment."

Why not test for "message/global" instead of inspecting message content?

In Section 3.1:

    "[RFC2919] specifies that "The list identifier will, in most cases,
     appear like a host name in a domain of the list owner."  Since
     these headers were defined in the context of ASCII mail, these
     headers permit only ASCII text including in the URLs.

I suggest moving the last sentence in that paragraph before the 
"[RFC2919]" sentence as it applies to the RFC 2369 header fields.

The List-Post: header needs the "mailto".  Part of the remaining 
(2369) List- headers (List-Unsubscribe:, List-Archive:, List-Help:) 
can be handled through HTTP.

The List-Id: header can be considered as an opaque string.  The 
information which is displayed can be passed as a comment.  That 
allows the issue of IDNs to be side-stepped.  You can also avoid the 
question of downgrading if you use a randomly generated string.

I would treat the 2369 and 2919 List- header separately as you have 
more leeway for the latter (see above paragraph).  Per-header issues 
could be identified and discussed on an issue-basis.

Section 3.2 discusses the "mailto" issue (re percentage sign and 
source routing).  There is one sentence about the IDN angle which 
does not say much.

In Section 3.3:

   "List software typically leaves the original submitter's address in
    the From: line, both so that recipients can tell who wrote the
    message"

I suggest author instead of submitter.

The Security Considerations section is going to raise 
questions.  Given the approach taken to discuss the subject, there's 
not much to say.

It's difficult to pick a solution for mailing lists.  I am not being 
critical about the trade-offs as I don't have a fix to suggest.

Regards,
-sm

1. The archives may be managed by the mailing list operator or by a 
third-party.

2. I assumed that RFC 2919 answered that question.  The implementer 
tried to devise
    a unique id even though there was a RFC published years ago about that.

3. http://packages.python.org/mailman/src/mailman/handlers/docs/nntp.html