Re: [Nmh-workers] Wishlist item - beefing up slocal pattern matching

[Igor Sobrado]

In message <address@hidden>, 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.