[Dovecot] Thinking Outside the Box - Extending IMAP

[Eric Rostetter]

Quoting Marc Perkel <marc at perkel.com>:

> Here's some thoughts I'd like to throw out there. I know it's not
> standard IMAP protocol but someone has to try new ideas first and I
> want to see what people (Timo) think of this.

I don't think you will find many supporters, other than the usual crowd
who always wants SMTP over IMAP support.

> Here's my initial thoughts on this. Suppose we extended IMAP to include
> an EXECUTE command as follows:

You'd be better off either making these "generic action verbs" like
"add" and "remove" (if each is meant to be self-sufficient, one-line
actions), or calling them "modes" (if the idea is to switch contexts
to some other protocol such as smtp, calendars, etc).

> On the server side is a config file

Yes, that would be critical IMHO, or at least that there was some
centralized way to control it, and not Dovecot-specific if you wanted
the idea to spread past dovecot.

> parameters passed. For example, suppose there is a command to add a
> user to a server side blacklist.
>
> 100 execute blacklist add joe at smith.com
> 100 ok

You'd be better off with a generic "add" which took paramters like:

100 add blacklist joe at smith.com
101 add user joe at mydomain.com
102 add whitelist joe at jones.com

You'd then of course have a "remove" or similar named function to undo
the add.  You could also do a "set" or "modify" and so on.

The first argument to "add" (or whatever) would say what to execute
(via a map file/table, for example).  This makes the implementation
a bit more generic and independent of any executable.

> Dovecot would open a two way connection to the server application
> allowing the client to talk to any application that is configured and
> can send and receive text. The connection persists until the server end
> terminates or the client closes the connection.

I'd rather see these as "plugin" type applications, but that certainly
limits their adoption...

> With a tool like this one can write generic applications easily that
> would greatly expand what email clients can do interacting with the
> server.

Sure, but why not just use a protocol for each, rather than layering
them on top of IMAP?  Do you really think the overhead of opening a new
connection is so great?  Debugging sure would be easier if they are
separate...

> Not only can setting be changes but you could interact with
> server side calendars, pick up voice messages from phone systems, run
> any sort of groupware, all over a generic IMAP connection with this
> simple extension.

This is more like the "mode" idea I mention above, IMHO.

> Example:
>
> 100 EXECUTE calendar
> 100 ok
> 100 list schedule today 8:00 10:00
> 100 8:00 make coffee
> 100 9:00 meeting with boss
> 100 9:30 Call Joe Blow at 415-555-1212
> 100 ok
> 100 quit
> 100 ok

And when "quit" happens, what mode are you in?  What if the task executed
changed the IMAP state, how would IMAP know that?  Seems like keeping
track of state would be next to impossible, and would require the IMAP
session to reinitialize after the execute command, which would be about
the same overhead as just using another connection in the first place (a
bit less, but...).

In other words, unless the task executed was specified as to never change
the IMAP universe (couldn't deal with SPAM filtering, password changing,
sorting/deleting/adding mail/folders, etc) then when it was done executing
the IMAP server would have to re-initialize to catch any changes, and this
kind of defeats the purpose of the proposal IMHO.

> One thing I'd like to use it for is an outgoing SMTP connection to send
> outgoing email over IMAP. A session might look like this:

Yeah, I knew that was coming. :)  And of course, this very well could
change the IMAP environment, and hence would require an IMAP session
reset, which means why do it?

> Who likes this idea?

Not me.  I think using different protocols for things...

Now, that doesn't mean dovecot couldn't support more protocols.  Just
as it already supports multiple protocols (pop3 and imap) it could add
others...  No reason not to, and not reason to piggy back them through
the IMAP session, IMHO.

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!