[ietf-dkim] ADSP result set

[Douglas Otis]

On May 28, 2008, at 9:30 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The CLOSED assertion represents an intent to limit users to signing  
>> outbound MTAs.  When used for typical email conversations, this  
>> intent does _not_ ensure receivers that "all" Author Domain emails  
>> will arrive with valid signatures.
>
> And why would receivers be interested in different shades of grey?   
> They need an actionable result, ideally rejecting unsigned mails. As  
> others noted, spending cycles on ADSP has to be worthwhile for  
> receivers.

CLOSED assertions raise the bar for invalid signature results.  By  
being assured of initial conditions, invalid results would need to be  
offset by elements causing signatures to become invalid, such as  
mailing-lists for example.  The LOCKED assertion is intended to  
preclude efforts related to invalid signature assessment.

>> By asserting CLOSED, the Author Domain indicates a desire that  
>> invalid signatures be carefully weighed and perhaps accepted.
>
> Sounds like SOFTFAIL, "please do the right thing, whatever it is,  
> but don't delete my good mails, and reject bad mails".

Unlike SOFTFAIL, a CLOSED assertion indicates there should be evidence  
of what caused a signature to become invalid.

>> The LOCKED state is very different from that of CLOSED.  The LOCKED  
>> assertion might be intended to thwart acceptance from unused  
>> domains whenever a message lacks a valid signature.
>
> Fine, then let's say "locked" is the real thing, and "closed" is too  
> unclear to be useful.

Disagree.  While LOCKED assertions offer receivers easy assessment of  
invalid signatures, such simplistic handling of invalid signatures  
will unfortunately make email dysfunctional for conversational  
emails.  CLOSED assertions offer an assurance of initially valid  
signatures where evidence of what caused it to become invalid should  
be evident.  CLOSED still offers actionable processing, although a  
more complex process with less certain result.

>  We should stick to the known SOFTFAIL and (hard) FAIL terms instead  
> of inventing new terms, and copy the known SOFTFAIL caveats (= use  
> it for testing, not forever).

CLOSED has _nothing_ to do with testing or rote placement into junk  
folders, for example.  CLOSED asserts messages emitted by the Author  
Domain are conversational and should be initially signed.   
Conversational messages are prone to exchanges where signatures may  
become invalid.  Just as closed doors may not bar access, neither will  
CLOSED assertions.  This does not mean CLOSED assertions are without  
merit.  CLOSED assertions still raise the bar for acceptance by  
offering information related to initial conditions.  SOFTFAIL suggests  
moderate handling for unauthorized messages.  SOFTFAIL and CLOSED are  
significantly different concepts, where clarity is reduced calling  
this SOFTFAIL.

> You can't lock a door by putting a note on it saying "locked" :-)

While the door metaphor is not perfect, application files are often  
"locked" in similar fashion. : )

-Doug