Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

[John C Klensin <[e-mail]>]

--On Sunday, March 04, 2012 20:20 -0800 [e-mail]
wrote:

>> Dear all,
> 
>>    This draft was triggered by  email software providers when
>>    we discussed the eai implementation with them. Any
>>    comments are welcome.
> 
> First, I have to say that given the present state of play of
> the DNS, I am extremely skeptical that a new RRTYPE can
> actually deploy soon enough to be useful. And that's assuming
> you are able to get it through the process quickly, which is
> also unlikely.
> 
> Sadly, the DNS folks are in total denial as to the issues and
> AFAICT see no value in working on mechanisms that would
> improve the situation.
>...

I agree with Ned, but want to add two additional comments
(speaking for myself only):

(1) Whether done with a new RRTYPE or with SRV, this is a major
protocol change.  The right time to suggest it would have been
well before RFC 6531, and the EAI core more generally, were
approved so that any relevant requirements could be built into
the base protocol if the WG agreed that it were a good way to
go.  Whether it is desirable or necessary should have been
something determined during the experimental protocol period,
not put into a draft right after the core standards documents
were published.  Certainly we have known since RFC 4952 was
published in 2007 that there were disadvantages of having to
await an EHLO response before knowing whether the server was
EAI-capable. 

As part of that protocol change, it very significantly updates
RFC 6531 (and the model in RFC 6530) by changing the expected
DNS lookup model from "just like 5321" to "use different RRTYPEs
in different ways".  It should certainly say that. 

At this point, any suggestion of this change, such as that in
the current document, requires a very careful analysis of the
various cases that might be relevant.  The few sentences in the
Security Considerations of this draft are completely inadequate
in that regard.   

In addition, if we were going to do this, there are other
dependencies that should be explored.  For example, the model
that the WG adopted for VRFY and EXPN in order to deal with the
fact that those commands can be issued outside a mail session is
really fairly ugly and may turn out to be too delicate.  If one
could know without going through SMTP extension handshaking
(i.e., the EHLO response) whether the server supported SMTPUTF8
capability, then one could hugely simplify the VRFY/EXPN model
from what is specified in RFC 6531.   It seems to me that this
document is not complete unless it at least examines that issue.

(2) We've tried to use DNS entries to definitively advertise
capabilities since the WKS record when the domain name system
was initially designed.  Our success rate has been terrible:
misconfiguration, different types of relationships between
operators of application servers and DNS zone operators, and
plain sloppy behavior and mistakes have contributed to both Type
I and Type II errors, causing problems severe enough that WKS
was formally deprecated.  Substituting SRV for an indicator plus
MX, as Ned suggests, would presumably help with the problem,
but, if SMTPUTF8 is deployed before this suggestion is fully
approved, the situation would still require that clients get a
sequence of tests correct which, as Ned suggests, is likely to
lead to nasty failures.

FWIW, when the SMTP extension model was being considered,
several types of pre-HELO capability announcements, including
trying to go back to DNS announcements, were considered.  The
EHLO model, despite some disadvantages --including the one to
which you are now reacting-- was chosen as the best alternative.
Moving to a DNS announcement model would, IMO, create an
alternate SMTP extension model.  At least IMO, having such
alternatives is never a good thing unless there is really no
other choice.


In addition, speaking as co-chair...

(3)  To ask a blunt question, if you consider this capability
important, would you suggest that people defer implementing the
capabilities in RFCs 6531-6533 until this proposal can be
approved in the IETF?  If the answer is "yes", consider that,
even if one ignores the DNS deployment issues, an AD would need
to be mildly insane to consider it for approval without getting
the EAI WG to process it.  Now consider what that would mean
given EAI's general speed and efficiency.  This draft would have
to be improved to the point that the WG could actually consider
it.  The WG would have to decide to consider it and, in the
process, decide whether to defer POP and IMAP and the supporting
documents until after this was either approved or definitively
rejected (i18n for POP and IMAP is pretty useless if messages
cannot be delivered).  Given EAI's track record --and your track
record for document updates-- I think it would be wildly
optimistic to believe that this would result in less than
several years delay in SMTPUTF8 deployment.  

Do you think that is worthwhile?

     john