Mailman must not strip DKIM-Signature headers

Bug #557493 reported by James Ralston
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Fix Released
Undecided
Unassigned

Bug Description

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

Revision history for this message
Mark Sapiro (msapiro) wrote :

This was fixed in Mailman 2.1.10 by adding the following to Defaults.py along with the code to implement it.

# Some list posts and mail to the -owner address may contain DomainKey or
# DomainKeys Identified Mail (DKIM) signature headers <http://www.dkim.org/>.
# Various list transformations to the message such as adding a list header or
# footer or scrubbing attachments or even reply-to munging can break these
# signatures. It is generally felt that these signatures have value, even if
# broken and even if the outgoing message is resigned. However, some sites
# may wish to remove these headers by setting this to Yes.
REMOVE_DKIM_HEADERS = No

Changed in mailman:
milestone: none → 2.1-stable
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.