Sorry this took so long. I was on my way out the door for a trip to
China, and then there was a problem getting Internet access, and
then...
So, here's my attempt at summarizing the marid jabber session on
Client SMTP Validation:
Authentication and Authorization schemes distinguish between
identities (hosts, networks, domains, email addresses, or users) that
should be tested through channel-based schemes and those that should
be tested through end-system based schemes. Channel-based schemes are
appropriate for statements about hosts and networks, that is, the
operators of a service. Responsible operators will seek to ensure good
behavior by their hosts and their customers. End-system schemes apply
to statements about content and attempt to assert the acceptability of
a particular set of bits, or to hold them accountable, usually to
their author.
Client SMTP Validation defines a channel-based scheme to permit a
client-side SMTP participant to assert accountability to an
administration of record, namely a domain name administrator.
It uses the SMTP HELO domain parameter and performs a lookup on
_client._smtp.<domain> for an SRV record. This contains information
about the authorization of that domain for operation as an SMTP
Client. A separate test must be performed to determine whether the
host offering the domain name in the HELO parameter is associated with
the domain. This can be done with different techniques, such as
reverse IP (inaddr.arpa) or public registration of well-known domain
names, such as paypal.com.
Questions during the jabber session:
1) What does it mean when an SRV record is not present?
The simple answer is that it means the same thing as we have today,
namely that there is no information about the authorization of the
offered domain name.
In such cases, how does it help to have a registration? It is intended
that a registration increases the accountability of the client host.
This increase is intended to _reduce_ the suspicion that a server SMTP
should have and, therefore, the nature and amount of processing on
incoming mail from that host. How much the suspicion is reduced
depends on the client's and the server's experiences with the
accountability mechanism. That is, trust will grow with experience.
2) What is the the behavior of a registration for *.example.com?
The intention is to permit an administrator to define a default for
the entire domain (that is, including its sub-domains) with the
ability to override the default, for particular host. Hence, a domain
administrator may declare that all hosts are prohibited from
performing Client SMTP services or that all are permitted. It may then
specify exceptions for individual hosts. Alternatively, the domain may
choose to declare no domain-wide default, and instead specify
authorization only for individual hosts (domains). Each of these
choices represent different domain operational policy. The intent of
the specification is to leave such choices up to administrators,
rather than impose particular choices on them.
3) Can this mechanism be used to construct a chain of trust, back to
the originator?
The current specification does not define that functionality, but it
seems straightforward to extend the specification to cover it.
This probably requires defining an out-of-band means for the domain to
assert that it records transitive support (backwards) and then an
in-band means of doing the recording, such as with an enhanced
Received: header.
4) Why pursue this mechanism first, rather than authenticate another
SMTP or RFC2822 identity through one of the other proposals?
Client SMTP Validation has the virtue of being very simple and very
localized. The content and it's author originate some unknown number
of hops prior to the current reception event. This indirection
requires validation techniques that are indirect and, necessarily,
more complicated and more constraining.
We have no experience successfully deploying accountability mechanisms
on a large scale, so let's start with something simple and useful,
that will have localized operation and localized effect, but will
provide a useful platform for better trust in email operation.
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>