[Mailman-Developers] New RFC on using DKIM with MLMs
Murray S. Kucherawy
msk at cloudmark.com
Tue Nov 29 01:33:37 CET 2011
> -----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
> > 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.
More information about the Mailman-Developers