Subject: [ietf-dkim] why we should clearly specify domain existence

From: Eliot Lear <[email-masked]>
Date: Sun, 25 May 2008 11:07:07 +0200

I've said that it is important to state what protocol behaviors actually 
are.  My reasoning is really quite simple: if we don't specify behaviors 
it leads to one of two outcome:

    * a conservative defacto standard that constrains the architecture
      to what exists today, and no more.  A perfect example of this is
      what happened with NAT.  Because the IETF wasn't ahead of the
      curve, we failed to at least state safe behaviors, which led to
      all manner of inconsistent behaviors, which meant that
      applications could only rely on a handful of protocol operations
      being carried out at the transport level.  In other words, if we
      don't say anything we will lose our opportunity to really have a
      say, and we won't like the results.
    * a plethora of special code that is engaged based on what vendor
      implementation one side detects the other side using.  This is
      what has happened with the web, javascript, ActiveX, et al, where
      the cost of development of a commercial site has been increased
      because of special code requirements for the various different
      browser technologies.  It also introduced barriers to entry, which
      are IMHO Bad.

In the case of DKIM, if we specify a conservative check – meaning that 
if any of a number of records are present (say, MX, A, AAAA) – then we 
will allow for uses of disconnected connectivity, some of which exist 
today, and others of which may exist in the future.  This is equivalent 
to the rfc2821bis outcome, if I am not mistaken.  It meets John Levine's 
stated concern that we not specify an additional mechanism, and I 
subscribe to that notion when there is not strong ground to do otherwise.

Some will argue that we don't know the right answer and that operational 
experience may teach us differently.  Fine.  This is a proposed 
standard, and not emblazened in stone.  Some might argue that recipients 
will do what recipients will do.  So they will.  As Dave Crocker and I 
once wrote in the title of an RFC, some practices shouldn't be codified.

Eliot

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Sun, 25 May 2008 17:35:41 +0100

On Sun, 25 May 2008, Eliot Lear wrote:
> experience may teach us differently.

We already have years of operational experience of validating domains
according to RFC 2821 section 5.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT PORTLAND: VARIABLE OR SOUTHEAST 3 OR 4, BACKING NORTHEAST 4 OR 5,
LATER BECOMING CYCLONIC 5 TO 7, PERHAPS GALE 8. MODERATE, BECOMING ROUGH FOR A
TIME. SHOWERS THEN THUNDERY RAIN. MODERATE OR POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Mon, 26 May 2008 06:09:58 -0400 (EDT)

> according to RFC 2821 section 5.

You are seriously advocating that verifiers connect to an authoritative
SMTP server for the author domain? I remind you that the mere
existence of an A/AAAA/whatever record does not "validate" something
as an author domain. It could be a device that does not even have
an SMTP implementation.

I find it embarassing to see people keep assuming that the bad guys
will play by the rules. In this case, people are assuming that the
bad guys will use only those author domains that resolve to valid
SMTP server implementations.

DNS lookup alone cannot validate an author domain, so one might
just as well use the least complicated mechanism. The SSP NXDOMAIN
check is sufficient; the RFC 2821 section 5 MX/A/AAAA lookups create
overhead without actual security benefit.

	Wietse

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 May 2008 12:23:13 +0200

Wietse,
> overhead without actual security benefit.

First of all for any reasonable implementation the query itself is "IN 
ANY", as anything else would add unnecessary network latency.  That just 
leaves the answer.  In many cases you'll want many parts of the answer 
already.  But beyond this, modern email systems score messages.  I'll 
predict that hosts without valid MX records are going to be weighted 
toward spam.  Are you saying that's not worth anything?

Eliot

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 May 2008 17:35:48 +0100

On Mon, 26 May 2008, Wietse Venema wrote:
> SMTP server for the author domain?

No, the discussion is about DNS-only verification.

I think the specification should not prevent implementations from using
more thorough verification if they choose, or re-using existing
verification code, or re-using a previously obtained verification result,
or using resolver libraries that don't distinguish NXDOMAIN and NODATA.

Tony.
FORTIES: NORTHEAST 5 TO 7. MODERATE OR ROUGH. FAIR. MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 May 2008 17:31:51 -0700

On May 26, 2008, at 3:09 AM, Wietse Venema wrote:

> Tony Finch:
>>
>> We already have years of operational experience of validating  
>> domain according to RFC 2821 section 5.
>
> You are seriously advocating that verifiers connect to an  
> authoritative SMTP server for the author domain? I remind you that  
> the mere existence of an A/AAAA/whatever record does not "validate"  
> something as an author domain. It could be a device that does not  
> even have an SMTP implementation.

This is the wrong concept.  Receiving hosts may limit Author Domain  
acceptance to email-addresses that are not invalidated by not having  
SMTP discovery records.  This requirement limits spoofing without  
reliance on ADSP or DKIM having being implemented by the sender.  (An  
incentive.)  The discovery record check should represent less overhead  
than that needed to qualify the Author Domain with PTR records in the  
reverse zone, largely due to the poor maintenance of this zone.

By ADSP making this recommendation, sending domains can obtain  
comprehensive sub-domain protection by publishing ADSP records below  
only the domains containing MX and A records.  This approach  
alleviates publishing ADSP records below _all_ domains, and  
importantly also permits use of wildcard records by other protocols.

> SMTP server implementations.

Is it not embarrassing to accept messages from Author Domains that  
can't possibly resolve to a valid SMTP server?  These are not rules  
for bad-actors, these are recommendations for receiving hosts that  
wish to reduce acceptance of messages being sent with spoofed email- 
addresses.

> DNS lookup alone cannot validate an author domain, so one might just  
> as well use the least complicated mechanism. The SSP NXDOMAIN check  
> is sufficient; the RFC 2821 section 5 MX/A/AAAA lookups create  

Once SMTP takes a rather small step and only ensures a public exchange  
when an MX records is published, then the check would represent  
significantly less overhead than any other scheme and would further  
reduce the number of domains where an ADSP record would be needed.

An MX record mandate also offers protection for domains not  
implementing SMTP, DKIM, from any number transactions often occurring  
as a result of spoofed originating email-addresses.  SMTP can't be  
allowed to recommend the use of bogus MX records either.  That  
approach does not scale and would set a bad precedent.  Until the MX  
mandate occurs, at least the recommended process of first checking MX  
records will detect a non-existent domain, and when used legitimately,  
the algorithm will conclude with a request for an ADSP record.   
Without the MX record mandate, a bad-actor may still induce requests  
for A records.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 10:57:28 +0200

Tony Finch wrote:
 
> I think the specification should not prevent implementations
> from using more thorough verification if they choose

For an ADSP result "nxdomain" they can't do whatever they like
better, e.g., "call back verification" might work, but it's not
the same as "nxdomain".  

> using resolver libraries that don't distinguish NXDOMAIN and
> NODATA.

That library would not implement RFC 1035, it is insufficient
for an "nxdomain" check, and besides, do such libraries exist ?

 Frank

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 May 2008 11:35:10 +0100

> better, e.g., "call back verification" might work, but it's not

You seem to be repeating my point that if the spec requires an NXDOMAIN
check then an implementation cannot be stricter if it wishes.

Note again that I AM NOT ADVOCATING CALL-BACK VERIFICATION. You snipped
the part of my message where I said "the discussion is about DNS-only
verification."

I am talking about checks such as recognizing MX 0 . or treating
MX-points-to-RFC1918 as invalid.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE OR EAST 3 OR 4 BACKING NORTHEAST 5 OR
6. SLIGHT OR MODERATE. THUNDERY RAIN, FOG PATCHES. MODERATE, OCCASIONALLY VERY
POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 14:32:01 +0200

Tony Finch wrote:

> You seem to be repeating my point that if the spec requires an
> NXDOMAIN check then an implementation cannot be stricter if it
> wishes.

I'm not sure about your statement.  Of course receivers can check
whatever they like.  They just have no business to say "nxdomain"
when they got "nullmx", "SPF FAIL", or anything else that is not
the same as "nxdomain".

> MX-points-to-RFC1918 as invalid.

Arguably these checks are fine, but they are no part of ADSP, and
I don't get why anybody would wish to say "ADSP result nxdomain"
when it actually is some kind of "bogusmx".  Why not simply reject
"bogusmx", and don't bother to check ADSP ?  

 Frank

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 May 2008 14:17:40 +0100

> "bogusmx", and don't bother to check ADSP ?

You seem to be arguing that if an implementer thinks the NXDOMAIN check is
too weak, then they should use whatever validity check they think is
suitable.

That is what draft-levine-dkim-adsp-00 says.

The whole point of ADSP's domain validity check is to define when an
implementation should not bother to check ADSP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: EASTERLY 4 OR 5, INCREASING 5 TO 7. SLIGHT OR MODERATE, INCREASING
MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 17:09:23 +0200

Tony Finch wrote:

>> Why not simply reject "bogusmx", and don't bother to check ADSP ?
 
> You seem to be arguing that if an implementer thinks the NXDOMAIN
> check is too weak, then they should use whatever validity check
> they think is suitable.

Yes, but of course ADSP implementations should not report NXDOMAIN
when they checked something else.  If you want a result NOMAILFQDN
instead of NXDOMAIN, stating that NOMAILFQDN can be determined as
specified in 2821bis chapter 5, and an NXDOMAIN check is (only) a
minimal approximation, then I'm fine with it (apparently John's
ADSP draft does this).  

But you have to rename the corresponding result, that is important
for the Authentication-Results.  Digression, at one point in the
SPF history a draft claimed that a domain literal is a "malformed
domain", and that was simply wrong.  If some receivers don't like
domain literals they can decide this without SPF, or here without
ADSP.  Chapter 5 in 2821bis does not discuss domain literals, for
obvious reasons (actually only "obvious" in an IPv4-only world).

> The whole point of ADSP's domain validity check is to define 
> when an implementation should not bother to check ADSP.

It's also the definition of result "nxdomain" in Murray's draft,
if you want "nomailfqdn" (or a similar name), where NXDOMAIN is
only a proper subset, it's okay.  

While we're busy renaming ADSP results, could anybody here explain
the idea of "all" vs. "discardable" ?  I don't see the difference.

One of the more dubious SPF concepts is SOFTFAIL vs. (hard) FAIL,
and "all" smells like SOFTFAIL for me.  The real thing is a FAIL,
what receivers finally do with it is their decision.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 18:25:14 +0200

> What's the filename of that draft?

http://tools.ietf.org/html/draft-kucherawy-sender-auth-header-14#section-2.4.2

> it's backwards to complain that we can't fix the semantics 
> because they will no longer match the semantics we are trying
> to fix.

ACK, I didn't get that you want new precise semantics with a
new corresponding name.  

 Frank

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 May 2008 16:51:04 +0100

None of the drafts I have read defines symbolic names for the ADSP
results, so I don't see why you keep going on about "nxdomain" results.
In any case it's backwards to complain that we can't fix the semantics
because they will no longer match the semantics we are trying to fix.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH FITZROY SOLE: MAINLY NORTHERLY 5 OR 6, BECOMING VARIABLE 3 OR 4, BUT
CYCLONIC AT FIRST IN NORTH FITZROY. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH
AT FIRST. SHOWERS. MODERATE, OCCASIONALLY POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 May 2008 16:41:41 -0700

> the idea of "all" vs. "discardable" ?  I don't see the difference.

The otis-dkim-adsp draft modified the terms from

unknown/all/discardable
  to
OPEN/CLOSED/LOCKED

"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.

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.  Rather "CLOSED" more correctly indicates  
non-signing SMTP services are considered "closed" to users of the  
Author Domain.  Use of "closed" non-signing outbound SMTP servers will  
result in messages being non-compliant with an ADSP "CLOSED" assertion.

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.  This term was replaced with a more  
generic term "LOCKED".  This assertion stipulates that the Author  
Domain wishes to have their messages lacking a valid Author Key Domain  
signatures dismissed.  Dismissal does not imply discard.  The Author  
Domain desires to have acceptance of Author Domain messages "locked"  
in to having valid Author Key Domain signatures.

For normal conversational email, a "CLOSED" Author Domain may often be  
found without a valid Author Key Domain signature.  For specific  
transactional email, a "LOCKED" Author Domain should seldom be found  
without a valid Author Key Domain signature.  The difference between  
"CLOSED" and "LOCKED" will likely be reflected in how messages are  
scored.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 28 May 2008 16:08:51 +0200

> 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.

> 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.

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".  

> 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.

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.  

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

> 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.  

There's no difference between an "all" or a "discardable"
signature, and there is no difference between an "all" or
"discardable" lack of a signature.  DKIM signatures are
meant to survive, if mailing lists destroy them receivers
have to deal with it, the domain owner can't help them to
get this right with a "do what I mean" (discardable) info.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 May 2008 10:34:47 -0700

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

>> "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.

>> 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.

> +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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 29 May 2008 06:30:39 +0200

Douglas Otis wrote:

>> I don't care much about the name, "open", "unknown", "neutral",
>> "maybe", whatever.
 
> state with that of an asserted state.

Okay, strike "unknown" if you don't like it.  Admittedly I didn't
get that your "open", "closed", and "locked" proposal was based on
the simple picture of an open, closed, or locked *door*.  

> 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.  

> 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".  

> 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.  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).

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

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 May 2008 23:13:27 -0700

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

>> 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.

> 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

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 30 May 2008 15:59:25 +0200

> significantly different concepts, where clarity is reduced calling  

For various reasons I think that "you" (the ADSP proponents) would be
better off by adopting known terms, and while you're at it store them
where folks will find them (in SPF records, working with wildcards if
necessary), but apparently "you" insist on inventing new terms and new
discovery methods.

Based on that we apparently agree on replacing "nxdomain" by a broader
concept "nomailfqdn", and "we" (you + me) also agree on replacing the
result names "unknown" / "all" / "discardable" by better terms.  

IMO "open" / "closed" / "locked" are better.  The spec. should mention
which ESMTP status codes fit when unsigned "closed" or "locked" mails
are rejected, following the RFC.hansen-4468upd-mailesc-registry rules.

JFTR, that is of course only relevant for receivers deciding to reject
unsigned closed / locked mails, not for receivers doing something else. 

 Frank