I'm willing to believe you, but can't... Do the other people on this
mailing list agree with John on this specific point? Do *many* people
see *every* Received line?
Hard to quantify the people, but let me support that "most" assertion:
-- IBM mainframes, running VM/CMS, the IBM TCP/IP product, and the
MIT/Rice command.
-- IBM mainframes, running MVS and the UCLA mail software.
-- IBM mainframes, running VM/CMS, the IBM TCP/IP product (or the UCLA
one) and UCLA/MAIL.
-- Almost anything using VMSMail as the delivery mechanism, unless an
intermediate MHS has per-user (Good) or per-system (IMHO, very
undesirable) header-trashing capability.
-- UNIX/EMACS/MH the way we have it configured for Athena at MIT,
since people concluded that "last lines" was a poor plan given that
there is no standard for line order, and no one has gotten around to
writing a sufficiently robust filter (e.g., one that does not hide
important Resent fields).
-- Most of the SMTP->mumble-> X.400 gateways I've seen, including the
one operated by MCIMail (when it works), AT&T's, DEC's message router
software (when the headers are not pre-stripped by the SMTP server,
which is a terrible idea).
--Anyone in a U**X environment who thinks "cat" is a UA. But maybe
they get what they deserve, unlike the people impacted by the above.
But the problem with both of these is one of creating and maintaining
bindings between the "real" (822) headers and the extended ones,
especially as mail is gatewayed into non-SMTP systems, forward, resent,
and replied to.
Yes, but you wouldn't be much worse off than you are now. If the From
line was gatewayed through some unextended gateway, you'd end up with
...
Not the point. Point is, how you keep the two sets of bound headers
(reference and target) connected as things gets transformed, added,
munged/trashed,...
john