OK, you have convinced me that there are loopholes in RFC-2822, and the
spec for an authentication header MUST close those loopholes. Any spec I
write will say something like - A Trusted Forwarder MUST NOT alter either
the incoming headers nor the body of a message.
And in so doing you let the undeployable best be the enemy of the deployable
good enough, and you join the ranks of at least a dozen other proposals that
will never see the light of day.
That still leaves open the question of how difficult it will be to enlist
Trusted Forwarders. Is this a situation like SPF screaming "forger" at
anyone who follows a widespread use of the MAIL FROM identity, or like CSV
saying - You damn well better fix your EHLO name, no excuse. I'm leaning
to the latter,
The issue of not modifyhing header or body content has been discussed ad
nauseum on this and other lists. It is a total and complete nonstarter. And no,
I'm not going to repeat the many hundreds of messages that have already been
exchanged on this topic. In fact now that you've taken off on the "no mods of
any kind" tangent my interest in discussing this matter has dropped to zero, so
this will be my last response on this topic.
but I could be convinced otherwise, if someone gives me more
than vague words about some big forwarder that diddles with incoming headers.
There's this little thing called "nondisclosure agreement" that effectively
precludes my, and I suspect many other contributors, from giving specific
examples of this and lots of other stuff.
It is, however, common knowledge that I work on Sun's messaging server. Large
deals involving such software being used by ISPs are often reported in the
trade press. So, while you won't be able to arrive at anything conclusive, you
can probably get some idea of what I cannot say if you want to do some
research.
Ned