[Pine-info] Filtering unusual ASCII code
Cornelius C. Noack
noack at itp.uni-bremen.de
Wed Aug 30 06:13:06 PDT 2006
On Tue, 29 Aug 2006, Lucio Chiappetti wrote:
> On Tue, 29 Aug 2006, Cornelius C. Noack wrote:
>> A week ago, I submitted the following question to the list, asking for help,
>> but received no answer so far. So I'll try again:
> Strange, I believe I replied privately, and I also saw some more traffic
> on the list on the subject. Cannot swear it was you or somebody else with
> a similar question. I'll try to rewrite my answers.
>> Since I never - in over 8 years - ever saw this code set (1022)
>> used in any serious mail to me, I would like to filter my incoming
>> mail for any that uses the iso 1022-jp code set in the subject field.
>> (1) is there any argument against doing that?
> None if you do not have regular correspondents in Japan which use such a
> character set.
>> (2) how do I set the filter accordingly ? I tried looking for the
> Personally I believe it's a bad idea (or a last resort) to do
> post-delivery filtering and therefore I've never done it in pine.
> What I used in the past (still active but less used, read on) was
> extensive use of procmail to do filtering at delivery time (what I do is
> described in http://sax.iasf-milano.inaf.it/~lucio/Procmail/ ... but for
> the installation and configuration of procmail you have to look to other
> resources on the net).
> An hint however is to use the full header command in pine to discover what
> is exactly the offending string. I used that to debug my procmail rules.
>> And here are 2 additional questions
>> (2a) the same applies to mail sent with the [GB2312] code set. But
>> the name of that looks like a Great Britain code set (!?), so I
> It's not Great Britain, it's some chinese code.
> It is included in the set of procmail rules I use for foreign charsets
> http://sax.iasf-milano.inaf.it/~lucio/Procmail/rc.chinese (note I did not
> write most of it, just adapted it from an extensive procmail package
> called SpamBouncer.
>> (3) another frequent case of spam is mail with 'Re:___' ('___'
> If you are seriously intending to reject spam, you should resort to more
> aggressive means which act at delivery or even before delivery. I found
> that mantaining the content-based part of my procmail rules was too much
> of a hassle (and one is always "behind" the spammers).
> A thing like DNSBL (black lists of mail sites) at sendmail level is quite
> more effective (in fact we were running that institute-wide ... my rules
> were just filtering the residual spam).
> A tool like spamassassin is even much more effective. Since a couple of
> months we are running institute-wide a sendmail milter based on
> amavisd-new calling spamassassin (which does DNSBL, URIBL - i.e. blacklist
> of URLs referred by spammers -, content analysis and network tests like
> razor and DCC, and then weighs and combines them all), and now my rules
> are triggered very unfrequently. For our entire institute the percentage
> of good mail is 15% of what we receive. 46% is rejected by spamassassin,
> 16% is addressed to non-existant users, 6% is rejected by the greet pause
> mechanism and the rest by other sendmail checks.
> Installing a milter should be done at central level, maybe it is best to
> talk with your system managers about using an aggressive antispam policy.
> However spamassassin with all plugins can also be installed privately on
> your workstation (as milter if you are root, otherwise it can be installed
> at user level as delivery-time agent called via procmail using a single
> simple rule).
> Only if you can't do ANY of the above you should resort to post-delivery
> filtering in pine, on which others may be able to assist better than me.
> Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
> For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
Thank you very much! I'll take some time to digest it all, and find out
what I can do myself and what would better be done on the level of our
institute (imap) mail server (that's running in a Linux environment, and
our technical staff is quite competent, so that's certainly the better
idea that PINE, I completely agree).
Prof.Dr. Cornelius C. Noack Phones:
Inst. f. Theor. Physik FB 1 office : +49 (421) 218-2427
Universit"at Bremen secretary: -2422
Otto-Hahn-Allee Fax : -4869
D - 28334 Bremen home : +49 (421) 34 22 36
Fax: 346 7872
E-mail: noack at itp.uni-bremen.de or ccnoack at mailaps.org
More information about the Pine-info