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: > > > >List-Received-Date > > 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. > >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 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). > >List-Archive-Send-Date 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 given out-of-band. _______________________________________________ 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