0

Good morning,

https://www.rfc-editor.org/rfc/rfc6376#section-5 reads:

"Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer. Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all."

What does that exactly mean? That is, for me it seems to be saying that if hash of a message does not correspond to the DKIM public key for a given message, a verifier should behave as there was a sort of no problem at all. It's exaggeration because messages that lack DKIM signature will probably be treated as having at least lower reputation than those that positively passed DKIM verification. But bad DKIM signature is explicit sign that something is wrong with the message.

Can you clarify how above is meant to be understood? It's possible that I miss something as I haven't read this article in its entirety yet and what I quoted seems to be colliding with "6.2. Communicate Verification Results".

Update: reading "6. Verifier Actions" seems to confirm my suppositions which I described in a comment (that Verifier only checks if the DKIM signature is good or bad, but what to actually do with it is to be determined by Identity Assessor and this RFC a kind proposes (although does not enforce) to implement Receiving Server to be Verifier and MUA to be Identity Assessor:

"A border or intermediate MTA MAY verify the message signature(s). An MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages."

Tom Johnson
  • 107
  • 3

2 Answers2

1

You have it yourself:

Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer.

I read it this way: A sends to C. The message is relayed via B so the flow looks like A->B->C

Party B can take steps (such as stripping off or changing headers) that invalidates the signature. Penalizing party A attempting to the right thing for B's bad behavior makes no sense, and so should be treated no differently then a message without a signature at all.

Tim Brigham
  • 15,545
  • 10
  • 75
  • 115
  • Penalizing A for B's bad behaviour seems to make enough sense to punish senders for the bad antispam enforcement of the relay service they are using - and that is even demanding *active* work, not just asking to *refrain from* committing atrocities against signed headers. – anx Aug 19 '21 at 19:56
0

Pay close attention which cases exactly are compared. Its not comparing

  • a valid signature against
  • a broken signature

It is merely demanding to treat these cases the same:

  • no signatures
  • no useful signatures

seems to be saying [..] a verifier should behave as there was a sort of no problem at all

Because there really is no problem with messages having additional signatures. A message having useless signatures should be painless for the sender, because it does not hurt recipient either.

I find it easier to understand why this is a good idea when considering how an optional feature in a diverse environment can succeed at all: if all it offers is an improvement, or nothing. Putting in effort to deploy an optional feature should not come with any downsides - and certainly not when your signature was fine but was broken by someone else.

anx
  • 8,963
  • 5
  • 24
  • 48
  • Thx for your answer. Yes, I spotted what you tell me to pay close attention to. But in some sense it is not compliant with practice - a lot of receiver servers immediately reject messages with a broken DKIM signatures while accept e-mails with no DKIM signature at all (although at the same time assigning some negative reputation points to that message). The second choice is perhaps in some sense out of necessity - there are still many servers that simply do not do DKIM-signing and rejecting them would be practically too much trouble. – Tom Johnson Aug 19 '21 at 20:20
  • RFC6376 makes difference between Identity Assessor and Verifier so perhaps one could argue that here the receiving servers are acting as both Verifiers and Identity Assessors and rejecting DKIM messages is done by these servers performing the role of Identity Assessors and not Verifiers. However, the question occurs if it actually corresponds to the reality or it's just playing with semantics. Also, it seems to me that almost all servers making DKIM verification play also the role of Identity Assessors (they reject the message or mark it as SPAM), is my impression correct? – Tom Johnson Aug 19 '21 at 20:24
  • "they reject the message or mark it as SPAM" - if its DKIM signature is broken, that is. – Tom Johnson Aug 19 '21 at 20:30