Hector Santos wrote: > ----- Original Message ----- > From: "Jim Fenton" <[EMAIL PROTECTED]> > > >> 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
