I have resisted getting involved in this discussion thus far, but now feel
that I must thow in my .135 $CDN.
IMO Neither approach is flat out wrong, but I must concede, I cannot find
many reasons to condone running external utilities from sieve.
AFAIC this opens a can of worms best left closed. Also, in an enterprise
environment where SMTP is the common denomiator between disparate email
systems (which has been the norm in my experience at least) - MTA content
filtering on both the perimeter and 'backbone' will protect all the mail
systems, not just the ones fortunate enough to be running cyrus imap ;-)
<snip>
> Cyrus IMAPd, IMHO, is meant to be used in a 'black box environment' ... no
> user accounts or directories, which is how we set ours up here ... with
> the extra spam extension in Sieve ("the filter"), end users would have the
> option of enabling/disabling the filtering as/when they wish to ... also,
> by putting it in "the filter", the end user has an option of *not*
> filtering email coming from specific senders, so, for instance, the
> postmaster account wouldn't have any spam filtering done for all email
> coming from the local machine, or things like that ...
>
> In the MTA, in a 'black box environment', a user has *zero* control over
> how the spam filtering is applied, or if it even *is* applied ... which
> also means *alot* of sites will not/do not implement it for fear of that
> *one* person that will cry foul that someone is 'filtering their mail' ...
> as part of "the filter", there is no filtering being done *unless* a user
> wants it, at the MTA level, *all* email is filtered regardless of a users
> desire ...
I would say that your problem is in your implementation, not the
architecture. If the spam/content filter simply marked a header, and you
left it up to the user to decide what to do with the email, then you have
not forced the 'protection' on anyone.
If you are implying that the user doesn't have the right to turn off even
the check/header mark, I ask you this: SHOULD an email adminsitrator allow
the user to do this? Even if so, whats to stop you from doing that at the
MTA level? If you use LDAP to house your user accounts, why not have an
additional attribute that sendmail validates before doing the spam check?
> I don't know ... how many ppl using Sieve out there spend a large portion
> of their time doing exactly that? figuring out effective rules to
> filter out their spam?
> As for the 'running of external programs' ... personally, I see that as a
> security issue, as it prevents users from running arbitrary programs ...
> if this were added, even with a configure option to compile in as desired,
> you are limiting the 'external programs' to what the SysAdmin installed
> into the system and wants the users to have access to ...
This is the can of worms I would prefer to leave closed.
> All I'm advocating is putting more control into the hands of the end users
> as to what they want to have happen to their email ... if they want
> spam/virii, who am I to take that away from them? But give the end-users
> the *tools* to make that decision on their own, which Sieve currently does
> not give ... draft-segmuller-sieve-relation-01.txt doesn't give them that
> choice either, as you are still controlling the flow of email without the
> user have a choice of whether he/she *wants* it to be controlled ...
I still don't see where the end user doesn't have any choices here, unless
as an administrator you don't give them the choice (which I, as an
administrator, should be able to do if I want).
> if you have spamassassin working with Sendmail/Milter, I know there are a
> *ton* of ppl on the spamassassin mailing list that would love to hear your
> success story ... or do you run it on a system of one? There have been
> several postings there (myself included) that talk about how they have to
> restart the daemons whenever sendmail receives two messages
> simultaneously, and nobody appears to know how to fix it ...
I have heard it works well with mimedefang, which if I read correctly, works
as a milter. Even if it doesn't, and as you say, has concurrency problems,
rather than modify everything around the problem, fix the problem!
> >
http://search.ietf.org/internet-drafts/draft-segmuller-sieve-relation-01.txt
I would love to see this implemented!
> IMHO, this is only half a solution, and one that is definitely useful as a
> 'second stage' from the 'spam extension' ... if(spam) && score > x would
> be *very* cool ...
Agreed, this is half the solution - the other half is in the MTA where it
can do good for all mail systems at the permiter and/or backbone, which is
where I would like to see it happen ;-)
Tim
