[Mailman-Developers] New RFC on using DKIM with MLMs
Stephen J. Turnbull
stephen at xemacs.org
Wed Nov 16 05:02:10 CET 2011
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:
> > 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.
> > 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
-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).
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
More information about the Mailman-Developers