Mailman must not strip DKIM-Signature headers
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://
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/
del msg['dkim-
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-
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-
But Mailman absolutely needs to cease stripping DKIM-Signature headers. (And really, CleanseDKIM.py should be renamed to CleanseDomainKe
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 www.dkim. org/>.
# DomainKeys Identified Mail (DKIM) signature headers <http://
# 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