![](https://secure.gravatar.com/avatar/8a0cdd54b32f895fdf86d7aafd41d1fd.jpg?s=120&d=mm&r=g)
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.
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.
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)
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.
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.
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.
X-Peer
Is this still being used?
Nothing in the changelog Nothing in the mailman-2.1.14 sources.
X-MailFrom
Is this still being used?
Nothing in the changelog Nothing in the mailman-2.1.14 sources.
X-RcptTo
Is this still being used?
Nothing in the changelog Nothing in the mailman-2.1.14 sources.
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']
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'),
]
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'
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.
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.
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.
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
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 ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563