[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
dotis at mail-abuse.org
Wed Feb 6 14:35:24 PST 2008
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.
More information about the ietf-dkim