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 :) .
A DKIM signature conveys the origin domain in a DKIM-Signature header
that most users don't see, and that (DMARC aside) need not bear any
relationship to either the envelope sender address or the RFC2822.From
address.
Yes, you are correct.
Nowhere have I stated otherwise.
* Apart from conveying potentially positive reputation information, What
security benefit do you see in such a signature?
* If a bad actor can choose between not signing (neutral outcome) or
signing with a key that fails to verify (negative outcome), what
would you expect the bad actor to do?
* Given the above, what is the value of rejecting signatures that
fail to verify? What class of attacks are you stopping?
"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.
Even if there is no additional security benefit, there is no reason why
such messages should pollute the receiving systems.
Well, it clearly (top of page 51) suggests that DKIM validation failure
SHOULD NOT it itself cause a message to be rejected.
"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".
Actually, it is in this case.
No, it is not. Meaning of words does matter.
The "sender domain" is free to choose not to sign its messages and to
not publish a DKIM record.
There isn't "a DKIM record", there's one per selector, and until you
see a signed message with a particular selector, there's no mechanism
for locating any or all of a domain's DKIM signing public keys.
You are correct again.
And again, nowhere have I stated that such a locator mechanism is available.
You can nitpick at the unfortunately chosen "a DKIM record" expression
if you want but the idea still stands.
Also, loosely speaking, "one per selector" is still "a DKIM record".
But *if it does* sign them, *the signature should be valid*. It is
common sense.
It is a common mistake. Some of a domain's mail (some transactional or
opted-in marketing) traffic may be signed under various selectors, and
the rest might not. The RFC2822.From of signed messages may differ from
the DKIM "d=" domain.
Absent DMARC, a DKIM signature just tells which domain potentially takes
*responsibility* for sending the message. When the signatuer check
fails, you can't make that connection. That's all.
The message may be transformed in some manner in transit that
invalidates the signature, sometimes right from the start if the sending
domain has software that first signs, and then does 8-bit to 7-bit
downgrade, or adds a footer, ... Sure they should not do that, but this
is not a good reason to seek to "punish" them for this.
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.
Actually, no. It just makes it possible to take responsibility for
*some* messages. They might for example not choose to take
responsibility for bounces (whose returned body they did not author).
"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:
That's the only sensible, non-pedantic, policy.
"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.
You can do what you want, but (DMARC or other sender-domain-specific
policy context aside) there's no threat model in which refusing the
message makes sense.
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.
Are the spammes adding DKIM signatures purporting to be created by other
domains that then fail validation? That'd be rather pointless...
I have no intention of starting a "flame" here.
As I said before: in the end everybody does as they see fit.
Cheers,
K.
