[Mailman-Developers] New RFC on using DKIM with MLMs

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote:
 > 
 > >I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598
 > ><http://www.rfc-editor.org/in-notes/rfc5598.txt> instead:
[...]
 > 
 > That makes a good case for Mediator.

+1, but only for the case of modification IMO.

 >Adding a second header might make the useful distinction:
 > >
 > >List-Received-Date
 > >        RFC 2822 date timestamp when message was received by MLM

I think this is best done with an RFC 5321 Received header as Murray
suggests, even though I don't really think of MLMs as MTAs (or MUAs
for that matter).  OTOH, RFC 5321 requires that MTAs be pretty lenient
about the presence of non-standardized trace headers, and specifically
forbids altering them IIRC.

 > >List-Approved-Date
 > >        RFC 2822 date timestamp when message was approved by moderator
 > 
 > What if the message is automatically approved?  Does it get a
 > List-Approved-Date header?  Merging with Murray's concept of Received states,
 > it might just make more sense to put all that information into Received
 > headers.

-1 on using "Received" for approvals.  The approval 

Also (per site or list policy) I would suggest that instead of a
family of List-Approved-* headers, there should be a single
List-Approved header with variable format.  If present, it MUST
contain an action ("Approved", "Denied", "Rejected", "Held"), MUST
contain "at" and a timestamp, MAY contain "because" and a rule ("list
member", "moderator", "spam score exceeded threshold"), and MAY
contain "by" and a moderator ID (arbitrary token, could be a name, a
numerial ID, or generic tokens like "mailman" (the name of the MLM in
general), "list-owner", "moderator").  (I'm not wedded to the field
tags, of course.)

The actions other than "Approved" would be used in cases where
non-approvals are sent to the list or site owner for debugging
purposes etc.  Maybe "List-Action" or "List-Approval" or some such
would be a better field tag.

I would suggest that it be inserted into the trace stream "as if" it
were a "Received" header (or maybe before the Resent-* cluster?)

 > >I see the benefit because it helps if you moderate in a team. But
 > >I fear the anger of people whose postings we decline. They search
 > >for moderator identities

Secret moderator IDs would serve to anonymize.

 > We can't use Keywords, because that header is already used as input
 > to various functions such as the topic tagger.

Worse, it's already standardized by RFC 5322.  In general, I take a
dim view of a MLM hijacking any headers standardized by RFC 5322;
those headers are basically for use of *authors*, though the common
practice of adding various tags to Subject doesn't bother me *too*
much, and exceptions might need to be made for Date and (especially)
Message-ID, although maybe the MLM can just add those as Resent-*
fields and abdicate responsibility if the user did.

 > We have to use a different header for "output".  I can't think of
 > anything better than List-Tags though.

What's wrong with List-Topics or List-Keywords?  List-Tags is OK, I
guess, but I think of tags as user-provided information for other
users (not necessarily provided by the author, and not necessarily
usable for automatic association of different posts).

 > >List-Archive-Send-Date

How about just List-Archived, make it a formatted field "in[to]
$ARCHIVE at $TIMESTAMP", and let the sent/received distinction be made
by using the standard trace header of "Received" (as already
suggested)?  The "in" version is used when ARCHIVE contains a
user-accessible URL (either generic for the list or post-specific), and
"to" is for cases where the user URL is not necessarily known but the
message is sent "to" an archiver and information about user access is
given out-of-band.