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 <i...@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 ()
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/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
