MH Michael Hammer wrote: > I posted a write up on an issue with DKIM/ADSP and missing message-ids > at CircleID that might be of interest to people: > http://www.circleid.com/posts/20090323_exploring_dkim_adsp_edge_cases_mi > ssing_message_id/ > I'm going to try to spend a little more time focusing on some of the > implementation "gotchyas" related to DKIM/ADSP for a while.
I promised the following list to Michael, but it is probably of a wider interest, so I'm posting it here. For more than a year I've been interested in cases where apparently a genuine DKIM signature is broken as received at our mailer (with about 1000 active users), so I started collecting such cases. It's a bit tricky to find out what could be a reason for a failure, but with practice some of these blunders can be guessed, typically by trying to reconstruct the original message until a signature becomes valid. Sometimes a combination of DKIM and a DomainKeys signatures helps to see what went wrong, sometimes a 'z' tag helps, sometimes I've been asking the sending site for joined troubleshooting or I could reproduce it by using the same type of a suspect MTA, and sometimes just plain guessing did the job. So here is my list. Each entry reflect an actual case of received mail. Some of these may have been fixed meanwhile by the sending domain, so I'm not claiming that all of them still apply for the named domain. - signing Bcc header field (which gets stripped away by MTA); - signing a Return-Path header field (e.g.: yahoo-inc.com, [email protected]); Apart from the fact that a verifyier at MTA may not see the Return-Path at all, and that signing envelope info is not something DKIM was supposed to do, the actual failure reason in this case was that a signer signed a Return-Path header field like: "Return-Path: [email protected]", while the verifier saw a reconstructed header field with address in angle brackets like "Return-Path: <[email protected]>" as required by RFC 2822; - adding a local Sender header field and signing it, then posting to a mailing list, which may be DKIM friendly, but still is required to strip the original Sender header field and replace it with its own; My pointing the blame in this case goes to RFC 2822, which does not allow more than one occurrence of a Sender header field. Allowing multiple Sender header field (new ones appended at the top) would avoid the issue. This is a reason why our site is not signing the Sender header field (except for mailing list fanout); - forwarding (by MailServer or Microsoft SMTPSVC?) replaces Message-ID, adds "FW:" to a Subject, replaces Date, but keeps original signature and Received header fields - some mailing lists strip Received header fields (lighttpd, bugtraq) (although I should add that a breakage due to a stripped but signed Received header field is much less common that other breakages, like a mangled To header field) - with DomainKeys: no h tag, but does not provide a Message-ID, which is inserted by a receiving MX prior to validation, e.g. from [email protected], [email protected] (still true at least for [email protected]) - signature includes Message-ID in h tag, but there was no Message-ID in the original message at the time of signing. When a receiving MX inserts a missing header field, it breaks the signature. - missing or misplaced public key, e.g. signs as s=mail, d=members.stockhouse.com, but key at d=stockhouse.com; or: jpl.nasa.gov key, lungusa.org, christopherreeve.org found under kintera.com; or: forgets a selector in DNS name: _domainkey.travian.com; or: ci._domainkey.ci.freewebs.com with d=freewebs.com; - syntax errors in public key: * missing ';' between tags (stardock.com),.. * a '+' in a published base64-encoded p tag is converted to a space: default._domainkey.biofeedbackinternational.com, k1._domainkey.mcsv22.net (looks like a web GUI blunder) - signed 'To', but fetchmail(?) rewrites 'To' into a (Recipient list suppressed) - sendmail reformats long lists of addresses in a To header field, which is why our site is not signing a To header field; - some mailers add a space after a colon, e.g. rewriting a "Subject:foo" into a "Subject: foo" - Mailman rewrites 'Reply-To: <addr>' into 'Reply-To: addr' and 'Reply-To: "Display Name" <addr>' into 'Reply-To: Display Name <addr>' - Postfix strips bare CR at end-of-line which invalidates a signature in a message with embedded bare CRs at eol (e.g. with altermime html disclaimers) (this is just one case of a garbage-in / garbage-out principle, the lesson to be learned is that a mail to be signed should be syntactically correct) - mail provider is mangling a Date header field: original: Date: Mon, 4 Aug 2008 17:43:42 -0400 (EDT) mangled: Date: Mon, 04 Aug 2008 17:43:42 -0400 (EDT) - system time on the signing host is few minutes into the future, dkim-milter considers it an invalid signature - resend munge (at Cern) - PerlMX munge - eSafe munge: eSafe SMTP Relay / Microsoft SMTPSVC at gen-energija.si - PMDF munger (rcum.uni-mb.si) - eBay and PayPal: signs non-existent Resent-From, preventing resending - the new yahoo.com DKIM signatures with c=relaxed/relaxed appears to get a body canonicalization wrong (signature h is ok, bh wrong) If someone is interested I have a trully small enough example, suitable for troubleshooting (several empty lines, followed by the last line with several spaces) Mark _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
