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