Subject: Re: sieve for spamfiltering and greylisting

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Jan 2007 09:35:53 +0000

Dilyan Palauzov wrote:

> Hello,

Hi Dilyan,

>   My idea was not to call external applications, but to provide  
> unified interface where different applications read the same sieve  
> script but interpret different parts of it.

Can this be done using Ned's environment extension and/or Sieve include 
extension?

> The aim is to minimize the  amount of interfaces a user needs to work 
> with in order to configure  the way of the mail from the MTA to his 
> mailbox.
>
>   There are several user's preferences in spamassassin (tool saying  
> for each may how high the probability is, that a specific mail is  
> spam). Such an example is the whitelisting. Another option is 
> altering  the scores per user, that matching specific test gives, thus 
> modifying  the influence that a test has. rewrite_header  
> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options 
> ) modifies the header of the message, in case it is spam. Of course 
> this can be achieved by other means in sieve,

Indeed. The editheader extension can be used for that.

> but the latter fact is a sign that spamassassin and sieve do very 
> similar things (conditionally rewriting headers) and therefore shall 
> be configured from the same  place.

I am not yet convinced that Sieve is the proper place for storing this 
information.
One possibility is to store such information externally (in LDAP, ACAP 
or IMAP METADATA) and access it using a Sieve extension. I've written a 
Sieve extension for accessing IMAP METADATA values.

Another possibility is to make spamassasin Sieve-aware. But maybe this 
is a wishful thinking :-).

>   spam rewrite_header nanana, or rather spam rewrite_header subject  
> nanana is supposed to prefix the subject-header with +nanana+ in the  
> mails marked as spam.
>
>   Greetings,
>     Дилян

---

From: Dilyan Palauzov <[email-masked]>
Date: Thu, 18 Jan 2007 23:32:53 +0100

Hello,

> One idea worth considering is multiple Sieve engines, one running in  
> MTA and one running in delivery agent.
This was what I tried to explain all the time.

> Can this be done using Ned's environment extension and/or Sieve include

   No. The spam filter needs the user preferences in form of input and  
delivers probability as output. The environment extension might  
contain the results from the spam evaluation, but at the moment the  
script is supposed to be read either before or after spam filtering,  
thus being used either as input to the filter, or as output.
>
>> The aim is to minimize the  amount of interfaces a user needs to   
>> work with in order to configure  the way of the mail from the MTA   
>> to his mailbox.
>>
>> altering the scores per user, that matching specific test gives,   
>> thus modifying  the influence that a test has. rewrite_header    
>> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options ) modifies the header of the message, in case it is spam. Of course this can be achieved by other means in   
>> sieve,
>
>> similar things (conditionally rewriting headers) and therefore   
>> shall be configured from the same  place.
>

IMAP Metadata is not appropriate, since not every email address has  
assigned an imap mailbox. E.g. on my server I have 15000 mail aliases  
and I don't want to install for all the suers imap accounts in order  
to store the settings.

LDAP is an option, as well ACAP, but this is practiced at the moment:
   In order to configure the incoming mail, a user has to write a  
sieve script, then to setup the greylisting, then to sfjust  
spamassassin, and then one more spam filter. It would be better for  
the user if there was only one itnerface. Needless to say, first the  
anti-spam tools shall agree on common settings, but sieve is the only  
one of the mentioned 3 interfaces that provides standard means to  
upload the settings.

> is a wishful thinking :-).

It is not that impossible. Just a new module for reading preferences  
is needed and if there is a standard, I am sure the module will be  
written. (there is already managesieve in perl). I will contact, soon  
or late, different spam dev. teams and share later the common opinion.

   Greetings,
     Дилян