On Wed, 1 May 2002, Rob Siemborski wrote:
> On Wed, 1 May 2002, Marc G. Fournier wrote:
>
> > > 1. Nobody has made a good enough case for this belonging in Cyrus
> > > instead of the MTA (yes, I know that Sieve can be used anywhere, but
> > > this discussion has been in the context of Cyrus).
> >
> > 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 ...
>
> This can all be done currently by tagging the spam in the MTA and
> appplying a header-based filter within sieve. There is no reason that
> sieve needs to call an external program. The header can be used or
> ignored at the user's whim.
And again, you have an external program that is going through and
"pre-reading" each and every users email, and adding/changing the message,
which I believe will severely reduce the number of sites that implement it
at the MTA level ... procmail isn't an option as a replacement for Sieve,
since you then have to 'break the black box' by providing each email
account with a shell account ...
I work at a University with >5k email accounts and growing ... altho stuff
like MIMEDefang and Spamassassin looks great, since we've decided to use
Cyrus IMAPd (ala black box), getting it implemented here is very difficult
since its not possible to "turn it off by default and let those that want
it turn it on" without breaking the black box ... and I swear we get more
spam going through here then we get regular email :(
> > 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 ...
>
> Yes it does. See above. draft-segmuller-sieve-relation-01.txt only gives
> a finer-grained control.
No, it doesn't ... you are still "pre-filtering" their email whether they
want you to or not ... that's like having someone sitting in your mailroom
pre-sorting your postal mail for you into "suspected spam" vs "real mail"
... I don't know about you, but I personally don't want my mailman going
through my mail, but I'd love the option of being able to say:
if !from(list of known address) then check for spam
Unless I'm missing something, the end-user does *not* have that level of
control at the MTA level ...
Doing it at the MTA level, IMHO, is the same as "Big Brother is Watching"
