[Joe Rhett]
This is using an atomic bomb to swat a fly. Not all flies
are the same size, shape and color and you're proposing to
kill many valid uses of mail delivery to solve a fairly
minor problem that is already addressed in other ways.
I think the banking industry would think phishing is more than a "small
problem". Hundreds of millions of dollars per year are lost to phishing
attacks. I would say drastic measures are called for. And this problem
is NOT already addressed in other ways.
PLEASE think before you speak. Or learn more about this
issue, which has been discussed for over 17 years at length,
before you speak.
First of all, I didn't "speak" - I "wrote". You need to learn some
precise English, and some freaking manners. This is supposed to be a
discussion, and I'm throwing out ideas.
Secondly, I have thought about it. I know all about the difference in
semantics between the envelope sender and the message sender, and the
benefits of having both. With all the problems I've seen recently -
problems that severely impact my own users and especially my customers -
I've had enough. The problems of having both identities available - and
the current difficulties authenticating both - outweigh the benefits in
my opinion. It's not worth it.
I think we need to authenticate 2822.from in a reliable fashion, but
that's apparently not so easy. Sender-ID wanted to address it, but the
PRA algorithm was a bit flawed, with all that resent-header junk. And
Sender-ID is basically dead after the patent fiasco. All we have right
now is SPFv1 and difficult-to-deploy crypto solutions like S/MIME and
PGP. Domain Keys seems to be mostly vaporware.
Since we won't be able to authenticate 2822.from reliably for the
foreseeable future, why not do away with it entirely by slapping
2821.from in there? Perhaps just temporarily, until Unified-SPF is done
and deployed. But something needs to be done to authenticate what the
user sees in the MUA. What I suggest seems to me a heavy-handed but
quick fix until a better solution is available.
So I ask again - and please provide some examples this time if you
choose to respond - what critical email delivery functions would
rewriting the 2822.from at edge MTAs break? The 2822.from header is only
an "informational" header, and has no effect on message delivery, right?
NULL senders/delivery reports will obviously need different handling
when it comes to the rewriting. I know mailing lists and forwarders will
not show the original sender of the message. But the 2822.reply-to
header can remain intact, so that's not a huge problem, is it?
-Ryan-