----- Original Message ----- From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
>> The fraudulent mail covered are for 0% FALSE POSTIVES. Absolutely >> No FUZZY LOGIC. If it was fuzzy, I personally wouldn't be wasting >> my time anymore here. > When a domain signs all of their outbound messages and makes a > statement as such, there are still common services that might be > employed. Strict adherence to an expectation of a message always > having a policy conformant signature where policy does not permit an > exception for these services will cause those services to be rejected > or discarded. Many would view such rejection as representing a false > positive, when the message was legitimately issued on behalf of the > From domain. No doubt. I agree. But this is an implementation issue. That is why it is all optional, a tradeoff, migration issue, security issue, a company decision to balance exactly who/how thier domain properties are to be used. But it still about a domain declaring a policy that is to be interpreted with 0% false positive and no fuzzy interpretations in mind. DKIM-BASE is already fuzzy enough with its "ignore failure as it was never signed" concept. With SSP, we are diluting some of the DKIM-BASE fuzziness: DKIM-BASE-FUZZY + SSP-NO-FUZZY = DKIM-BASE-LESS-FUZZY With SSP, all fuzziness remains with the purity of the DKIM-BASE verification process of the signature. At this point, we won't be questioning the authorization or usage aspects of the signature, but rather authenticity. Its about removing the obvious abuse, no more, no less. The SSP policy considerations I have in mind are before the DKIM signature verification take places. > An option is needed to indicate whether other messages without valid > signatures might be from valid sources acting on behalf of domain > issuing the policy. Ok, it is produces 0% FALSE POSITIVE Policy concept. I'm fine with that. But with what we have now with all the work done with SSP, including my own work with DSAP, its about removing the obvious abuse. Review the verification flow chart outlined in DSAP. http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt or better review this earlier chart with the SSP model: http://isdg.net/public/ssp/ssp.htm You will see that the obvious policy abuses are quickly disseminated. These are 0% FALSE POSITIVE considerations. This is really the same concept and debate regarding the DKIM-BASE Expiration Tag. Do you really need to do a signature hash verification when the x= tag has an expired date? No, not from my viewpoint. That's overhead. The x= debate goes lost with key management debates. But conceptually, it is really the same kind of dispute. An Expire tag is an really a Policy concept. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
