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

[Damon <[e-mail]>]

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

Which is why I tell my CEO always send the important stuff via FedEX.
(I own stock ;)

Wouldn't it be safer not signing?

On the other hand....
Being an operational guy, I know that 99.999^nth% of my mail is going
to make it unmunged. But I hear so much "sky is falling" that I get
caught up in it too.

But what you are talking about is good mail. Mail we know is good
going bad due to some technical hiccup.
What I am concerned with is the bad mail being treated at the same
level as the good mail. I have to weigh my options....

Do I make my scores very high for failed sig checks and treat someone
who /thinks/ they are going the extra mile to ensure their mail is
getting better treatment at the receiving end by signing it- is
getting exactly the opposite of what they expected to happen because
some two-bit system munged their sig in-between. This mail gets
junked, their reputation takes a hit, and the powerpoint they needed
for today's meeting doesn't get there.

Or

Is this just another luke-warm protocol, that is going to be a pain in
the rear to implement and maintain, just so I can add a few measly
points to their score?


I see room for improvement... lots of room. I can see adding policy to
the record or to the DKIM header.. or both that can provide a
"secondary" check or what to do if the record is munged. I like those
ideas. I can start putting teeth back into my scoring

Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html