On Wed, Jul 14, 2021 at 07:08:07PM +0300, Kevin N. wrote:
> > 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.
* 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.
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.
> 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.
> 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...
--
Viktor.
