On December 26, 2005 at 16:10, Igor Sobrado wrote: > Indeed, I missed that important matter. Certainly nmh should follow > standards as nicely as possible. It does not make sense violating > a RFC only because a product (in this case, the email filtering service > provided by Postini) does. I was not aware about the case-insensitive > behaviour not only on the header field names but also in the field contents.
Case sensitivity of field contents is dependent upon the field itself. Although it appears that there is the intent of field values to be case insensitive in the core mail RFCs, this does not reflect modern reality. For example, the List-* header fields can have different meanings if case was ignored. I.e. List-* fields can have URLs, and URLs are not case-insensitive (excluding any domain portion or other component that is explicity specified as being case-insensitive). BTW, there may also be security concerns involved with ignoring case, depending on the application involved. Therefore, some applications may be case sensitive (header field names should be excluded) to prevent security vulnerabilities. In addition to the example noted, a problem exists with non-ASCII encoded data. Ideally, support for decoding non-ASCII encoded data would exist before a pattern is applied (normalization to UTF-8, or other Unicode encoding format, would be done). Due to complexity of case conversion for many languages, case-sensitive matching would be much easier here from an implementation perspective. However, software does exist that deals with such complexities (e.g. Perl). Ignoring non-ASCII encoded data could also be a security concern depending on the nature of the application. --ewh _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers