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
