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

Damon deepvoice at gmail.com
Mon Dec 11 07:33:34 PST 2006


On 12/9/06, Hector Santos <hsantos at santronics.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


More information about the ietf-dkim mailing list