ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8

2008-02-06 15:42:00

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

<Prev in Thread] Current Thread [Next in Thread>