[Mailman-Developers] New RFC on using DKIM with MLMs
Patrick Ben Koetter
p at state-of-mind.de
Sat Oct 29 06:39:22 CEST 2011
* Barry Warsaw <barry at list.org>:
> On Oct 28, 2011, at 10:36 PM, Patrick Ben Koetter wrote:
>
> >> >> From Mailman/Handlers/CookHeaders.py:
> >> >>
> >> >> msg['X-Mailman-Version'] = mm_cfg.VERSION
> >> >>
> >> >> Seems to add the product version and not the User-Agent.
> >> >
> >> >Yes, but a User-Agent, header would have the product and the product version.
> >> >A List-Agent header should do the same.
> >>
> >> List-Agent is not a bad idea.
> >
> >It's not available in RFC 2369. We will have to propose 'List-Agent' as a new
> >standard. Should we?
>
> I think it makes sense to have a header identifying the MLM that the message
> flowed through, and List-Agent seems like a good choice.
Let me merge Stephen's comment from <87obx04ocb.fsf at uwakimon.sk.tsukuba.ac.jp>
to stick with a more generic term such as 'User-Agent'.
While I disagree with having Mailman be a User-Agent, I can't actually
say there are useful semantics to having a separate List-Agent. Nor
do I see a real problem with having multiple User-Agent headers, if
multiple agents have handled the message.
I agree with Stephen that List-Agent is too specific leaving no semantic room
for other types of message processing software. At the same time I think
User-Agent is not apt, because RFC 1945 defines a User-Agent as originator,
which is not the case with any MLM - it distributes a message which originated
somewhere else:
The User-Agent request-header field contains information about the
user agent originating the request.
-- http://www.ietf.org/rfc/rfc1945.txt
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:
A Mediator attempts to preserve the original Author's information in
the message it reformulates but is permitted to make meaningful
changes to the message content or envelope.
A Mediator's role is complex and contingent, for example, modifying
and adding content or regulating which Users are allowed to
participate and when. The common example of this role is a group
Mailing List.
(see section "2.1.4. Mediator" and also section "5. Mediators")
A 'Mediator' would leave the original User-Agent intact AND tell the message
had been processed by another mail handling service AND it would allow for
other Mediators to be added in case more mail processing was done after an
MLM's (here: Mailman) job.
> >> >>>> X-Mailman-Approved-At
> >> >>
> >> >> From Mailman/ListAdmin.py:
> >> >>
> >> >> # Queue the file for delivery by qrunner. Trying to deliver the
> >> >> # message directly here can lead to a huge delay in web
> >> >> # turnaround. Log the moderation and add a header.
> >> >> msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1
> >> >
> >> >So, I guess that the web moderation works by adding this header, so that
> >> >the message can be delivered when the queue runner sees it. It looks like
> >> >useful trace information, so it should stay.
> >> >
> >> >This also looks like a candidate for, say, a List-Approved-Date header.
> >
> >It's not available in RFC 2369. We will have to propose 'List-Approved-Date'
> >as a new standard. Should we?
>
> I also think it makes sense to have a date header marking the time when the
> message was approved. This implies of course that the message was held for
> moderation. Would there be a L-A-D header if the posting was automatically
> accepted? Maybe the header should be List-Posted-Date, although there some
> subtly different semantics implied by that. E.g. if the date the message was
> approved isn't quite the date the message was posted (idk, some delay from
> moderator acceptance to actually posting through the MLM).
Hmm, if there are no intermediate processes between receiving a message and
approving it a List-Approved-Date seems fine. But if there are we run into the
same problem as described below with List-Archived-Date - you can't tell when
it was queued and when processing took place.
Adding a second header might make the useful distinction:
List-Received-Date
RFC 2822 date timestamp when message was received by MLM
List-Approved-Date
RFC 2822 date timestamp when message was approved by moderator
> Another header that might be useful here would be List-Approved-By which could
> be the name or email address of the moderator who approved it. Right now, MM3
> doesn't fill that in, and it could of course be filled in by say
> list-owner at example.com, but in MM3 it could be potentially filled in with the
> preferred address for the moderator that approved it.
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 and then start molesting them e.g. by subscribing them to mailing
lists that don't require opt-in. (Happend to me python.org postmaster. The
angry person subscribed my address to various pr0n mailing lists and it took
me weeks to get unsubscribed.)
All this said, I'd say the policy should be to add it as an optional header
field.
> >> >> From Mailman/Handlers/Tagger.py:
> >> >>
> >> >> # For each regular expression in the topics list, see if any of the lines
> >> >> # of interest from the message match the regexp. If so, the message gets
> >> >> # added to the specific topics bucket.
> >> >
> >> >So, is this used by Mailman to decide who to send the message to? Or is it
> >> >supposed to help recipients to build filters. Either way, it might be useful
> >> >for the latter purpose. Perhaps it's a candidate for List-Topics?
> >>
> >> Are there any other MLMs that support topics in a way that would make that
> >> header generally useful?
> >
> >Not that I am aware of. But maybe we could give it a more generic view. I
> >could imagine calling them 'Tags', which would make them usable in any
> >protocol that sends headers.
>
> Hmm, adopting a hash-tags format here would be kind of interesting for interop
> with social networking sites. It wouldn't have to be reflected in the name of
ACK with the notion that hashtag seems to closely realted with twitter and a
more general 'tag' would stay away from that.
Is there or should there be a distinction between 'tag' and http 'keywords'
<http://en.wikipedia.org/wiki/Meta_element#The_keywords_attribute>? Should we
use 'keywords' instead?
> the header, but it could be SHOULD in the spec. I ought to be pretty trivial
> for MM3 generate hash-tags here.
>
> What's interesting of course is that the Mailman module that fills this
> information in is the tagger handler.
There you go ... ;)
> >> >> From the changelog:
> >> >> The archived copy of messages grows an X-List-Received-Date:
> >> >> header indicating the time the message was received by
> >> >> Mailman.
> >> >>
> >> >>
> >> >> # Always put an indication of when we received the message.
> >> >>
> >> >> Seems to decide where messages should be archived
> >> >
> >> >I think that's a candidate for a List-Archived-Date header. Because that's
> >> >potentially helpful for people looking to find the message in an archive.
> >>
> >> Possibly so, if it's a header added by the MLM. E.g. an archiver might have
> >> its own "archive date" value so it would either have to chose a different
> >> header, or use multiple instances (with the loss of fidelity).
> >
> >When I read 'List-Archived-Date' I understand it specifies the date the
> >message had been archived by some archival software and not the date is was
> >sent to the archive by an MLM.
>
> Yep, to me too.
>
> >That makes a difference to me because copying the message to an archive might
> >not be the only way to transport it there. The MLM might as well use an LMTP
> >transport and queue it up for delivery. The queued message might get stuck in
> >a delivery queue for hours. Being able to tell the difference between 'sent
> >off to' and 'stored at' might be very useful to a postmaster when debugging
> >archival problems.
>
> Agreed.
>
> >Choosing a more specific header field would probably also avoid getting into
> >an archivers way when it creats an "archive date" value as Barry mentioned
> >above.
> >
> >Not sure. Am I overly pedantic on this?
>
> No, I think it's an important distinction. Also note that in MM3 you can
> actually have any number of archivers, so I think you want a field that
> clearly describes the actions of the MLM. I'm not sure what that would be
> other than List-Archived-Date though. :/
>
> Suggestions?
List-Archive-Send-Date
'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we
needn't care, as it will only be added to messages that go to the
archive, right?
Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer
Marks the beginning in opposition to Archive-Received-Date or
Archive-Received. But then again an archiver could simply add a
Received:-header!
Not an easy one.
p at rick
--
state of mind ()
http://www.state-of-mind.de
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
More information about the Mailman-Developers
mailing list