Folks,
DC> 4) Why pursue this mechanism first, rather than authenticate another
DC> SMTP or RFC2822 identity through one of the other proposals?
Some further thoughts:
There are vastly more users (and user domains) than there are
operators. Hence, finding a way to vouch for an operator will produce
a benefit across a number of users (and domains).
Interestingly, this really is only the one, strong argument that is
used in favor of pursuing an infrastructure-based solution, rather
than the usually-superior end-system based one.
This approach is has an important degree of stability, because it is
not subject to the problem of combinatorial explosion, as is present
with using a channel-based mechanism to check and end-system identity.
2822.From, 2822.Sender and 2821.MailFrom are all end-system
identities. (The 2822.Sender sets the value for 2821.MailFrom. Hence,
2821.MailFrom is really an end-system identity.)
In particular, any scheme that ties authentication/authorization of
the last-hop MTA to an end-system identity means that all combinations
of last-hop MTAs that the identity must be pre-registered. This
creates a scaling problem for any end-system identity with a
substantial amount of MTA mobility. (This is in addition to the
problem posted by independent intermediaries that are used and not
amenable to pre-registration.)
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>