From: David Woodhouse [mailto:dwmw2(_at_)infradead(_dot_)org]
Right. And by this argument, neither RFC2822 nor RFC2821
identities are really what we want to use. Biometric
authentication, perhaps? Meanwhile, in the real world... :)
An RFC 822 identity is something that I as a user type into the machine.
The RFC 821 identity is about to be trashed by BATV or something like it.
RFC 2821 identities are irrelevant when dealling with the phishing
problem, they are never seen by end users and are not
intended to be
seen.
This is a red herring. RFC2822 identities aren't _reliably_
seen by users either. _Whatever_ we do, if we want it to be
visible to users we have to make MUA changes. Picking the
RFC2822 identity purely on the basis of visibility makes no sense.
I can persuade pretty much any MUA to reveal the 822 address, the 821
address on the other hand is lost in transit and there is no way for me to
actually see it, the bits NEVER reach my MUA.
In the specific cases of interest in the phishing problem the 821 address
will point to some bulk sender who wants the bounces, the 822 address will
be the one that carries the brand that wants to be identified.
Furthermore the signature headers &ct will be carried in the RFC 822 message
envelope. If you try to sign 821 data you are guilty of a layer violation
that will inevitably lead to a train wreck. The problems with POP3 and the
email senders are due to the failure to observe the protocol/message layer
separation that has always been present in email. In effect you are
proposing the most radical change to email imaginable.
If you want to sign the 821 data go ahead and propose an appropriate SMTP
level scheme.