Subject: Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01

From: "John Levine" <[email-masked]>
Date: 6 Jan 2012 06:39:34 -0000

>for feedback from a mailman developer and other MLM implementors.

Hi.  I guess I'm a defacto mj2 implementer.

>>1) Have the original authors of these documents been contacted to 
>>see if they want to
>
>I emailed to the original authors.  If anyone has an up to date 
>contact for them, please email me. 

Josh Baer is easy enough to find, once you know he's the one in Austin,
not the art critic.

General comments on 2369bis:

It's basically fine, but I have a few suggestions.  As an editorial
matter, the constant harping to use mailto: everywhere gets old.  I'd
suggest saying it up front and noting that mail users aren't
necessarily able to use any other kind of URI, then drop it.  The
other 99.9% of mail users, of course, find a web page a lot easier
than trying to send mail and hope for a response.

Section 4 seems obsolete.  Does anyone use nested lists any more, at
least nested lists visible to the users?  The idea used to be to save
bandwidth by sending one copy of a list message to an exploder closer
to the users, but I don't know anyone who still does that.  You can
get pretty much the same effect by sorting the deliveries by target
MX, and then send one copy per MX with multiple MAIL TO.

Appendix B strikes me as MUA user interface design advice by people
who know nothing about UI design.  I'd just drop it, or replace it
with a short note that the plan is for MUAs to recognize and interpret
the list headers and use them to present a list management interface
to the user that matches the rest of the MUA's interface.

>>3) The deletion of Appendix A from RFC2369 is conspicuous.  Why 
>>remove all of that supporting discussion?

Because it's not very interesting any more.  I suppose you could put
in a sentence saying that the design discussion in RFC 2369 may
be useful to help understand the design of list headers.

>>7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no 
>>need" sentence seems odd.  If the MUA is supposed to use 
>>"postmaster" to contact the owner in the case of a list that doesn't 
>>add this, what domain name should it use?

I agree that's wrong.  Just add the fripping header, please.

>I have not tested whether existing implementations bounce user 
>generated messages which contain List- headers.

mj2 typically deletes and replaces them.  In theory it could recognize
and bounce, but I don't know anyone who's configured it that way.

Comments on 2919bis:

In sec 2, the list ID is typically a hostname in the domain of the
list itself, not of the list owner.  I run lists with addresses like
[email-masked], but I as the owner have an address in
another domain.

In sec 3, most of the places it refers to the MUA are at least as
applicable to the MDA.  I do all of my list sorting at delivery time,
not in the MUA, and I suspect a lot of SIEVE users do the same.

Sec 7, I still think nested lists are dead.

>Subject tags are commonly used as list identifiers (this mailing list 
>uses them).  Appendix A.1 explains the difference between a List 
>Identifier and a subject tag in terms of uniqueness.  If I have to 
>provide an explanation, I would have to get into mail filtering, e.g. 
>why use List-ID instead of subject tags to move messages from this 
>mailing list into a separate mailbox.

I'd just point out that the subject is associated with the message,
not the list.  As a concrete example, if I send a personal reply
to the author of a list message, the subject will still have the
list tag, but it won't have a list-ID.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Jan 2012 04:40:36 -0000

>Nested lists did not disappear because of a definition.  It is 
>because people do not know about it, that they prefer simple things, 
>or that the sites that used it no longer have a need for it.

Nested lists were an imperfect way to do traffic management, with the
idea that the addresses on each sublist were "close" in some sense to
the sublist's exploder.  That made sense back when lists had a mixture
of uucp, BITNET, and Internet users, or when the connection from the
US to Japan was slow and expensive, but these days nobody cares.  It's
the same reason that we no longer make a big fuss when people use MUAs
that put 100K of ugly stationery on their mail.

I'm not adamant about removing it, but it does seem to provoke
more confusion than useful advice these days.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Jan 2012 16:52:28 -0000

>> There is a discussion about variable substitution in Appendix A.5 of
>> RFC 2369.  It explains why that was not added.  I'll leave this comment
>> open.
>
>It could well be that there isn't any demand for being able to do this (or as John mentioned in REPUTE,
>Apache mod_rewrite makes this kind of thing unnecessary).

I'm pretty sure the motivation was the desire to do something like this:

List-Unsubscribe: mailto:[email-masked]?body=unsub%20<ADDRESSTHISWASSENTTO>

These days since it's considered normal to send a customzed version of
the message to each subscriber, the variables can be substituted in at
the sending end, and you don't need a standard for that.

R's,
John