The 2821 MAIL FROM and HELO strings are visible to end users in the
RFC2822 headers via the Return-Path: and Received: headers. Granted,
these are not normally displayed, but since they appear near the top
of the headers, they are often found by those that know enough to look
at the headers.
That does absolutely nothing to address the phishing fraud problems
I am working on.
We seem to spend an inordinate amount of time considering edge cases
that only affect the handful of users who use line mode clients and
then completely ignore the issues that face the billion plus users
of GUI clients.
RFC 2821 data is only useful for two applications, it can be used
to eliminate bounces for mail that was never sent and it can be used
as a means of applying an accreditation tied to a domain name to
a message.
There is no point in trying to use headers that are correctly
and properly suppressed in the vast majority of clients as a means
of preventing impersonation spam. The only way to stop impersonation
spam is to authenticate the headers the end user sees.
So I think that RFC2821 data, due to their position in the list of
headers, is very slightly more visible to the end user than the
RFC2822 headers that C-ID uses.
Try looking at the clients that the billion plus real users of the
internet, not the ones used by the handful of geeks who attend
IETF.
We are not desiging a scheme to suit our own needs here. We are
designing a system to be used by the masses.
Restricting the validation to the portions of the RFC2822 headers that
are currently widely displayed makes it much harder to create a
standard that can handle all the special cases that (By "portions" I
mean the comment fields vs actual email addresses.)
The 'special cases' are forwarding relationships. There are perhaps
a few tens of thousands of servers involved.
The argument you make yourself demands that any changes be required
of the forwarding relationships and the postcard sites.
Caller-Id provides a very detailed and complete description of how
to use 2822 headers. It has been extensively vetted by the exchange
people and by Eric Allman at Sendmail
https://www.sendmail.com/smi/news/pressrelease.jsp?eventOID=80352&localId=US
A
It is certainly a good idea to do additional examination here. But
there certainly has been a lot of thought put into use of message
headers.