Mark,
Good review list.
Sounds to me that people are implementing DKIM, and I hate to use the
term "blindly", but thats exactly how it appears with this review.
This doesn't help with the confidence that DKIM can be successful
outside the direct 1 to 1 communications where there is less
expectation for integrity issues and in my view, where the focus needs
to be to give DKIM some real power, rather than trying to make this
work broadly with Mailing List Server and 3rd party signers.
But I think yo are showing the extent of how passthru mail is being
reworked when the long tradition is to leave passthru mail alone - it
only creates problems and you provided a good review of this
unfortunate trend over the years.
The DKIM specification clearly says what headers SHOULD be considered
and what SHOULD NOT. I always felt there should a default and that h=
was optional (to reduce the bandwidth), but having h= should help
remove any guessing.
I have inline comments:
Mark Martinec wrote:
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);
Thats crazy (signing BCC header).
Talking about Errata, this should be a MUST NOT sign. This is the
type of spec changes that are really worth the causes. Not trying
work in 3rd party signatures and reputations services which produces
all kinds of 3-4 years of already discussed headaches. This should of
been a separate I-D.
- 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;
Same thing, RFC 4871 says this header SHOULD NOT be signed. Again,
another case thats shows BLIND signing!
- 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);
I think its a MLS/DKIM that has not been worked out. Another case
where a MLS needs to be paying attention to what its going to strip
and resign, and talking about "taking responsibility?" the originating
domain should be more prudent about what it signs and where it
"blindly" sends his mail! I don't see how a domain can expect the
integrity of the signature to be safe knowing its going to be
destroyed in nearly all MLS systems.
- forwarding (by MailServer or Microsoft SMTPSVC?) replaces Message-ID,
adds "FW:" to a Subject, replaces Date, but keeps original signature
and Received header fields
I really, really, really hate middle ware that destroys passthru mail
- it should be against the law! <g>
- 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)
Another MLS issue, especially when a MLS has gains DKIM smarts, it
should be more conscious of such things.
- 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.
But if it was signed with one, then someone stripped it before the MX
got it.
- 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)
Another case of blind signing. IMO, if failure is going to be
tolerated, DKIM will never work well.
- 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>'
wow.
- 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)
This is an issue for many. We are talking about the MS-DOS, UNIX vs
MAC storage and/or display world. This is one of the reasons why we
have not implemented yet.
- 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)
Another case where passthru mail SHALL NOT BE touched!
- system time on the signing host is few minutes into the future,
dkim-milter considers it an invalid signature.
Ha! I just ran into a similar situation with OpenSSL creating a
self-signed certificate valid 1 hour from now :-) Didn't have time to
figure that one out but to use another version.
- resend munge (at Cern)
- PerlMX munge
- eSafe munge: eSafe SMTP Relay / Microsoft SMTPSVC at gen-energija.si
- PMDF munger (rcum.uni-mb.si)
Oh brother!
- eBay and PayPal: signs non-existent Resent-From, preventing resending
Another case of BLIND signing! Read the freaking specs!!
Anyway good list. Wow! Maybe not as bad as this list makes it, but to
me, it shows DKIM - a mail integrity technology is not going to work
very well in a open distribution environment. Not direct 1 to 1 with
less expectation for failure.
But if we don't give a hoot about failure, then whats the point of
DKIM in the first place.
Bad guys will simply not sign or just fake it even if they know will fail.
Who is hurt by all this?
The SMTP mail receivers!!
who are being asked to put up with this tolerance for failure, and
only look for Mr. GoodBar in a crowd of misfits! So if you see 3
messages from the same domain:
1 - valid signature
2 - invalid signature
3 - no signature
where 2 and 3 are the same according to RFC 4871, and the signature is
expected to be there by the DOMAIN with no way of exposing that fact,
I find it hard to shallow why the sending domain will want only the
GOOD MAIL to be accepted without no instructions on handling 2 or 3.
If DKIM is going to have a chance to provide a payoff, we need to
finally provide the power for exclusive domains, the high-value
domains to better protect their 1 to 1 communications.
In this environment, most of those items in your list will not be
tolerated and the mail will be expected to fail.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html