ietf-mta-filters
[Top] [All Lists]

Re: sieve for spamfiltering and greylisting

2007-01-18 15:41:15

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.

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?

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.

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.

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.

Another possibility is to make spamassasin Sieve-aware. But maybe this
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,
    Дилян

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