ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Collection of use cases for SSP requirements

2006-12-11 08:40:49
On 12/9/06, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Dave Crocker wrote:
> old news, but i'm trying to catch up.
>
> Steve Atkins wrote:
>> While I strongly agree with this interpretation of dkim-base,
>> some have argued that there are three states
>> in dkim-base: signature verification suceeds, signature
>> verification fails and "no signature".
>
> Since -base explicitly direct a failure as being equivalent to no
> signature, that leaves a total of 2 states:
>
> 1. GoodSig
> 2. NoSig

Unfortunately, it will probably not have that effect when it all said
and done - "Cry Wolf Syndrome."

    FAILURE SIGNATURE  ==> NOSIG

has no logical basis for it.

In short, when systems begin to see an avalanche of DKIM failures, a
pattern of NOSIGS will not be ignored.

---
HLS

+1

I understand what we are trying to accomplish - not treat harshly any
valid messages that for some reason get their sigs munged. I am
wondering how often this ~actually~ happens.
I submit that spammers will take advantage of this in the hopes that
the fallback rule will treat them more kindly. I also believe that
once sysadmins see the volume of failed sigs- a failed sig will be
treated harshly or checking will be turned off to save the overhead of
checking something that offers no value if it checks bad- whether we
say it is legal or not. The volume of bad vs. good will be as it is
now. Why waste the cycles?

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

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