[dev] Sieve filtering module

[Julian Jares]

Quoting Atif Ghaffar <aghaffar@developer.ch>:

> Hi Julian,
> 
> I think that co-operative filters could be a bad thing.
> 
> Example: If I add mail coming from dev@lists.horde.org in  blacklist by 
> mistake that none of my users (currently 2.5K+) will not be able to 
> recieve any mails from the dev list.

Ok, lets start by saying that I _don't_ like cooperative filtering... anyway, 
my installation is what I'd call TINYINT (notice my email address 
julian@jares.com.ar ... my setup is for me, my two brothers and my father)... 
so I can totally trust the good judgement of my users about spam, and anyway, 
If I didn't, Im sending all junk mail to a junk folder. Anyway, it's not the 
best idea.

> 
> For the sieve parser stuff,  have a look at  cyrus_sieve.lib from Didi 
> Diedier <adrieder@sbox.tugraz.at>
> 

Im actually using Dan Ellis sieve-php.lib (I think you told me about this 
one)... Didi's lib's wheren't very user friendly, and Dan Ellis library 
provided me with everything I wanted (just access to the sieve daemon)

> I dont know why you are using a mysql database in between to store the 
> filters?

mmm... this question has a couple of answers
Mainly order... I want to have all my filters in a single location (all my 
users filters)... the sieve daemon is VERY unfriendly to the administrator, 
there is virtually no way of knowing a user filters without nowing the user 
password. Also, it's way easier bulding an user interface based on mysql than 
on the sieve rules, I mean, parsing each time.

> 
> A cleaner implementation will use the Driver aproach like in Turba/Prefs 
> etc where the admin can decide what to use to store/manage filters.
> Eg: sql/sieve/ldap etc
>

Oh... I'll have a look at this... I didn't know about it (there are tons of 
things in the Horde Framework that I'm knowing just now)
 
> OTOH, if you use the current mech of storing the filters, then you get 
> the benifit of both client-side (current) and serverside filtering. 
> (Server-Side filtering happens only on incoming mails and not on mails 
> currently in your folder)
> 

I didn't quite understood this... you mean using my module AND the current 
client side filtering? My only concern about this is that it maybe confusing to 
my users (ok, only to my father) having different set of rules stored in 
different places... Also, server-side filtering is nice in that any client the 
user uses, the filters are the same, and sieve filters are very powerfull :-)

> cheers
> 

Thanks a lot on the feedback :-)

> 
> 
> 
> 
> 
> Julian Jares wrote:
> > About project 2:
> > 
> > (btw, my english is not what it used to be :-( )
> > 
> > I was thinking of two "blacklisting methods":
> > 1. 
> > a. Ask all my users (currently 4) to send spam to a mailbox spam@domain
> > b. Have a daemon check that mailbox, and add to the mysql database (under
> 
> > username all) the froms
> > c. install rules for all users that include this rules, and their own.
> > d. the spam rules should send to a INBOX.junk folder (for if any
> mistakes)
> > e. monthly manteinance can clean the junk folder, say each week
> > 
> > 2.
> > (this is cleaner, but doesn't support the cooperative spam reporting)
> > a. Basically replace the blacklist function with something that adds sieve
> 
> > filters... Im looking at the projects api.php to see how is that done.
> > 
> > Also, did you like what I did? disliked it? I used a lot of Chuck's code,
> just 
> > to use as much of the Horde framework as possible, but every time I look at
> 
> > imp, I just see I reinvented the wheel a lot :-)
> > 
> > Thanks,
> > Julian
> > 
> > Quoting Jan Schneider <janmailing@gmx.de>:
> > 
> > 
> >>Zitat von Julian Jares <julian@jares.com.ar>:
> >>
> >>
> >>>yep, my mistake... just replace the line for
> >>>        if (isset($this->rules))
> >>>I think I have some of those scattered around :-)
> >>>
> >>Ok, no more error messages anymore.
> >>
> >>
> >>>What I do, is on every disruptive change (add rule, edit rule,
> >>>delete rule, undelete rule) I build the actual rules and pass
> >>>them on to sieve.
> >>>
> >>You probably don't need the database anymore if you've got your "project
> 1"
> >>
> >>done.
> >> 
> >>
> >>>I have two projects I'm working on:
> >>>1. something to read the rules currently installed, and upload
> >>>them to the database
> >>>
> >>That would be a great feature! Have fun with the parser coding! ;-)
> >>
> >>
> >>>2. tell my users to an e-mail address, and have that read by a
> >>>deamon, and add it to common rules for all users (note the all user
> >>>in mysql, and the ALL_USERS constants everywhere)
> >>>(2 could be replaced by blacklist send to a junk folder, and
> >>>monthly maintenance deleting old files from that folder)
> >>>
> >>Sorry, but I don't understand what you mean.
> >>
> >>Jan.
> >>
> >>
> >>
> >>-- 
> >>Horde Developers mailing list: http://horde.org/
> >>Frequently Asked Questions: http://horde.org/faq/
> >>To unsubscribe, mail: dev-unsubscribe@lists.horde.org
> >>
> >>
> >>
> > 
> > 
> 
> 
> 
> -- 
> Atif Ghaffar
> Internet Development Manager
> 4unet AG/SA/Ltd.
> ---------------------------.
>            +41 21 351 53 60 ¦ voice
>            +41 79 659 89 72 ¦ mobile
>            +41 21 254 53 62 ¦ fax
>        http://www.4unet.net ¦ www
> http://www.atifghaffar.com ¦ homepage
>      atif.ghaffar@4unet.net ¦ email
> 
> 
> --
> Horde Developers mailing list: http://horde.org/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe@lists.horde.org
> 
> 


-- 
Julian