IMAP needs server-side solutions

On 10/24/05, Seth Dillingham <seth@macrobyte.net> wrote:

>I use Mailsmith <http://www.barebones.com/products/mailsmith/>,
>a commercial (read: not free) email client. It's the best I've ever
>used, but it still doesn't support IMAP. I want to switch to IMAP, but
>I don't want to drop the 99 other Mailsmith features I'd hate to go
>without, like it's awesome filtering system.

I used to berate Barebones for their lack of IMAP support, but at some point I realized that the cool things about Mailsmith would not be so cool on an IMAP connection.

For example, a database query -- the Mailsmith model would need all the text to be available locally. So it would have to download the entire IMAP mailstore, and check every folder every so often to make sure it was up to date, in order for queries to be helpful. Or, the functionality could be implemented by an IMAP server.

Or the example you brought up, filtering -- the Mailsmith model would need the client to be open and active to do all of the filtering. If you check your email from some other IMAP client, mail would remain unfiltered until Mailsmith has its next chance to process the new material. Or, the functionality could be implemented by an IMAP server.

Ultimately I think the desirable use model is something like what Microsoft has done with Outlook and Exchange. (Betcha never thought you'd hear me say that, huh Seth? ;) Of course I'd rather see an open protocol, with server and client offerings from various commercial vendors and open source projects.

For IMAP, I think the magic has to happen on the server. Clients need a standardized way to invoke or access such magic at the low level, and clients should present a pleasant GUI to present the magic to users at a high level. "Magic" includes: setting up filtering rules. Setting a vacation/out-of-office auto-reply (I don't care for them, but apparently others do...)=2E Querying the mailstore. "Smart" folders (akin to smart playlists in iTunes). The functionality belongs on the server, since that's where the data is, and the protocol should be designed in such a way to support a nice GUI on the client.

Does anyone know of activity in this direction? I'm not aware of any, but then I don't track development in this area.

-Brian

[Top]

Re: IMAP needs server-side solutions

On 24-Oct-05, at 11:52 AM, Greg Pierce wrote:

> On Oct 24, 2005, at 1:19 PM, Brian Andresen wrote:
>
>> Does anyone know of activity in this direction? I'm not aware of
>> any, but then I don't track development in this area.
>
> In the free software arena?
>
> Sieve filtering is implemented in Cyrus, and a number of proprietary
> IMAP servers. And there's a plugin for SquirrelMail to allow editing
> of your filters server side. It's all very capable stuff, but, yea,
> it's clunky for your average user with the UI currently available.

Mulberry IMAP client also had a Sieve interface, but I tried it and
it was really buggy.

I'm using Sieve and Cyrus to do server side filtering and it's
wonderful... it would not be hard to write a good GUI for managing
Sieve scripts. I wrote my Sieve script by hand, it wasn't hard after
seeing some good examples (which weren't easy enough to find via
Google unfortunately).

> There's a lot of other proprietary solutions for this stuff, too,
> with commercial servers.
>
> Apple nicely addressed some of the issues by allowing you to sync
> mail rules/accounts with a .Mac account -- but, yes, that still only
> works with different macs and only if you're using Mail.app.

If you sync the rules does it apply them on the server or just back
them up so other clients can download and use the same rules in
mail.app?

I wonder if it's possible to do a Mail.app rules to Sieve translator?

Jim

[Top]