ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] How mailing lists mutate messages

2006-01-25 05:47:21

----- 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.

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?

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?

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.

  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.

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?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>