On Feb 5, 2008, at 10:46 PM, Hector Santos wrote:
Both SSP-00 and SSP-01, offered DKIM signer who wished to operate in
this mode, powerful 100% zero false positive protocol inconsistency
and fraud protection.
With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection
against 3rd party fraud.
An "all" assertion never implied all unsigned messages should be
rejected. This assertion also never ensured receivers that third-
party handling was avoided. Any damaged signature must be handled as
if not signed. Otherwise, spoofed signatures permit a means to thwart
policies that give credit for invalid signatures.
The NEVER concept can still be covered using DKIM=DISCARDABLE and a
NULL DKIM public key.
Disagree. This is attempting once again at establishing that no email
is sent by the domain. The rub being that this assertion does not
require DKIM to be involved. If done, this assertion should be made
directly rather than requiring still more DNS transactions.
The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
Disagree. Domains wishing to protect important transactional or
commerce related messages are unlikely to consider their messages
"discardable". Rather than assuring receivers that their domain
avoids services that might damage a signature, "discardable" permits
discarding messages whenever a signature is not valid.
When was changing the assertion from "strict" discussed?
When would discarding a message be a recommended action?
Why is SSP attempting to define receiver actions?
But anything related to 3rd party signers was completely eliminated
in SSP-02/ASP. Even though SSP-02 DKIM=ALL is a "always sign for
1st party authors" concept, it is basically a DKIM=DISCARDABLE
without semantics on REJECTION. DKIM=DISCARDABLE failures is
explicit with the REJECTION control. DKIM=ALL failures are not.
The assertion of "all" will likely result in few sources being
considered acceptable sources for this domain's email. When lacking a
valid signature, it would be clear that some other domain is involved.
In short, DKIM=ALL is the SPF version of SOFTFAIL where you can
record it, but you do not take any REJECTION action on it. Just
like SPF.
Disagree. SPF's SOFTFAIL essentially admits registration failures are
beyond the control of the transmitting domain. DKIM's ALL admits
other domains might handle messages that should otherwise be signed.
"Strict" suggested that the domain attempted to preclude any
destructive handling, but this assertion has been removed.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html