----- Original Message ----- From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Damon" <[EMAIL PROTECTED]>
> 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
