Re: Filtering unusual ASCII code

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
.................................................................
_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info