![](https://secure.gravatar.com/avatar/ce38ab6067b2c63d9ac27f0cbe105817.jpg?s=120&d=mm&r=g)
-----Original Message----- From: mailman-developers-bounces+msk=cloudmark.com@python.org [mailto:mailman-developers-bounces+msk=cloudmark.com@python.org] On Behalf Of Stephen J. Turnbull Sent: Tuesday, November 15, 2011 8:02 PM To: Barry Warsaw Cc: mailman-developers@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