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.