[Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs)

[Barry Warsaw]

Right, sorry.  I was in a hurry when I wrote my follow up, so let me provide
more detail about the headers, and my thoughts about the X-iness.

In general, Mailman should "play nice" but I also think it's not unreasonable
to claim the Mailman-* prefix and just start using it for Mailman-specific
headers.  If the header has some more general utility, then keeping the X- for
now and registering them may make more sense.

On Oct 26, 2011, at 12:43 PM, Ian Eiloart wrote:

>> X-Message-ID-Hash
>
>This could be replaced with DKIM sigs, I guess.

Actually, no, this one comes from here:

http://wiki.list.org/display/DEV/Stable+URLs

I think there was a discussion about this ages ago, although it might have
been (partly) a private discussion with the Mail Archive folks.  The idea is
that given only the List-Archive or RFC 5064 Archived-At header and Message-ID
header, you should be able to calculate a stable url for an archived message.
If you only know the Message-ID then using the hash should allow you to search
an archive for the message.

X-Message-ID-Hash is essentially just a convenience, since it can be
calculated from the Message-ID.  I think it's still appropriate to leave this
one an X- header, although it might be interesting to register it, and even
more interesting to propose an RFC as an extension of RFC 5064.

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

Mailman's always done some form of message filtering, so this is just MM3's
way of recording the results of the various tests for acceptance.  In MM2, the
processing pipeline contained both moderation handlers (e.g. "is this
administrivia") and modification handlers (e.g. "futz with the headers"), but
this has been refactored in MM3 so that there are different processing
subsystems for moderation and modification.  The headers above will contain a
list of the moderations rules that matched or missed, so their inclusion in
the outgoing message is *mostly* diagnostics.

Since they'll probably be hidden anyway, I think it's useful to keep these on
by default.  They could certainly lose the X- prefix.

>> X-BeenThere
>
>I guess that's useful for avoiding list loops, perhaps?

Right, but MM3 uses List-Post for that now, so this is legacy.  I think this
can be eradicated from the MM3 source, since I think it makes no sense to
recognize the MM2 loop-detection header in MM3.

https://bugs.launchpad.net/mailman/+bug/883158

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

This is just the version of Mailman that sent the message.  It can lose the X-
prefix.

>> X-Mailman-Approved-At

This is a time stamp, so it'll help you understand why a message you sent to a
list a year ago is only showing up now <wink>.  It can lose the X- prefix.

>> X-Archive
>> X-No-Archive

These are Postel's law headers which control whether a message is archived or
not.  Yeah, we've seen them both.  MM3 doesn't set them, so ignore these for
the purposes of this discussion.

>What does this mean? 
>
>> X-Ack
>> X-No-Ack

Similarly, these control whether an acknowledgment of a post is sent to the
original author.  MM3 does set this to "no" when a user's noack flag is set.
These should keep the X- prefix. 

>> X-Peer

Ignore this, it's used in the test suite only.  lazr.smtptest sets it based on
the host:port of the connecting socket.

>> X-MailFrom
>> X-RcptTo

These are also primarily used in the test suite.  Again, lazr.smtptest sets
them, however MM3's LMTP server does add this header based on the RFC 5321
MAIL FROM value.  It's mostly used as a diagnostic though.

I think we could probably rename this to Mailman-LMTP-MailFrom if we still
wanted to keep it.

>> X-Originally-To

Mailman only sets this in gate_news.py when it needs to rewrite the To:
header.  Probably not worth changing.

>> X-Original-CC
>> X-Original-Content-Transfer-Encoding
>> X-MIME-Version

Ignore these.  They are used in the news gating code when it has to rewrite
duplicate headers.  E.g. if a message destined for NNTP has more than one CC
header, MM3 collapses this into a single X-Original-CC and deletes all of the
original CC headers.  At least at one point, NNTP software did not accept
messages with multiple CC headers.

>> X-Mailman-Copy

This one is used when VERP is enabled.  When a message is posted to the list,
personalization is enabled, and a user wants to receive duplicates (i.e. they
have not enabled list-copy suppression), the copy of the message coming from
Mailman will have X-Mailman-Copy: yes set.

This is probably a fairly useless redundancy, since I always tend to use one
of the List-* headers to determine whether a copy comes from the list or not.
It also probably does no harm.  It can either be removed or lose the X-
prefix.

>> X-List-Administrivia

Honestly, I don't remember what the purpose of this header is.  It used to be
used when reduced RFC 2369 header were requested by the list administrator,
e.g. because they had users with, um, unhelpful mail clients and got
complaints about all the List-* headers.  Now we don't support reduced headers
so X-List-Administrivia is just useless and should be removed.

>> X-Content-Filtered-By

This is an identification header added when MIME contents of the original
message are filtered.  I'm not sure how useful it is, except that it does
signal to the recipient that the message they received via the list has been
modified.  I think this should be renamed to (X-)Mailman-Content-Filter.

>> X-Topics

This contains a list of all the topic names that matched the message.

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

Mailman's autoresponder is the only thing that adds this, and it only contains
an identity string.  It may or may not be useful to keep this or change it.
I'm not sure User-Agent would be right though.

>> X-List-Received-Date

This only gets added when the message is sent to the archive.  It's consumed
by the scrubber to help calculate the directory that attachments are saved in.

>> X-Approve
>> X-Approved

These are used for admin bypass of the posting rules.  We could change these
to Mailman-* headers, but we'd still need to keep the above two for backward
compatibility, so I'm not sure it's worth it.

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

I generally agree.

https://bugs.launchpad.net/mailman/+bug/883193

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20111028/4e85555a/attachment.pgp>