Re: The sorry state of i18n

[prev] [thread] [next] [lurker] [Date index for 2006/03/21]

From: A. Pagaltzis
Subject: Re: The sorry state of i18n
Date: 06:44 on 21 Mar 2006
* Sean Conner <spc@xxxxxx.xxx> [2006-03-20 20:45]:
>Procmail?  For not supporting i18n at all?  Are there any regex
>engines out there that can deal with i18n?  Does procmail need
>to be updated to support MIME?

That's where all of the blame rests. Neither mutt's nor the
spamwall's behaviour would be a problem if procmail behaved
itself, would it?

Precedent: RFC(2)822 headers must be wrapped at 76 columns.
Procmail sensibly undoes this wrapping before it matches the
headers against the patterns you defined. It would be stupid if
procmail made you account for the fact that the subject line
could be broken at any point, now wouldn't it?

But it makes you account for the fact that headers may be encoded
per RFC2047.

Stupid. Hateful.

>I'm guessing the Spam Firewall vendor can't (or probably won't)
>fix this because the actual bit that does the rewriting of the
>subject line is probably some third party i18n library that the
>Spam Firewall uses and it's not cost effective to "fix" this
>particular problem, since for most people it's not a "problem"
>at all.  

Indeed. If, say, you used Thunderbird and set up a filter rule
based on the subject, it would work regardless of whether of the
subject was RFC2047-encoded or not.

This is just a matter of procmail being prehistoric.

I have forever meant to write my own mail filter script and
retire that nasty paleolithic excuse for a hack...

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>;

Generated at 12:00 on 03 Apr 2006 by mariachi 0.52