[Mailman-Developers] New RFC on using DKIM with MLMs
Ian Eiloart
iane at sussex.ac.uk
Thu Oct 27 16:29:28 CEST 2011
On 26 Oct 2011, at 16:33, Patrick Ben Koetter wrote:
> I searched mailman 2.1.14 sources and changelog to find out what they stand
> for. Read below. Which could/should we replace with already existing
> standardized headers?
>
> * Ian Eiloart <iane at sussex.ac.uk>:
>> On 25 Oct 2011, at 02:04, Barry Warsaw wrote:
>>
>>> On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote:
>>>
>>>> There's movement afoot to deprecate use of "X-" in header field names. Just
>>>> call it "Mailman-Topic". And if it's worthwhile, consider registering it
>>>> with IANA.
>>>
>>> I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of
>>> ones we still add or recognize (some might be used only in the test suite):
>>>
>>> X-Message-ID-Hash
>>
>> This could be replaced with DKIM sigs, I guess.
>>
>>> X-Mailman-Rule-Hits
>>> X-Mailman-Rule-Misses
>>
>> This might be useful for diagnostics, but probably wants to be off in
>> general. My view is that Mailman should not be doing message filtering.
>
> Are they related to SpamAssassin filtering that can take place in MM?
>
>
>>> X-BeenThere
>>
>> I guess that's useful for avoiding list loops, perhaps?
>
> From Mailman/Handlers/CookHeaders.py:
>
> # Mark message so we know we've been here, but leave any existing
> # X-BeenThere's intact.
The message that I'm replying to carried this header:
X-Beenthere: mailman-developers at python.org
I guess that should stay, then. Unless we find a different place to put it. Moving it to a different place probably would not cause problems, depending on how it's used. If the header means "don't relay the message to this address", then there would be problems. If it means "drop this message, if you are mailman-developers at python.org" then it can be moved.
>
>>> X-Mailman-Version
>>
>> I think this should be replaced with X-Mailer, or even User-Agent. That's
>> not currently an SMTP header, but I think it should be. And it is in quite
>> widespread use.
>
> 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.
>>> 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.
>
>>> X-Archive
>>
>> Does this do the same as List-Archive?
>
> Looks like a control feature for senders:
>
> From doc/mailman-admin.txt:
>
> Note that senders can control whether their own posts are
> archived, on an individual per-message basis. If the posted
> message has a X-No-Archive: header (regardless of value), or a
> X-Archive: header with a value of No (case insensitive), then
> the message will not be archived, although it will be treated
> as normal in all other ways.
>
>
> From the changelog:
>
> o When a moderated message is approved for the list, add an
> X-Mailman-Approved-At: header which contains the timestamp
> of the approval action (changed from X-Moderated: with a
> different format).
>
> - Honor "X-Archive: No" header by not putting this message in the
> archive.
Ah, well that's also a feature that various lists might want to implement. However, List-Archive says where archives are kept. Also, I guess an MUA is never going to have a guarantee that an MLM will honour a request. To use a List-* header might confuse, since all other List-* headers are added by the MLM.
Actually, I think that perhaps it and X-No-Archive could be deprecated. Does anyone actually use them?
>>> X-No-Archive
>>
>> What does this mean?
>
> Seems like a dupe from X-Archive:
> From the changelog:
>
> o Just the mere presence of an X-No-Archive: is enough to
> inhibit archiving for this message; the value of the header
> is now ignored.
>
See above.
>
>>> X-Ack
>
> From the changelog:
> - Autoresponses, -request command responses, and posting hold
> notifications are inhibited for any message that has a
> Precedence: {bulk|list|junk} header. This is to avoid mail
> loops between email 'bots. If the original message has an
> X-Ack: yes header, the response is sent.
>>> X-No-Ack
>
> Is this still being used?
>
> Nothing in the changelog
> Nothing in the mailman-2.1.14 sources.
I think X-Ack and X-No-Ack could be deprecated. Just advise people to use the correct precedence.
>>> X-Peer
>
> Is this still being used?
>
> Nothing in the changelog
> Nothing in the mailman-2.1.14 sources.
I guess that should be deprecated, then!
>>> X-MailFrom
>
> Is this still being used?
>
> Nothing in the changelog
> Nothing in the mailman-2.1.14 sources.
I guess that should be deprecated, then!
>
>>> X-RcptTo
>
> Is this still being used?
>
> Nothing in the changelog
> Nothing in the mailman-2.1.14 sources.
I guess that should be deprecated, then!
>> Isn't that usually in the Received header?
>>
>>> X-Originally-To
>>
>> Doesn't that do the same thing as List-post?
>
> Seems like a copy of Postfix' X-Original-To-header. Is it?
>
> From cron/gate_news:
>
> del msg['X-Originally-To']
> msg['X-Originally-To'] = msg['To']
Does Mailman 3 gate news?
>
>>> X-Original-CC
>> What's the purpose of including this?
>
> From Mailman/Defaults.py.in:
>
> # Next, these headers are left alone, unless there are duplicates in the
> # original message. Any second and subsequent headers are rewritten to the
> # second named header (case preserved).
> NNTP_REWRITE_DUPLICATE_HEADERS = [
> ('to', 'X-Original-To'),
> ('cc', 'X-Original-Cc'),
> ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'),
> ('mime-version', 'X-MIME-Version'),
> ]
So, this is about tracking original message headers. Why do we want to do that? Why not leave them intact?
>>> X-Original-Content-Transfer-Encoding
>
> From Mailman/Defaults.py.in:
>
> # Next, these headers are left alone, unless there are duplicates in the
> # original message. Any second and subsequent headers are rewritten to the
> # second named header (case preserved).
> NNTP_REWRITE_DUPLICATE_HEADERS = [
> ('to', 'X-Original-To'),
> ('cc', 'X-Original-Cc'),
> ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'),
> ('mime-version', 'X-MIME-Version'),
> ]
>
>
>>> X-MIME-Version
>
> From Mailman/Defaults.py.in:
>
> # Next, these headers are left alone, unless there are duplicates in the
> # original message. Any second and subsequent headers are rewritten to the
> # second named header (case preserved).
> NNTP_REWRITE_DUPLICATE_HEADERS = [
> ('to', 'X-Original-To'),
> ('cc', 'X-Original-Cc'),
> ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'),
> ('mime-version', 'X-MIME-Version'),
> ]
>
>
>>> X-Mailman-Copy
>
> Nothing in the changelog
>
> From templates/en/options.html:
>
> Avoid duplicate copies of messages?
>
> When you are listed explicitly in the To: or Cc: headers of a list
> message, you can opt to not receive another copy from the mailing
> list. Select Yes to avoid receiving copies from the mailing list;
> select No to receive copies.
>
> If the list has member personalized messages enabled, and you elect to
> receive copies, every copy will have a X-Mailman-Copy: yes header
> added to it.
>
> From Mailman/Handlers/SMTPDirect.py:
>
> # We can flag the mail as a duplicate for each member, if they've
> # already received this message, as calculated by Message-ID. See
> # AvoidDuplicates.py for details.
> del msgcopy['x-mailman-copy']
> if msgdata.get('add-dup-header', {}).has_key(recip):
> msgcopy['X-Mailman-Copy'] = 'yes'
This seems to be redundant. The Received headers will tell me which copy was processed by Mailman.
>
>>> X-List-Administrivia
>
> From the changelog:
> o X-List-Administrivia: is only added to messages Mailman
> creates and sends out of its own accord.
>
> From Mailman/Handlers/CookHeaders.py:
>
> # For internally crafted messages, we also add a (nonstandard),
> # "X-List-Administrivia: yes" header. For all others (i.e. those coming
> # from list posts), we add a bunch of other RFC 2369 headers.
This seems like a candidate for a (collection?) of new List-* headers. It could assist MUAs, for example, in identifying the nature of messages generated by lists.
>> List-help?
>>
>>> X-Content-Filtered-By
>
> Nothing in the changelog
>
> From Mailman/Handlers/MimeDel.py:
>
> # If we're left with only two parts, an empty body and one attachment,
> # recast the message to one of just that part
>
>>> X-Topics
>
> Nothing in the changelog
>
> 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?
>
>>> X-Mailer
>>
>> I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header.
>
> Nothing in the changelog
>
> Some references to code in Mailman/Bouncers/*
> Dunno what it does.
The message that I'm replying to doesn't seem to contain an X-mailer header.
>>> X-List-Received-Date
>>
>> Don't the Received headers carry this information?
>
> 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.
>>> X-Approve
>
> Nothing in the changelog
>
> From Mailman/Handlers/Approve.py:
>
> # See if the message has an Approved or Approve header with a valid
> # list-moderator, list-admin. Also look at the first non-whitespace line
> # in the file to see if it looks like an Approved header. We are
> # specifically /not/ allowing the site admins password to work here
> # because we want to discourage the practice of sending the site admin
> # password through email in the clear.
>
>
>>> X-Approved
>
> Nothing in the changelog
>
> X-Approve dupe?
>
>> Generally, I think we should avoid the use of headers that duplicate other
>> existing headers. Where we want to add more information, then extend the
>> List-* header set if the information might be generally useful for mailing
>> list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people
>> know where the header came from.
>
> +1
>
> 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
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/iane%40sussex.ac.uk
>
> Security Policy: http://wiki.list.org/x/QIA9
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
More information about the Mailman-Developers
mailing list