[ietf-dkim] ADSP result set (was: why we should clearly specify domain existence)

[Douglas Otis]

On May 28, 2008, at 7:08 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The otis-dkim-adsp draft modified the terms from
>
>> unknown/all/discardable
>> to
>> OPEN/CLOSED/LOCKED
>
> So far that is IMO still three terms for two results.
>
>> "unknown" is a misnomer since this asserts not signing Author  
>> Domain messages is permitted.  This practice becomes known once the  
>> ADSP has been discovered.  The term "OPEN" more correctly indicates  
>> any outbound SMTP server is "open" to users of the Author Domain.
>
> It's anyway not very interesting for receivers, and so I don't care  
> much about the name, "open", "unknown", "neutral", "maybe", whatever.

When describing the "practice" state, using the term "unknown" is  
utterly wrong.  Even asserting a practice has meaning well beyond  
"unknown".  The term OPEN does not attempt to conflate the default  
state with that of an asserted state.

>> The term "all" incorrectly implies the nature of the assertion.    
>> Clearly ensuring all messages are signed is beyond the control of  
>> the domain making this assertion.  Not "all" Author Domain messages  
>> can be assured to have been signed.
>
> But "all" is clear for receivers, the intention is to sign all  
> mails, and anything else is by definition bad.

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.  Any reply containing the original  
Author Domain (From email-address) is likely to appear as not being  
signed.  So no "all" is still the wrong term, and is clearly misleading.

> Of course that is the definition of the domain owner, the domain  
> owner has to educate the users, the receiver can say "getting this  
> right is none of my business, I simply reject (or similar) unsigned  
> mails on behalf of the domain owner, unless I have a reason to  
> accept them, e.g. from a known mailing list".

When asserting CLOSED and ensuring users are limited to signing  
outbound MTAs, messages lacking valid Author Key Domain signatures  
could still be due to many normal reasons.  By asserting CLOSED, the  
Author Domain indicates a desire that invalid signatures be carefully  
weighed and perhaps accepted.  Here the term CLOSED accurately  
indicates the nature of the assertion, whereas "all" does not.

>> Rather "CLOSED" more correctly indicates non-signing SMTP services  
>> are considered "closed" to users of the Author Domain.
>
> IMO "closed" is not better than "all", but that could be a matter of  
> taste.  My point was that there is no relevant third case  
> "discardable" / "locked" as soon as you have "all" / "closed".
>
>> Depending upon intended outcome of "discardable", this term  
>> recommends an action that may not be appropriate, and one that  
>> degrades the integrity of SMTP delivery.
>
> Yes.  Additionally it's redunant, receivers are free to interpret  
> "all" and "discardable" as identical, and in fact I don't see why  
> they should interpret these results as different.

Disagree.  When messages from a domain are strictly transactional in  
nature, and are extremely unlikely to have been sent to a "known"  
mailing-list, then the term LOCKED more accurately reflects this  
state.  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.  Such strict  
treatment is unlikely practical for typical messages from Author  
Domains that should assert CLOSED instead.  The difference could be  
described as conversational versus transactional use of messages from  
Author Domains.

> At one point of the SPF history folks proposed to add a "do what I  
> mean" modifier for FAIL.  That proposal wasn't adopted, it would  
> downgrade any unmodified FAIL.  The difference between "all" and  
> "discardable" is apparently the same "do what I mean" idea, I don't  
> like it.

You will find agreement in that respect.  However, some heavily  
phished domains issuing transactional messages desire receivers to  
apply stricter acceptance criteria.  Much like describing the state of  
a door, CLOSED and LOCKED more accurately reflect two clearly distinct  
assertions made by Author Domains.  Terms "all" and "discardable" do  
not offer clear distinctions and are not easily explained.  The term  
"discardable" also has a problem of implying a specific (often  
incorrect) action rather than expressing a state.

> "Closed" and "locked" don't improve this situation.

Unfortunately, there may be receivers that don't make a distinction  
between CLOSED and LOCKED.  If such handling becomes prevalent, then  
typical enterprise domains would be advised not to assert CLOSED, and  
would be advised to assert OPEN.  Since OPEN is the default state,  
only a few domains would likely to publish anything.  That result  
would be a failure of the DKIM WG in communicating what the different  
assertions indicate.  The terms "all" and "discardable" do not offer  
any clear understanding or provide clear metaphors.

>> Dismissal does not imply discard.
>
> +1  But "discardable" is not only the wrong name, it's a redundant  
> concept.  The real thing is "all", and what receivers do with it is  
> a receiver policy, not a signing practise.

Agreed.  Discardable is the wrong name causing a muddled concept.   
"all" represent an unobtainable ideal and thus is incorrect as well.   
On the other hand, LOCKED might be used as an assertion for unused  
domains where any acceptance of a message lacking an Author Key Domain  
signature would be fully undesired.  A CLOSED Author Domain might  
represent messages being exchanged in conversations where some  
signatures will be damaged.  Carefully weighing acceptance of messages  
from CLOSED Author Domains would be desired instead.  The DKIM WG must  
clearly communicate these critical differences, or you'll be  
absolutely right.

-Doug