Re: [Evolution] Re: FRQ: Pipe incoming mail through AntiVirus tools

[Not Zed <notzed ximian com>]

On Fri, 2002-07-12 at 13:07, Ian Forde wrote:
> Hmm... good idea, but I have a question.  In the case of IMAP, is
> modification of stored email supported?  If so, then one could have IMAP
> folders stored remotely, while still being able to filter locally.

Well we have a 'filter new messages in inbox' option, although it
doesn't appear to be terribly reliable.  That downloads as much of a
message is required to perform the filtering, and then moves it around
on the server (if that is where your filter destinations are).  When it
doesn't properly detect new messages, you can trigger it manually.  The
detection of new messages problem is probably partly imap problems, and
partly a problem with IMAP itself, other clients accessing the messages
will clear the 'recent' flag for example.

> (Granted, this may be somewhat of a strange need, as I'm a roving laptop
> user who doesn't control the IMAP store.)  And fetchmail would get me
> 99% of the way there.
>
> Now - one thing that would (currently) get me through this is the fact
> that I have a shell account on the IMAP server, where I run my procmail
> scripts - I could run everything there.  But that's still technically
> "server side".  I don't think it's a matter of asking for antivirus
> support in Evo - more of asking for a way to send a message out to a
> script (which we already can do), then have a way to get the modified
> message back in.  After that, we can write our own scripts...

Like I said elsewhere, this is being considered but hasn't been written
yet.  Its not terribly efficient as Jeff noted, because you require a
server<>client round trip for each message.

> Besides, isn't this project (and product) about more than duplicating
> functionality of other mailers?  Evo has the right (and probably
> necessity) to create its own unique solutions and lead, not follow. 

Well we're probably getting to the point that this can be done, so far
it has been base functionality, stability, scalability, and
interoprability issues demanding our time.  GNOME2, and other design
issues may be next ...

> Just because other mailers aren't doing it, doesn't mean that it
> shouldn't be considered... Otherwise vFolders wouldn't be a reality, no?

I'm not sure vFolders are that new an idea, apart from the name, which I
may have even been the first to use (i'm fond of shortening things), but
I wouldnt' be surprised if I hadn't been.  Although I think the way they
work in evolution is fairly nice, I haven't ever used any of the other
clients that support similar features to compare though.