> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Stephen J. Turnbull
> Sent: Tuesday, November 15, 2011 8:02 PM
> To: Barry Warsaw
> Cc: [email protected]
> 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
[email protected]
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
