----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
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