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. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows: EXECUTE command parameter, parameter .... On the server side is a config file that has the commands that execute will allow and what programs they run. When the execute command is seen by Dovecot then Dovecot runs the program in the list with the 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 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. With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server. 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. 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 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: 999 EXECUTE smtp 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 999 helo ctyme.com 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] 999 mail from:marc at perkel.com 999 250 OK 999 rcpt to:dovecot at dovecot.org 999 250 Accepted ...... 999 quit 999 OK Who likes this idea?
I love this idea! I know it wouldn't be part of the standard IMAP specification, and you'd probably have to have an extra capability such as CUSTOMEXECUTE or something in the IMAP capabilities, which Thunderbird would have to look for before it allows the use of the plugins. As you suggested, this would make it so much easier to create an Exchange-style account with Thunderbird/other client software. Anyone else? Andy. Marc Perkel wrote:> 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. > > IMAP establishes a connection between the client and the server. > Wouldn't it be great if it could be a conduit to let custom > Thunderbird plugins talk to custom server application over the IMAP > interface? For example, personalized server settings. Suppose for > example I want Thunderbird to edit my server side white lists or black > lists or any other setting? Wouldn't it be nice if IMAP supported > these changes? The connection is made. It's a secure connection that's > been authenticated. Lets use it! > > Here's my initial thoughts on this. Suppose we extended IMAP to > include an EXECUTE command as follows: > > EXECUTE command parameter, parameter .... > > On the server side is a config file that has the commands that execute > will allow and what programs they run. When the execute command is > seen by Dovecot then Dovecot runs the program in the list with the > 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 > > 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. > > With a tool like this one can write generic applications easily that > would greatly expand what email clients can do interacting with the > server. 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. > > 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 > > 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: > > 999 EXECUTE smtp > 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 > 999 helo ctyme.com > 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] > 999 mail from:marc at perkel.com > 999 250 OK > 999 rcpt to:dovecot at dovecot.org > 999 250 Accepted > ...... > 999 quit > 999 OK > > Who likes this idea? > > > > !DSPAM:37,4647190f343946551815980! > >
On May 13, 2007, at 9:55 AM, Marc Perkel wrote:> 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. > > IMAP establishes a connection between the client and the server. > Wouldn't it be great if it could be a conduit to let custom > Thunderbird plugins talk to custom server application over the IMAP > interface? For example, personalized server settings. Suppose for > example I want Thunderbird to edit my server side white lists or > black lists or any other setting? Wouldn't it be nice if IMAP > supported these changes? The connection is made. It's a secure > connection that's been authenticated. Lets use it! > > Here's my initial thoughts on this. Suppose we extended IMAP to > include an EXECUTE command as follows: > > EXECUTE command parameter, parameter .... > > On the server side is a config file that has the commands that > execute will allow and what programs they run. When the execute > command is seen by Dovecot then Dovecot runs the program in the > list with the 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... I think this is a fantastic idea! I'm always opposed to proprietary extensions to standardized protocols, but in this case, it may be useful enough to gain acceptance. With Dovecot (as far as I can tell) quickly becoming the dominant IMAP server, it probably has the "push" to be able to pull this off. Of course to make it useful you'd need some client support...that's even more work than implementing it in the server, multiple clients 'n all.. -Dave -- Dave McGuire Port Charlotte, FL
On Sun, 2007-05-13 at 06:55 -0700, Marc Perkel wrote:> IMAP establishes a connection between the client and the server. > Wouldn't it be great if it could be a conduit to let custom Thunderbird > plugins talk to custom server application over the IMAP interface? For > example, personalized server settings. Suppose for example I want > Thunderbird to edit my server side white lists or black lists or any > other setting? Wouldn't it be nice if IMAP supported these changes? The > connection is made. It's a secure connection that's been authenticated. > Lets use it! > > Here's my initial thoughts on this. Suppose we extended IMAP to include > an EXECUTE command as follows: > > EXECUTE command parameter, parameter ....I think this could be done in almost standard way with METADATA extension (http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt). It allows setting and getting any key=value pairs in the server (also for mailboxes). Then you could have a Dovecot plugin that listens for some specific keys and handles them in whatever way you want.> 100 execute blacklist add joe at smith.com > 100 okMETADATA doesn't really support adding/removing, but it could be kludged something like this: 1 setmetadata "" "/x-blacklist/joe at smith.com" (value.priv "1") Although the joe at smith.com can't contain "*" or "%" characters. If that's needed then the string could be base64 encoded. Or the address could be in the value and the key would contain some kind of a unique ID. Listing blacklist would work like: 1 getmetadata "/x-blacklist/* value.priv" Anyway all of this would mean that if client implements a standard METADATA browser you could edit these kinds of lists without any special support from the client. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070513/26471e8e/attachment.bin>
On Sun, 2007-05-13 at 06:55 -0700, Marc Perkel wrote:> 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: > > 999 EXECUTE smtp > 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 > 999 helo ctyme.com > 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] > 999 mail from:marc at perkel.com > 999 250 OK > 999 rcpt to:dovecot at dovecot.org > 999 250 Accepted > ...... > 999 quit > 999 OKAnd as for this, I think embedding SMTP inside IMAP session only complicates things. LEMONADE support (http://www.ietf.org/html.charters/lemonade-charter.html http://www.lemonadeformobiles.com/index.html) is apparently being implemented in all kinds of mobile clients and probably will get used a lot more. They're not using port 25 for sending messages, they're using port 587 which requires authentication (RFC 4409). So instead of trying to create a new non-standard implementation, why not just use the submission port, which is pretty much guaranteed to be the standard future way of sending messages? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070513/78900c5e/attachment.bin>
On 5/13/07, Marc Perkel <marc at perkel.com> wrote:> 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. >Somewhat off topic. I long time ago rather than making just a intranet/extranet website that dealt out reports I made a imap daemon in perl that would also serve the same report. Easily navigated virtual folders and subject lines that helped with the content and attachments. The backend would handle the authentication, new/read/flag, caching the reports if needed, automatic folder subscription. This was very useful for people that live in outlook, need to get price lists on the road. The phrase 'awesome the noon call center report is done' isn't something that you often think you would hear, but is priceless. I also made a imap front end to bugzilla in much the same manner for people that couldn't handle bugzilla but that I wanted to be involved (project managers / executives). Product Folder->Component Subfolder->Threaded Bugs all coupled with a smtp2bugzilla gateway. I find imap's ability to be secure and easy to integrate into the personalized desktop. For some things its better than the browser. Only thing that will get you in some of the above examples is a maniac anti-virus administrator that wants all the outlook copies to rip through your server frequently ... ouch. -- Gabriel Millerd
On Sun, 13 May 2007 06:55:59 -0700 Marc Perkel <marc at perkel.com> wrote:> 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. > > IMAP establishes a connection between the client and the server. > Wouldn't it be great if it could be a conduit to let custom > Thunderbird plugins talk to custom server application over the IMAP > interface? For example, personalized server settings. Suppose for > example I want Thunderbird to edit my server side white lists or > black lists or any other setting? Wouldn't it be nice if IMAP > supported these changes? The connection is made. It's a secure > connection that's been authenticated. Lets use it! > > Here's my initial thoughts on this. Suppose we extended IMAP to > include an EXECUTE command as follows: > > EXECUTE command parameter, parameter .... > > On the server side is a config file that has the commands that > execute will allow and what programs they run. When the execute > command is seen by Dovecot then Dovecot runs the program in the > list with the 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 okI like the idea of having to and from added to the w/b list. That way it would be way nicer to use with SpamAssassin.> 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. > > With a tool like this one can write generic applications easily > that would greatly expand what email clients can do interacting > with the server. 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. > > 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 > > 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: > > 999 EXECUTE smtp > 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 > -0700 999 helo ctyme.com > 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] > 999 mail from:marc at perkel.com > 999 250 OK > 999 rcpt to:dovecot at dovecot.org > 999 250 Accepted > ...... > 999 quit > 999 OK > > Who likes this idea?I love that idea. Especially if it could run it through a specified program for deliver as well as passing the username, from, and password to the program. It may seem like a silly idea to pass that to the program, but it does have a awesome usage. That way the backend program can fetch the outgoing SMTP server through some method and figure out how to send it. Been kicking around writing something like that for QPSMTPD. It would be nice for with squirrelmail.
Timo, Think outside the box on this. Create a new standard. Sometimes someone has to make the move and lead the standard instead of following it. This is new territory. Let's just try it and see where it goes.
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 fileYes, 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 okYou'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 okAnd 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!
On Sun, 2007-05-13 at 06:55 -0700, Marc Perkel wrote:> 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. > > IMAP establishes a connection between the client and the server. > Wouldn't it be great if it could be a conduit to let custom Thunderbird > plugins talk to custom server application over the IMAP interface?Why do you always want to stuff everything into IMAP?> For > example, personalized server settings.Isn't there some protocol similar to IMAP that solves this?> Who likes this idea?I strongly disagree with this idea. Too little definition, too much server dependence, not portable across installations. IMHO defining some behaviour that is so little related to the original purpose of IMAP is counterproductive. Besides, why do you need to do this with IMAP? There's a protocol that supports all this already, it's called ssh. You can even tunnel pre-auth IMAP tunnels through the same ssh connection :) johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070514/89d161f7/attachment.bin>
andy.shellam-lists at mailnetwork.co.uk
2007-May-14 13:41 UTC
[Dovecot] Thinking Outside the Box - Extending IMAP
I disagree about SSH. Firstly, how do virtual users fit into your proposed setup? Secondly, as a service provider to the general public, the absolute LAST thing I want to be doing is opening up SSH access to my servers. Mark has a valid point in that you have to connect to the server via IMAP to get your mail, why should you have to have a second protocol to do other things with the same mailbox? And why worry about a whole second set of authentication when you've got a pre-authenticated connection ready and waiting? I agree it's not portable, and not ideal (ie. look at M$ Exchange's handling of custom server features), but Timo's suggestion of using the METADATA extension may strike the ideal balance between an extensible feature and the IMAP standard. Andy. Johannes Berg <johannes at sipsolutions.net> wrote:> On Sun, 2007-05-13 at 06:55 -0700, Marc Perkel wrote: > > 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. > > > > IMAP establishes a connection between the client and the server. > > Wouldn't it be great if it could be a conduit to let custom Thunderbird > > plugins talk to custom server application over the IMAP interface? > > Why do you always want to stuff everything into IMAP? > > > For > > example, personalized server settings. > > Isn't there some protocol similar to IMAP that solves this? > > > Who likes this idea? > > I strongly disagree with this idea. Too little definition, too much > server dependence, not portable across installations. > > IMHO defining some behaviour that is so little related to the original > purpose of IMAP is counterproductive. > > Besides, why do you need to do this with IMAP? There's a protocol that > supports all this already, it's called ssh. You can even tunnel pre-auth > IMAP tunnels through the same ssh connection :) > > johannes >_________________________________________________________ DISCLAIMER This e-mail was sent through a Mail Network server. The Mail Network accepts no liability for it's content.