--On Sunday, 06 April, 2008 11:40 -0400 Dave Aronson
<ietf2dave(_at_)davearonson(_dot_)com> wrote:
Some (though admittedly not all) of the problem could be
mitigated if software authors were encouraged (not forced!) to
have their programs:
1) accept new X-headers both with and without the X-, and
2) be configurable to send either, defaulting to "with".
If a given header gets approved, and registered without the
X-, the software need not be changed and redeployed, or even
reconfigured, to *accept* the new version. Having it *send*
the new version, would be a matter of configuration, hopefully
simple.
As new versions of the software are written, support for the
X-version could even be removed, preferably after some
agreeable fairly long amount of time. (A "deprecated"
registry would certainly help there. That could be cluttered
if ALL abandoned X-headers are listed, but it could be
restricted to those that have been deprecated in favor of
things that became official.)
The main problem I see is site admins too far behind the times
to bother flipping the switch to send without an X-, nor
upgrade to versions that don't support sending the X-. Their
users may send to sites that have upgraded to versions that no
longer accept the X- version. In this case, the header will
not be recognized.
One could take at least approaches here. First, one could
simply say "X-headers are experimental, not to be relied upon,
so who cares, tough luck, if it's that important to you, get
your admin to flip the switch." Second, it could be
mitigated by simply having the software continue to accept the
X- version, rather than deliberately removing X- support.
Your thoughts?
Interesting, probably impractical, almost certainly irrelevant
to the text that goes into 2822bis because this would constitute
a new processing requirement (although one might get it through
by insisting that it is just a clarifying suggestion). The
problem of how to turn "experimental" command verbs, header
lines, etc., has been with us for a very long time. We have
never figured out how to get it right. The discussion in RFC
1123 Section 4.1.3.1 about something that the authors though had
been fixed in RFC 959 (four years earlier) is a symptom of the
problem, but by no means the earliest case.
My belief that your idea is impractical is reinforced by the
knowledge that many "firewall" SMTP implementations will simply
remove any X- header and any other header that they do not
recognize on the assumption that it is either private-use and
hence doesn't belong there or that it is a potential vector for
attack or hidden information disclosure.
In my view, RFC 2822 adopted an innovative solution to the
problem, which was to abolish all distinctions and pretend that
there was no history that would lead software to assumptions
about anything that started in an "X-". My view (I think
consistent with Brian's) is that the 2822 approach has
demonstrably failed and therefore that, for the private-use
cases as least, we need to move the text toward a clear
restatement of the intent of the 822 text.
best,
john
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf