Judging from the wide variety of discussion points, some clarification on
the subject of transport authentication would probably be useful.
There are two different classes of transport authentication. One
authenticates submission access, such as via the AUTH verb we have today.
Another provides authentication across organizational boundaries, where
the sender's credentials can be verified by remote recipients. There is
nothing similar to that today, which is why we have so many spoofing
problems right now. The best we can get in the current model is for
sending sites to declare that local authentication was used, a statement
which cannot be believed in the absence of additional infrastructure.
Another problem with trying to relay local authentication credentials is
that there's no easy way to negotiate mechanisms across multiple hops.
AUTH allows a variety of different mechanisms, and in order for the
original credentials to be preserved and reused, every hop would need to
support the same original mechanism. So it's also just impractical to
extend the AUTH submission-centric model to a per-hop model.
Thus, there are a few interrelated problems that must be solved in order
to have multi-hop, site-to-site, transport authentication: at the very
least, the credentials must be portable enough to be transferred intact,
must be capable of being verified and validated by remote nodes, and the
credentials must use a common form that all of the participant systems
can/will actually support. My guess is that means x509 sender certs which
can be validated mid-stream with verification lookups, but that's neither
her nor there at this particular moment; the important thing is that we
need at least one mandatory and portable credential-relay system in order
for identity information to be meaningful past the first-hop.
We can have other optional mechanisms. For example, it would be feasible
to have an ANONYMOUS extension that allowed a server to advertise that
it'll accept unsigned mail. That would need to be an extension though,
rather than being part of the canonical credential-relay system.
There can also continue to be a variety of local submission mechanisms.
In fact, I pretty much expect that the short-, mid- and even long-term
approaches to submission will be to continue using SMTP AUTH (or some
other varient of existing local service), and that the sender credentials
will be mapped to the canonical credential model by a gateway of some
kind, rather than expecting that any significant portion of desktop
mailers will be using MAIL-NG anytime soon. As long as the mail contains
valid credentials that verify correctly when the mail arrives here, I
don't really care how those credentials were created. I just want
something that I can verify with high credibility, and that I can
therefore use to filter against with equally high credibility.
The credentials do not equate with trust. If the credentials verify, the
only thing I can assume is that the sender was able to use those
credentials, and was therefore probably authorized to do so (sometimes
that's even too much to assume; see below). I still need to use some kind
of external trust relationship or projection to permit any additional
actions. In some cases, the default will be to assume that the identity
data is valid and to only filter against certain attributes (a domain
listed in a blacklist, for example), while in other cases I may need to
verify the credentials against a private store, or may even define a
default-deny policy, and so forth. The point is that the credentials just
provide a way to relay a default assumption that the sender is probably
who they say they are, but trusting in that assumption is different.
Separately, the transport identity does not necessarily need to equate
with the identity purported in the content, and signing the content will
still be necessary in many (if not most) cases, although that's really a
decision that the terminal processes need to make, not something that the
transport system needs to worry about. Human emails could be signed and/or
encrypted if the content needed to be validated separately from the
transport (it would be lower overhead to reuse the transport credentials
for content signing, of course, but that shouldn't be mandatory).
Meanwhile, machine-machine distributed processes like mailing-list
managers or CVS systems or antyhing else could also use content signing,
if they deem it necessary, and may also need separate credentials.
Regardless of all those diversions, however, it seems to me that the
transport system must provide a single, common and portable credential
system that recipients can use to determine if the sender is allowed to
say they are who they claim.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/