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

["Hector Santos" <[e-mail]>]

----- Original Message -----
From: "Michael Thomas" <[e-mail]>
To: "Damon" <[e-mail]>

> 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

and this is what you and others administrators seems to completely ignore.

Before SpamAssasin, comes 2821/SMTP and it will be a Donald Trump "HUGE"
mistake believing Payload abuse is going to be tolerated. Payload abuse
promotes bounce-attacks, lowers the scalarability of operations, and builds
the confidence level of bad guys to bombard systems that depends on
post-smtp MFA frameworks.

I personally don't care how its worded, we are talking about "exclusive"
domain operational considerations where Mail Integrity is still an important
concept in mail systems.  Junk will not get pass 2821.

Regarding testing:

 4.7.  DSAP Tag: t=y

   The t=y tag is optional.  If defined, the domain is currently testing
   DKIM.  Verifiers SHOULD NOT treat testers any different from
   production mode signers.  It SHOULD NOT be used as a way to bypass a
   failed signature classification policies.  However, verifiers SHOULD
   track testers for over extended usage of test signatures and MAY
   consider using the results to provide feedback to the domain.

And other words, the testing flag will not be tolerated as well.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com








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