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

27 Oct 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@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@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@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@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@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.u...
Security Policy: http://wiki.list.org/x/QIA9
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148