At 07:18 23-02-2005, Bruce Lilly wrote:
Responding to your points in reverse order:
The message header field "Sender" is an originator field which is
not necessarily related to the SMTP envelope sender return path (or
similar mechanisms in protocols other than SMTP). Consequently, it
plays no role in authentication.
I agree that the "Sender" field may not necessarily be related to the
SMTP envelope sender. The field may be used for end-to-end
authentication technologies.
we need to nip this idea in the bud.
It is completely inappropriate to use Sender for e2e authentication.
When applied to a diverse group of users, such use inevitably conflicts
with both the email specifications and with the installed base of
software.
The From and/or Sender headers are the only fields available
to the MUA for making any determination as to the reputation of the
sending domain.
And neither one is appropriate for authentication in general. Sender
is just too haphazardly used, and there are too many legitimate reasons
for the From field to contain some address or addresses other than that
of the message originator.
If you want a viable authentication proposal, you need to define a new
field which will have a well-established meaning, not try to borrow some
existing field which has either a different meaning (From) or some
existing field which has no consistent use in practice (Sender).
IMHO, there's no way that any proposal reusing Sender can meet the
requirements for Proposed Standard.
There's another idea that we need to nip in the bud, and it's that
any single authentication system will make a dent in the spam or
phishing or virus problems. We're going to need layered defenses
in order to have a useful effect. And for layered defenses to work
implies that they can't use the same protocol fields in ways that
conflict with the specifications, established practice, or each other.
Keith