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,
avaaz(_at_)avaaz(_dot_)org);
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: user(_at_)example(_dot_)com",
while
the verifier saw a reconstructed header field with address in angle
brackets like "Return-Path: <user(_at_)example(_dot_)com>" 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 y-alerts(_at_)reply(_dot_)yahoo(_dot_)com,
reminders(_at_)reply(_dot_)yahoo(_dot_)com
(still true at least for y-alerts(_at_)reply(_dot_)yahoo(_dot_)com)
- 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