[ietf-dkim] ADSP result set (was: why we should clearly specify domain existence)
dotis at mail-abuse.org
Wed May 28 10:34:47 PDT 2008
On May 28, 2008, at 7:08 AM, Frank Ellermann wrote:
> Douglas Otis wrote:
>> The otis-dkim-adsp draft modified the terms from
> 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
> 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
More information about the ietf-dkim