IMAP5 : or developments that should happen in email

When I first started work I was responsible for a UNIX server which acted as a departmental mail server. I remember in my inexperience randomly deciding to upgrade from a IMAP2 to IMAP4, with zero testing or consultation with the organisation email system administrator, luckily it worked!

Since then IMAP has stood still. In fact most internet protocols and RFCs have stood still, but that’s a different blog post.

It seems to me that it is in need of updating. I confess I am no longer a email administrator nor do I keep up with the ’email standards’ world.

I think any new additions to the IMAP standard should be optional and email clients and servers should be able to handle talking the current/earlier versions of the protocol.

I also think any new version should handle a efficient negotiation of what the server AND client can handle, that is to say: what features they want to (or can)  use.

What should a new version contain?

  • a ‘sync’ option, for working offline, and then sync’ing with the server, with the server handling what needs updating.
  • Address book : option feature. Allows contacts to be stored on server. Specifically the same server (and settings) as the email IMAP server. There are already addressbook servers but this would be the same as the imap server: same protocol, same ssl/security. A user can log in from anywhere and get the same address book. (of course the server is free to act as a proxy where it reads/write the addressbook details from a specific addressbook server, but the important thing is that the client works with one server).
  • Filters. Yes many MTA (email delivery) agents, such as exim, can have filters. But you normally have to log in to the server and know their syntax to set these up. The other current option is to use a client like Thunderbird open with filters set. I keep my work PC running 24/7 to filter mail-list emails and move stuff to ‘Junk’. But I would like to see an optional addition to the IMAP protocol which allows clients (like Thunderbird) to set the filtering at the server. The user uses the client interface, but the filtering happens at the server end. I see this as one of the most pressing needs of an email protocol.
  • As mentioned above, a IMAP5 (or whatever) should negotiate which of the above it can handle, if it doesn’t do ‘addresses/contacts’ for example, fine, the client reverts to storing this locally. And of course, it is up to the software software and administrator if the server stores filters/addresses locally or acts as a proxy for another application.
  • Email sending: this may be the most controversal suggestion. At the moment you need to setup two protocols within a mail client, an incoming mail (IMAP/POP) and a outgoing, both with ports, security, encryption etc. Other internet protocols, like usenet, can handle both. Why should IMAP handle both. Accept the same as SMTP, and simple pass it on to a defined SMTP client. It means the user only has to setup and authenticate against one server.
  • Handle POP. This may sound odd, but what if a client said ‘Hello IMAP server, do you speak POP’, and if it gets a positive answer a POP exchange takes place. Why? Some users/clients may prefer it. Yet by letting IMAP handle it the email server only needs to be listening on one port and run one server. Ideally the IMAP server would recognise when a client is atarting a POP session and automatically revert to POP-mode. i.e. you could use an old POP client which has been told to connect to the IMAP server port and the IMAP server recogines the client only talks ‘POP’ and reverts to acting like a POP server.

Finally I would like to see an ‘auto configure’ option for email. Thing about it. If I tell my email client that my email address is cjk@company.co.uk then it should be possible for my email client to query company.co.uk for server settings for user ‘cjk’, in the same way that a client can get DNS or MX information for a domain. I can not see that (though I am fairly ignorant on the matter) specifying server details (IMAP, security level, port, etc) via a protocol for a user account should not be a security risk (though it may be definition show that an email address exists), and will mean that a user just has to provide their  email address and password to setup Outlook Express or Thunderbird.

Thinking out loud here. If this is stupid, or if I have missed something, let me know in the comments.

2 Replies to “IMAP5 : or developments that should happen in email”

  1. Ah, I totally agree with this wish list. Used to be involved in email stuff years ago, I have been an IMAP addict ever since, and I have always wanted to see these features implemented in IMAP. Especially the address book stuff. I have been trying all kinds of sync/ldap mechanisms etc., but still no real solution. My personal email provider since a long time http://fastmail.fm now implemented an LDAP database on their servers, which is getting close. What next?

  2. Some extra remarks since you updated this post, and also to take care of my extra thinking ;-)
    – IMAP address book should not have to be on the same server, I mean you should also be able to connect to this from other (web)email accounts with other email providers or the same.
    – There is a Thunderbird addon (Sync Kolab) that uses IMAP servers to store contacts, but not in a very usable way
    – Server based filters functioning in ALL clients (also web) is indeed very important
    – SMTP: with Thunderbird you can already only use IMAP for reading and a general (local) SMTP config for sending, but that is not en IMAP feature
    – Handling POP, I think this should not really be an IMAP feature. A lot of mail servers provide IMAP and POP already, but it is not an automatic feature of the IMAP protocol
    – automatic configuration, great idea too, like the SRU explain function!

Comments are closed.