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.