On 12/10/06, doug(_at_)safeport(_dot_)com <doug(_at_)safeport(_dot_)com> wrote:
UNREADABLE='[^?"]*big5|iso-2022-jp|ISO-2022-KR|euc-kr|gb2312|ks_c_5601-1987'
This is wrong. It means '[^?"]*big5' OR 'iso-2022-jp' OR ...
What's intended, I believe, is
UNREADABLE='[^?"]*(big5|iso-2022-jp|ISO-2022-KR|euc-kr|gb2312|ks_c_5601-1987)'
However, that shouldn't have affected the recipes in the specific
example you give. With the fixed regex this:
* 1^0 $ ^Subject:.*=\?($UNREADABLE)
should match any subject containing an equal sign followed by a
literal question mark followed by any number of characters that are
not question marks or quotes followed by one of the charset names
you're filtering. This:
* 1^0 $ ^Content-Type:.*charset="?($UNREADABLE)
should match any content-type containing charset= followed optionally
by a quote followed by (etc.). With the old regex, the "any number of
characters that are not ..." applies only to the big5 pattern, but
GB2312 directly follows the question mark or quote so it shouldn't
matter.
One other minor note:
:0:
* ^Content-Type:.*multipart
* BH ?? $ ^Content-Type:.*^?.*charset="?($UNREADABLE)
There's no reason to use BH there, the first recipe should have caught
any mail that has the charset in the header. You just need B.
In writing this, I checked for non-printing characters as you can see the
Content-Type are exactly the same. This seem to then be some kind of timing,
locking or other non-delivery issue.
As Sean suggested, you're going to have to turn on verbose logging and
examine the logfile. One possibility is that there is an extra blank
line in some of the message headers that is causing procmail to treat
them as part of the body, but you seem to have checked for that.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail