There is another way to avoid this, leave out the identity issue
altogether.
There are a number of source headers that a sender might be
authenticating. Which one is important depends on whether
the mail server is the original source of the message or a
forwarder of some type.
In the most plain vanila mail config all the possible addresses
will match. In the most complex all of these can be different.
But it actually does not matter, as a receiver choose ANY address
you like, look for the SPF record and if it is there see if the
information you have is compatible with the message being sent
from a listed outgoing mail server.
The only thing we need to agree on here is that if the DNS record
lists the set of IP addresses X (by whatever means) then at some
point Y during the transfer the message SHOULD have passed through
a mail server at IP address z such that z is a member of X.
In certain circumstances we can narrow down the issue of point Y
further. The address given in SMTP FROM should always be consistent
with the IP address from which the packet came[1]. (i.e. if IP
address 1.2.3.4 says HELO example.com then we check that 1.2.3.4 is
listed for example.com.
[1] Although this is most relevant for externally facing mail
services it is actually true for any mail service. Look up Adelyn
Lee and Larry Ellison to see why this is useful for non external
services.
I don't think we need to open up the identity question at all.
Clearly there is a big difference in the effect that we get if
we authenticate different parts of the message. In particular:
Message From: This is the address presented to the user
by most MUAs. We should authenticate this
address to prevent impersonation spam (aka joe jobs)
Envelope FROM: This address is not seen by the user, but
it can be used for accreditation purposes.
E.g. message comes from isp.com, isp.com has
positive reputation, accept it.
Other Message headers can be used in the same way as envelope
from.
I don't think we need to get into the identity issue here. The
question is already decided in the protocols.
An effort to first choose the identity that is being
authenticated, before discussing concrete proposals, is likely to
suffer too much abstraction.
This is not a topic and this is not a group of participants with much
success as such fuzziness.
That said, I think that agreeing on the identity, before choosing the
the authentication _mechanism_, is a good thing. It gives us a tight,
incremental approach to the process, and we need all the
process help we
can get.
How to resolve the problem?
I suggest that we have a deadline for _semantic_
proposals, before
we attempt to choose an identity.
That is, folks should submit a description of the identity and the
proposed approach to its authentication, without the syntax or other
protocol details. Hence the discussion of choice of identity can refer
to proposals associated, without having to get bogged down in
their gory
details.
So, we might have 3 proposals for identity X and 2 for identity Y. We
could choose X or Y without deciding which of the proposals.
This gives
us incremental steps in the fashion you are attempting, but gives a
sense of the ways identities will be authenticated as input to the
identity-choosing exercise.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>