In message <43AEB05B(_dot_)4020605(_at_)ccr(_dot_)org>, Mike O'Dell writes:
OOPS..... now you've stepped in it...
:-)
Having been through all this before, the first time 25 years ago
when RFC-733 was revised to give RFC-822, and all the
machinations since then...
both the specs and operational reality treat headers as
case-independent. *if* you wish to honor case in header
processing involving pattern-matching, it MUST NOT be the default.
"slocal" in particular must honor arbitrary CaPiTaLiZaTiOn.
Ok, in this case it is better not honoring case in header processing.
I was not sure if case should be considered in headers pattern-matching
processing, it seemed a restriction imposed by nmh's slocal.
From your email, I see that Postini is doing the wrong thing and
violating an established standard. In this case, it is better not
honoring case even as an optional feature.
Why adding an optional feature that violates an established standard?
It is much better asking Postini to follow the standards instead.
(0) the header tag to the left of the : is ALWAYS case-independent.
the spec specifies how you *should* send it, but it
required that the recipient to accept the header in spite
of bizarre capitalization.
(1) anyone who created a new header with a case-sensitive data portion
(to the right of the :) made a very, very bad design decision
(2) yes, i know base-64 can be used to encode the value of some
extension headers (eg, X-foo), but that merely
requires not screwing with the data in the header,
which is already a requirement. if the processing
of extention-header semantics wishes to honor case,
that's fine, but *nothing else* is obliged to do so.
(3) ergo, it's still a bad decision to make headers case-sensitive
The fact that Postini made a very poor decision is no recommendation.
Indeed. If Postini did a poor design decision, it is their fault.
Changing slocal to meet Postini's case-sensitive classification
scheme is something we should not do.
What about sending email to Postini's technical staff asking for either
changing the email classification scheme or adding a new user defined
field (e.g., X-email-status) to classify an email as spam or not?
NOTE: Personally, I have always been on the side of honoring case in headers.
Especially now that we've admitted there are symbols outside the
26 letters of the US Roman alphabet, "case-folding" is really stupid
because it only applies to 26 symbols out of the 32,000 one can
use in Unicode-clean software. I also happen to have an apostrophe
in my last name - a fact that almost always betrays the brain-damage
in Microsoft IIS web sites - and know many people with much more
exotic diacritical marks in their name, so i'm quite sensitive to
the "6-Bit-DEC10-ASCII-ization" imposed in the email RFCs.
(It wasn't that long ago that lower case was operationally
verboten in email text.)
however, the specs are the specs, and Postel's Robustness Principle:
"Be conservative about what you send and
liberal about what you receive."
is still very, very good advice.
Certainly you, and Jon Postel, are right. We must send good RFC-compliant
email, but we cannot expect all MUAs to make good headers for us. Case
matching is not acceptable, nor standard, for email headers.
Ok, we can safely drop this wish... ;-)
Thanks a lot for the feedback on this matter!
Igor.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers