(Moving to SMTP list because this is definition not about the
DANE document in Last Call)
--On Tuesday, February 16, 2016 07:04 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
Sadly Keith Moore's addrquery draft seems to have stalled:
https://tools.ietf.org/html/draft-moore-email-addrquery-01
I agree that was a promising direction... Yes I quibbled over
the details, but certainly not with the intention of blocking
it, rather I wanted it to be more realistically deployable..
It's not dead. I'm still working on it and will try to get a
revision out this coming weekend.
Keith (and Chris),
This is not a comprehensive review. I'll defer that until I see
the revised version. However, some observations for you to
consider:
(1) While it is common on the Internet these days for bandwidth
to be very inexpensive, that is not universally the case and, as
the Internet reaches into more and more remote locations, may
never be. Consequently, it may be desirable for a client to be
able to specify the information it wants and perhaps whether it
wants a non-error answer if that information is not available
and/or whether it wants the server to trim information not on
its list. Similarly, it may be useful for the server to be
able to advertise at least a summary of the information it is
willing to provide. If, for example, the client can determine
that the server is unwilling (or unable) to supply recipient
encryption information, it might not want to bother with the
AQPX command.
(2) I infer that, like VRFY and EXPN, a mail session (i.e.,
successful issuance of a MAIL command) is allowed but not
required. You should say that explicitly. Also, even with weak
authentication of the validity of a sender email address (or
other credentials) I can easily imagine a server being willing
to return some information to some senders from a given site but
being less enthused about others. So there may be advantages to
allowing either a mail session or a backward-pointing (as well
as forward-pointing) address in the AQRY command.
(3) At some level, as long as the "look at the first character
only" rule and the theory of reply codes is not violated, I
shouldn't care what new SMTP codes you add. On the other hand,
because the theory of reply codes is fairly restricted and, as a
result, the number of available codes smaller than might be
obvious at first glance, I wonder if it is really necessary for
you to invent (and use up) circa five new codes. Wouldn't it be
better to assign (at most) three codes to this command and
insist that servers and clients using it support and use
extended reply codes? My recollection is that we have done that
with some extensions in the past, so it isn't unprecedented.
(4) The EAI WG went through a very long debate as to whether the
right model was "if the server advertises the availability of
the extension, go ahead and send non-ASCII characters in
addresses if you like" and "the server much offer but the client
has to explicitly request/indicate". While, IIR, the
experimental version of those protocols allowed the former,
experience and later discussions caused the WG to concluded that
the second model was better. This spec seems to use the second
model. Please at least review the EAI discussions before
concluding that is a good idea and, ideally, explain why.
(5) Finally, what is probably a bigger deal: I think I
understand the reasons why you want to require a TLS session and
an authenticated (rather than opportunistic) one at that.
However, there will probably always be mailboxes on hosts that
are never accessible by a single connection from a client
machine on the public Internet and probably cases in which it is
unwise to shadow user and key information onto more accessible
hosts. For those systems, optimizing for, much less requiring,
single-hop connections or tight timing dependencies may not be
desirable. "Mail server on Mars" is one such example because
simple round trip TCP (or DTN) time might exceed what would be
considered a reasonable timeout for a database query on
better-connected hosts. Personal concerns about privacy and
address mining aside, little or none of the information AQPK is
specified to return is actually highly sensitive. It seems to
me that it might be better to relax that requirement, explain
why it is desirable and/or use a "SHOULD" and explanation, but
allow the normal multi-hop relay behavior of SMTP to work as it
ordinarily does (presumably including DSN-style messages for the
return data). Note that would allow end to end encryption with
keys obtained through this mechanism and make it useful even in
circumstances where hop-by-hop transport encryption is
infeasible or provides little or no practical protection, so the
advantages are considerable.
Of course, servers could refuse to behave that way and it would
probably be desirable for a client to be able that it is only
interested in single-hop connection approaches, but those should
perhaps by dynamic operational decisions rather than
restrictions of the protocol.
Again, those comments are for consideration -- some of them may
be dumb ideas. But I'd like to think they deserve consideration
and, if you decide to not reflect them in the spec, some
discussion of why they are undesirable.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp