[Mailman-Developers] New RFC on using DKIM with MLMs

Patrick Ben Koetter p at state-of-mind.de
Fri Oct 28 22:36:02 CEST 2011


I've begun to sort the various comments into a list that sorts all changes in
categories like 'decide', 'delete', 'modify', 'keep'. I will send it to
mailman-developers at python.org once I've clarified a few header fields.

As a reference I looked for existing list-relevant header fields in RFC 2369
<http://www.rfc-editor.org/rfc/rfc2369.txt>, which doesn't seem to have seen
an update in a while.

All my comments to List-* headers refer to RFC 2369. Please find them below
including some minor nitpicking at the end.


* Barry Warsaw <barry at list.org>:
> On Oct 27, 2011, at 02:29 PM, Ian Eiloart wrote:
> Note that I responded in the context of Mailman 3.  We have an opportunity
> there to clean that all up, but it probably isn't a good idea to radically
> change these for MM2.

ACK. I'd keep MM2 as it is and introduce changes for MM3 only.


> >> 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?


> >>>> 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?


> >> 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. 


> >> 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.

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.

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?

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