John,
JL> It does, however, authenticate that you're talking with an SMTP client
JL> worthy of some level of trust
Given what follows in the rest of the exchange, let me suggest
somewhat different wording, in order to make sure that the difference
between authentication and accreditation are completely clear, here.
(I know John know it, but want to make sure this thread says if VERY
explicitly. This is a topic that has been extremely confusing in this
forum.):
A successful SMTP Auth gives the receiving smtp server a basis for
believing that it knows who the sending smtp client is. With that
assurance about the identity of the client, the server can proceed to
assess the authorization (permission to be an smtp client) and
accreditation (degree of trust to give) appropriate for the client.
JL> Having said that, it's hard to imagine the case where host name
JL> authentication would be the only thing missing _and_ SMTP AUTH would
JL> be in use.
So it perhaps shouldn't be part of the spec, if the purpose is just to
be a component of CSV.
JL> I believe Dave included it for completeness of background, and it
JL> really isn't part of our proposal.
CSV does not attempt to carefully restrict the combinatorial outcomes
of the component sequences. (In english: No doubt there are silly
combinations that can occur; we didn't worry ab out it.)
The HNA stuff really only attempt to document exsiting mechanisms that
can be used for the necessary authentication. That's why it made
sense to move it to the CSV appendix rather than keep it in a separate
document.
JL> However, we realize there _will_ be cases where the SRV lookup doesn't
JL> return the matching IP address, but local policy may recognize STARTTLS
JL> as "sufficient authentication".
In order to avoid confusion, I am inclined to use language like "there
will be cases where the DNS server does not return the matching IP
address as Additional Information to the SRV lookup. It really isn't
the SRV record that is returning the address(es) and even the DNS
server is not obligated to. It's only a (very useful) efficiency hack.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>