[Pine-info] Filtering unusual ASCII code

[Cornelius C. Noack]

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

ccn.
-- 
.................................................................

   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
   WWW-page: www.itp.uni-bremen.de/~noack
.................................................................