ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A more fundamental SSP axiom

2006-08-04 14:42:09
Damon wrote:

>> "SIGN ALL MAIL"
>>
>
> We _dont_ really really mean it.

You and others seem to be having a big problem differentiating between
signing and verifying. I can make a perfectly valid statement that I
sign all of my mail. There is no guarantee that it will survive intact.
Period. Once it's left my domain, I have no control of what intermediaries
do. This is a fact of life, and no amount of glib dismissals or fanciful
reinterpretations of that true statement says alters that.

      Mike

Mike,

You are absolutely and positively correct and _that_ is my problem.
"Sign all mail" is a pipe dream (as you have stated) unless you have
utter control over where it goes and how it gets there.

No. *Verifying* all mail that was once upon a time correct will be
a long time a coming.

So what is the
point of saying "Sign All" unless you can and ensure it gets there
intact?

Nobody can once it's outside of your control. I can make a statement
about what I do though, and a receiving piece of software might
be able to make use of that (nb, not the postmaster) as an input
function to all of the rest of the things it considers.

Which causes me to repeat myself... Treat everyone default as
"Sometimes Sign" and only set "Sign All" only if you really really
mean it - and are willing to deal with the consequences. Isn't that
what is really going to be happening anyway?

Not necessarily. It's not hard to envision a piece of software that
knows that something that ought to be signed needs differnt treatment.
Consider the current dkim policies:

o=~  (sign some)
o=!; t=y;   (sign all, but testing)
o=!; t=n;   (sign all, not testing)

In spamassassin terms,  I might assign:

SSPPOLICY_SIGNSOME 0
SSPPOLICY_SIGNALLTESTING 2
SSPPOLICY_SIGNALLNOTTESTING 10

In the first case, they're telling me to not bother with DKIM because it will
be unreliable. In the second case, the signing domain saying that they sign
everything means that there's clearly something amiss and that it would be
good to bias it toward rejection. The third case is the signing domain saying
that they'd rather it fail than be accepted.

Thus there really is the potential for a receiver to make use of the two flavors
of  SIGN ALL.

      Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html