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

Wed Oct 26 17:33:45 CEST 2011

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.

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