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 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:
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
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?
Regars,
Alexey
----- End message from alexey(_dot_)melnikov(_at_)isode(_dot_)com -----