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

[Murray S. Kucherawy]

> -----Original Message-----
> From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Stephen J. Turnbull
> Sent: Tuesday, November 15, 2011 8:02 PM
> To: Barry Warsaw
> Cc: mailman-developers at python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> 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.

Works for me.  If it includes the hostname where the mediator is running, it can go a long way toward debugging things like DKIM validation problems or other "What the hell happened to this message?" things.

But then again, if we go with the received-state idea, mailman could do what other MTAs do and write its name and version information in a comment in a Received field.

>  > >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

Incomplete thought here?

If the received-state idea is adopted, a second Received: is the perfect way to show when something entered an approval hold and when it came out, without registering a new header field dedicated for this purpose.

> 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.)
> [...]

If this is meant to be machine-parsable versus user-parsable, it'll need to be more rigid than that.  But I see where you're going.  Phrases in particular are a pain unless they're meant to be quoted strings that machines don't care about using.

So I guess we need to be clear on how these various new fields are expected to be used.

> Secret moderator IDs would serve to anonymize.

As long as the MLM keeps track of who they are so administrators can track actions, sure.

>  > 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.

I think RFC5598 suggests that the MLM re-mailing should generate a new Message-ID and a new Date, and observes the common Subject: tagging practice, but I don't think anyone expects the other stuff to be renamed to Resent-* first.

> 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).

As above, how are they typically consumed?  That might help to answer these questions.

-MSK