Re: Filtering unusual ASCII code

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
----------------------------------------------------------------------------

_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info