[imp] Filter Suggestions

[Darragh Bailey]

Quoting Michael M Slusarz <slusarz at bigworm.colorado.edu>:
>Quoting Darragh Bailey <felix at compsoc.nuigalway.ie>: 

> As Jan said, you should take a look at ingo since many of the things you
> have requested have already been implemented there 
> (http://www.horde.org/ingo/)

popped over to have a look as soon as he mentioned it (tks Jan). I've joined 
that mailing list and I've cc'ed this to it there as well. I'll probably 
continue the discussion (if there is any continuation) on that list since it 
seems to be the more relevant place. I've leave this as the last mail to the 
imp list about this so that anyone else interested in responding will know I've 
moved to discuss it on the list that deals with it directly and can listen it 
to it there. :) Since I'm cc'ing the ingo list I've left in my original 
comments so the points can be understood. I'm assuming of course that pretty 
much all the filtering stuff is going to be moved to ingo as stated on the ingo 
webpage.

Will any filtering features remain in imp at all or will they all move to ingo?

> > 1) All filters must be applied at the same time 
> > Currently your limited to applying all the filters at the same time, 
> > there is no ability for certain filters to be applied at login/refresh
> > time while others can be applied manually later. 

> This is somewhat difficult to implement, especially since most filtering
> solutions at the present time don't allow this (sieve, procmail, other
> server based solutions).  This is possible using IMAP commands (the imap 
> driver in ingo for example), but the UI would have to be vastly improved
> because this no longer is true filtering - this is more like 'sorting' 
> messages.  Ingo deals with filters - there would have to be a whole 
> different UI for this 'sorting' mechanism that made clear that it had
> nothing to do with filtering at all.
> 
> Ingo does have support for 'filter on demand' for those backends that support
> it (namely, the imap backend).  This kind of does what you are looking for,
> but it is not perfect (namely because it won't allow you to do filtering
> when the messages enter your mailbox).

Looking at ingo it does indicate that it has support for procmail which would 
accomplish exactly what I was suggesting, provided your not limited to one or 
the other and can combine using procmail and the same functionality as the 
filter system that imp uses altogether in ingo. I'll have to look at ingo 
before I say any more since I didn't realise that the filter system had evolved 
into its own system. But if you can manage the procmail filters from ingo that 
would provide the functionality of being able to deal with your blacklists and 
spam separation as it arrives into your mailbox. In fact as I said I currently 
use procmail for exactly this, it'll be nice to be able to manage it in line 
with the horde system was well instead of doing it separately.

>From what I've read in some of the mails about the blacklist issue on this 
mailing list, I think that ingo with its blacklists provides this and therefore 
its really already been done. You can use the blacklists in ingo for what I was 
refering to which does all that via a backend and then perform the filtering 
stuff in the same method that's currently available in imp 3.1. Or at least 
thats what I think is the case, of course need to look at this before I make 
any further suggestions to do with filtering.


> > 2) Filter fields are restrictive.
> > Currently imp only provides the ability to filter based on five 
> > fields To, Cc, From, Subject & Body.
> 
> This is a limitation of the IMAP c-client extension to PHP (it is limited
> to IMAP v2 search rules) that has been worked around in ingo/IMP HEAD.  You
> can sort by any header field in the new versions of these applications.

Spotted that feature in ingo as soon as I looked. Guess others though it would 
be a nice feature as well. Should have figured that the idea was just too good 
to be the first time anyone had thought of it.



> > What I was thinking of would it be useful to allow for a series of
> > advanced fields to be used as well. instead of just having To:, From:, etc
> > checkboxes, include a "Custom Field" checkbox which when ticked enables a
> > user to enter a mail header or series of mail headers to check for into 
> > a text box and these can be used with the text that the rule is to use to
> > filter. This would mean that experienced users have have the ability 
> > to define rules based on additional header fields without the necessity
> > of having to create different options.
> 
> Already done.
> 
> > 3) Sorting Rules
> > Rule order is important, however when you have a significant number 
> > of rules it can become very cumbersome to change the order about 
> > when you create a new rule.
> >
> > Would it be useful that when you go to move a rule up/down that there
> > is an additional box that would allow you to control how many you 
> > could move up/down by instead of being limited to 1 step in either
> > direction?
> 
> If someone would come up with a patch that performed this while keeping
> the UI clean (I can't think of a way to do this without making the filter
> page look ugly) I would gladly commit it.
> 
> michael

What about something similiar to whats use on the page to show the mailbox to 
allow you to move forward/back a number of pages? Use the same type of box to 
allow you to move up/down by a set number. I assume that this would just be for 
ingo, so I'd need to look at this more and try it out with that instead.


-- 
Darragh

"Nothing's foolproof to a sufficently talented fool"