We're working to close that very loophole. I just believe it
can be done
without sacrificing the functionality of sending on behalf of another.
I think so too, but the receiver should know this happened,
outlook showed the from line of your message as:
owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org; on behalf of; Gordon Fecyk
[gordonf(_at_)pan-am(_dot_)ca]
I think that is the right approach. Use Sender: and From: by all means, but
explain to the user what just happened.
This would eliminate a lot of the email postcard problems.
Unfortunately, to do that
requires receiving the entire message first and I believed saving the
bandwidth was more important than matching the RFC 2822
headers to the RFC 2821 envelope.
These are computers, they work for cheap. They can check both if we
tell them to.
It happens that by not matching these, we happen to avoid
removing what many (in my opinion) consider still useful
functionality, not to mention avoid a
pile of real world censorship/content-filtering problems.
I think this is possible, we just need to explain a good
way to do it right.
Perhaps there is a non-normative part 3 to the spec, how
to achieve the various functionalities people ask for in
a manner that is compatible with authentication.
However, like any other functionality consistently abused, it
will be taken
away. The moment I start seeing MAIL
FROM:<paypalspoofer(_at_)aol(_dot_)com> sending
From: service(_at_)paypal(_dot_)com under an envelope-only verification
system, I'll
start matching headers to envelopes and bouncing mail. Baby
steps, though. This is still new (well, newer than SMTP).
Perhaps an attribute that could appear in the paypal.com reocrd
would be an attribute 'Frequent target of phishing attacks'.