Subject: sieve for spamfiltering and greylisting

From: Dilyan Palauzov <[email-masked]>
Date: Wed, 13 Dec 2006 12:41:35 +0100

Hello,
   What happens with a mail between the end MTA and the mailbox? First  
(optionally) greylisting, then (optionally) spamfiltering and at the  
end )optionally) sieve-filtering. All this (optional) steps could be  
up to the user to be configured, hence each of them requires different  
interface:
   - one interface for conf. the personal grey listing
   - one interface for configuring the personal spam settings and
   - managesieve for configuring the personal filters.

   It is a bit cumbersome, as all these settings are related to the  
same thing (mail delivery from the users' point of view), but setting  
them up requires different approaches.

   Maybe you have discussed it already, but recently I was thinking on  
uniting all this settings into one. And my idea concrete is either to  
extend sieve to support settings for external programmes or to define  
sieve extensions per purpose (hence one extension for both configuring  
spamassassin and dspam). In the first case just the name of the  
programme will need to be specified and it will be able to define what  
will happen afterwards with the parameters (and be able to get them  
from the script), e.g
   require "prog";
   prog grey-listing 10 30
   (meaning that the mail shall be retried not later than 30 minutes  
and not earlier than the next 10 minutes, in order to pass the  
grey-filtering, or wise-versa - it will be up to the interpreting  
programme)
   prog spamassassin rewrite_header nanana

or in the second case we define a keyword per purpose, the sample  
sieve script could look like

   require "spam", "grey-listing"
   spam rewrite_header nanana
   grey-listing off

   Where the meaning of spam rewrite_header and/or grey-listing off is  
defined by a sieve extension/capability.

  That's all, I just wanted to share the idea. Of course such an  
approach would require the management of several other applications,  
but at the same time it supposes for the future even wider support for  
sieve, both in the spam-programmes and in the tools for managing  
settings. Actually my initial idea was to extend managesieve to upload  
the settings for different applications - once for sieve, once for  
spam-settings, but later I thought it would be better to alter the  
language itself.
   Greetings,
     Dilian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Dec 2006 22:35:22 +0000

Dilyan Palauzov wrote:

> up to the user to be configured, hence each of them requires 
> different  interface:
> extend sieve to support settings for external programmes

Hi Dilyan,
I don't think Sieve is suitable for specifying settings for external 
programs or calling external programs in general.
(Avoiding support for calling of external programs was one of the 
original goals behind the language).

> or to define  sieve extensions per purpose

This seems to be more sensible.
In fact I can imagine a Sieve extension for accessing/managing 
greylisting database or other types of externally stored lists of 
addresses (e.g. whitelists)

> (hence one extension for both configuring  spamassassin and dspam). In 
> the first case just the name of the  programme will need to be 
> specified and it will be able to define what  will happen afterwards 
> with the parameters (and be able to get them  from the script), e.g
>   require "prog";
>   prog grey-listing 10 30

Can you explain what is the exact meaning of "spam rewrite_header 
nanana" in your example?

Regars,
Alexey

---

From: Dilyan Palauzov <[email-masked]>
Date: Tue, 19 Dec 2006 08:19:39 +0100

Hello,
   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. 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, 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.

   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,
     Дилян

----- Message from [email-masked] ---------
     Date: Mon, 18 Dec 2006 22:35:22 +0000
     From: Alexey Melnikov <[email-masked]>
Reply-To: Alexey Melnikov <[email-masked]>
  Subject: Re: sieve for spamfiltering and greylisting
       To: Dilyan Palauzov <[email-masked]>
       Cc: [email-masked]

>
> Dilyan Palauzov wrote:
>
>>  Hello,
>>  What happens with a mail between the end MTA and the mailbox?   
>> First  (optionally) greylisting, then (optionally) spamfiltering   
>> and at the  end )optionally) sieve-filtering. All this (optional)   
>> steps could be  up to the user to be configured, hence each of them  
>>  requires different interface:
>> same thing (mail delivery from the users' point of view), but   
>> setting  them up requires different approaches.
>>
>>  Maybe you have discussed it already, but recently I was thinking   
>> on  uniting all this settings into one. And my idea concrete is   
>> either to  extend sieve to support settings for external programmes
>
> Hi Dilyan,
>> (hence one extension for both configuring  spamassassin and dspam).  
>>  In the first case just the name of the  programme will need to be   
>> specified and it will be able to define what  will happen   
>> afterwards with the parameters (and be able to get them  from the   
>> script), e.g
>>  require "prog";
>>  prog grey-listing 10 30
----- End message from [email-masked] -----