[Top] [All Lists]

Re: sieve for spamfiltering and greylisting

2006-12-19 00:32:08

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


----- Message from alexey(_dot_)melnikov(_at_)isode(_dot_)com ---------
    Date: Mon, 18 Dec 2006 22:35:22 +0000
    From: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
Reply-To: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
 Subject: Re: sieve for spamfiltering and greylisting
      To: Dilyan Palauzov <Dilyan(_dot_)Palauzov(_at_)aegee(_dot_)org>
      Cc: ietf-mta-filters(_at_)imc(_dot_)org

Dilyan Palauzov wrote:

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

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

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

----- End message from alexey(_dot_)melnikov(_at_)isode(_dot_)com -----

<Prev in Thread] Current Thread [Next in Thread>