It is a really bad idea to reject messages whose DKIM signature is invalid.
DO NOT DO THIS.
Why exactly is it a really bad idea :) ?
Could you give us some more practical details/examples?
The point is that absent DMARC policy that promises DKIM signatures
aligned with the RFC2822.From domain, there is no sane threat model in
which rejecting invalid DKIM signatures yields any security benefit.
An attacker (spammer if you like), can always sign the mail with some
throw-away domain, or not sign it at all.
So a failed DKIM signature conveys nothing other than perhaps an
operator error on the legitimate sending system, or an unexpected
message transformation in transit.
No spammer wastes bandwidth sending messages with broken DKIM
signatures, they either sign correctly, or don't sign at all.
In my opinion if a signature is present is should be valid. Always.
Otherwise it loses it's whole purpose.
You can certainly take a pedantic view, that's contrary to the DKIM
RFCs and common sense, there's no Internet police to stop you. Just
keep in mind that rejecting failed DKIM signatures has no security
benefit.
Hm, there is always the possibility that I misunderstood the
specifications. Corrections are always welcome :).
I do think, however, that my view is actually in line with the DKIM
specs, although I wouldn't call it quite pedantic :) .
Here is how I see it:
Section 6.3 "Interpret Results/Apply Local Policy" states:
"It is beyond the scope of this specification to describe what
actions an Identity Assessor can make, but mail carrying a
validated SDID presents an opportunity to an Identity Assessor
that unauthenticated email does not."
From this, one can conclude that the DKIM specification actually makes
no formal recommendations on whether to reject or accept a message.
The choice is up to the receiving system. Whatever the decision might
be, it will still be in line with the specs and with common sense.
Next, it does give some general guidelines:
"In general, modules that consume DKIM verification output
SHOULD NOT determine message acceptability based solely on a
lack of any signature or on an *unverifiable signature*; such
rejection would cause severe interoperability problems."
Now, *unverifiable signature* is not the same as "signature present but
not valid". A signature can be unverifiable for multiple reasons, such
as the temporary inability to access the key server.
The "sender domain" is free to choose not to sign its messages and to
not publish a DKIM record. But *if it does* sign them, *the signature
should be valid*. It is common sense.
"If an MTA does wish to reject such messages during an SMTP
session (for example, when communicating with a peer who, by
prior agreement, agrees to only send signed messages), and a
signature is missing or does not verify, the handling MTA
SHOULD use a 550/5.7.x reply code."
Publishing a DKIM record by the "sender domain" does in fact constitute
an "implicit prior agreement" that the "sender domain" sends signed
messages. So, *if present*, the signature should be valid.
While this:
"If the email cannot be verified, then it SHOULD be treated the
same as all unverified email, regardless of whether or not it
looks like it was signed.
See Section 8.15 for additional discussion."
might seem like a recommendation for non-rejection to always occur when
an email can not be verified, Section 8.15 shows that they are cases
when delivery can be refused:
"It is up to the Identity Assessor or some other
subsequent agent to act on such messages as needed, such as
degrading the trust of the message (or, indeed, of the Signer),
warning the recipient, *or even refusing delivery*."
Again, I believe that mail handling software, such as mailing lists or
intermediate relays, should fix their issues and be standard compliant
instead of putting the burden on the end recipient system.
Spammers are often early adopters of various email security standards.
On some receiving systems there's a positive correlation between a
message having a valid DKIM signature and the message being spam!
I wold even go so far as to require DKIM signatures from everybody. But
unfortunately that is not quite possible since there are still many who,
for various reasons, can't provide a DKIM signature at all :) .
Your network, your rules. I am just trying to give rational advice.
On a more practical note: Indeed, our organization does handle quite a
large amount of messages and transactions are very closely monitored for
this kind of issues. So far, the only DKIM related issues we ever had
were with a couple of poorly configured or outdated mailing list
software and spammers. Lots and lots of spammers.
However, depending on their configuration, the situation might be
different for other organizations.
I agree. In the end everybody does as they see fit and what works best
for them.
Cheers,
K.
