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