[Bug 557493] [NEW] Mailman must not strip DKIM-Signature headers

[James Ralston]

Public bug reported:

I reviewed the discussion that led to the decision to have Mailman strip
DomainKey-Signature and DKIM-Signature headers:

http://mail.python.org/pipermail/mailman-
developers/2006-January/018537.html

This may have been the correct action to take in 2006. But since then,
the DKIM standard has been finalized (RFC4871), and it contains:

3.5.  The DKIM-Signature Header Field

   The DKIM-Signature header field SHOULD be treated as though it were a
   trace header field as defined in Section 3.6 of [RFC2822], and hence
   SHOULD NOT be reordered and SHOULD be prepended to the message.

RFC2822 defers to RFC2821, which has been replaced by RFC5321, which
states:

4.4.  Trace Information

   An Internet mail program MUST NOT change or delete a Received: line
   that was previously added to the message header section.  SMTP
   servers MUST prepend Received lines to messages; they MUST NOT change
   the order of existing lines or insert Received lines in any other
   location.

Ergo, Mailman MUST NOT strip DKIM-Signature headers. Even if Mailman
knows that actions it will take with the message will invalidate one or
more DKIM-Signature headers, those (now-invalid) signatures MUST be left
intact. DKIM-Signature headers must be treated exactly like trace
(Received) headers.

This isn't simply a case of doing the right thing just for standards
compliance: although DKIM states that MTAs can't treat the lack of a
DKIM signature any differently than an invalid DKIM signature, the
presence of a DKIM-Signature header (even invalid) is a consumable item
for MUAs; e.g., a token for Bayesian anti-spam systems. (For example, we
currently receive *zero* spam with forged DKIM-Signature headers for our
own domain. Zero. Thus, even an invalid DKIM-Signature header is
incredibly useful to have.)

The fix for this is simple; just remove this line from
Mailman/Handlers/CleanseDKIM.py:

    del msg['dkim-signature']

As for DomainKeys, although the DomainKeys protocol is now historical,
RFC4870 states:

3.5.2.  Determining Whether an Email Should Be Signed

   A signer MUST NOT sign an email that already contains a "DomainKey-
   Signature:" header unless a "Sender:" header has been added that was
   not included in the original signature.  The most obvious case where
   this occurs is with mailing lists.

   A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.

The difficulty here is that the signer (downstream from Mailman) cannot
guarantee that a Sender header was added that was not included in the
original signature, but it is forbidden from adding another DomainKey-
Signature header if that wasn't the case. I suspect this is why many
(most?) DomainKeys signers simply refrain from signing if a DomainKey-
Signature header is already present, which is the behavior that Joe
Peterson observed, and led to the decision to unconditionally strip all
DomainKey-Signature and DKIM-Signature headers.

Thus, I think Mailman stripping DomainKey-Signature headers is probably
still the best choice; leaving them will all but guarantee that any
downstream DomainKey-signer will refrain from generating a DomainKey-
Signature. This isn't optimal, of course, but implementation ambiguities
like this are why DomainKeys is now historical.

But Mailman absolutely needs to cease stripping DKIM-Signature headers.
(And really, CleanseDKIM.py should be renamed to CleanseDomainKeys.py.)

** Affects: mailman
     Importance: Undecided
         Status: New

-- 
Mailman must not strip DKIM-Signature headers
https://bugs.launchpad.net/bugs/557493
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.