Hector Santos wrote:
----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
This goes back to the topic of how much we need to accommodate
verifiers that interpret things wrong. Messages will be signed
in order to increase their deliverability. If verifiers behave in
this way, people will be reluctant to sign messages at all because
there will be a possibility that the signature will impede
deliverability in the event that something enroute (e.g.,
SpamAssassin with certain settings) "breaks" the signature.
Jim,
Please don't think the worst of me with any of this. I'm just expressing
my technical opinion on the matter.
Don't worry about that -- I'm interested in what you have to say, even
(and perhaps especially) if we disagree.
I think you are underestimating the flip side - receivers won't bother
with implementing DKIM verification. DKIM Signatures - valid, broken or
otherwise, without a concept that is essentially a "permission or
authorization to sign verification" concept, has little to no value.
We need solid good reason why we should add the check for DKIM signed
messages. A signed message is not enough.
Just look at your own broken DKIM signatures in the IETF-DKIM forum.
Explain to me why this is an acceptable message over lets say a bad
actor who has learned that its par for the course and will simulate and
emulate your broken message? Further, he doesn't need your private key.
He just needs to fake the signature.
How can I protect you?
I agree; any "verifier" that places extra acceptance-value on a message
just because it looks like it's signed (but doesn't actually verify the
signature) is doing something worse than someone who just ignores DKIM
outright. The reason is that the pseudo-verifier is encouraging others
to spoof DKIM signatures. DKIM can handle spoofed signatures, but it's
just not something we want anyone to encourage since bogus signatures
take (a little) time to verify.
The only reason IETF-DKIM messages is allowed in my system is because it
white listed.
But can I use a broken Jim Fenton DKIM signed messages as a mouse trap
here that are not being sent by this list?
I'm not sure what you mean by a "mouse trap". You shouldn't consider
messages with an invalid signature any differently from messages lacking
the invalid signature, if that's what you mean.
You got to give me solid, logical and deterministic reasons why we
should even bother looking for DKIM signatures - valid or not.
Here is one simple implementation of a Lite Weight DKIM/SSP mouse trap:
Step 1) Message arrives.
Step 2) It goes thru normal/established testing, and
its indeterminate. Move to next state.
Step 3) DATA stage is reached. Message is transfered, no
response yet.
Step 4) Hook is run to check for SSP
If domain SSP says NEVER, issue 5xx or 4xx rejection response.
If domain SSP says EXCLUSIVE:
If No DKIM-signature, issue 5xx or 4xx rejection response.
If Sender != From , issue 5xx or 4xx rejection response.
By "Sender", do you mean "Signer"? (and I presume you would check the
signing address of all the signatures on the message).
This is one set of possible verifier policies; SSP really gives guidance
on what to consider "suspicious" which is intentionally vague and up to
verifier/recipient interpretation. [Although a couple of places in -ssp
section 5 it does talk about message acceptance, and I will propose to
change that.] It also seems to assume that the verifier is the MX host
for the domain; if it's a later hop, you will probably not want to 4xx a
message because it shifts the burden onto yourself.
If domain SSP does't exist (NONE), accept message, issue
positive 250 response.
[Place Holder for additional Logic of relaxed policies]
The point is, I don't need any DKIM signature verification overhead. 1
DNS Policy Lookup. No need get the public key. The above would be 100%
compatible with the draft SSP specification.
Yes, it is. I have to say that I am a little uncomfortable with the
idea that a message might get a 5xx if it had no signature but not if it
had an invalid one (presumably they get a bounce in that case?).
Perhaps we need some better wording in the specs about that.
The problem is not so much relaxed policies and the talk that broken
signatures are ok, but that relaxed attitude blocking the groundwork to
minimize the issue enough that we might as well leave the place holder
above empty. Why bother trying to verify the signature?
Not verifying the signature is one of those things that you can probably
get away with if you're the only one that does it, but something that
will be very quickly exploited if you're not. While it's very hard to
dictate (and in some cases, even to determine) what verifiers do, I
expect that any implementer that doesn't actually do the verification
will quickly lose customers.
Thanks; you have given me some good things to think about.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org