> -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark....@python.org > [mailto:mailman-developers-bounces+msk=cloudmark....@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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9