After spending a frustrating afternoon migrating users to a new email server, I am more convinced than ever that we need an integrated, open-standard mail client protocol. Let us call it imap5.
imap5 would address the following problems with current client/server mail protocols:
1. The need to configure separate incoming and outgoing connections.
2. The use of the same port for both client and backhaul communication, which prompts heavy firewalling of port 25 on corporate networks, often making it impossible to send mail at all.
3. The need to store long lists of configuration options (server, port, authentication, encryption, all twice) on the client.
Solutions to these problems already exist, but are not widely supported.
1 and 2. Sending email via imap is possible on courier-imapd and mutt through the use of smart outboxes – draft emails uploaded to a given imap folder are automatically forwarded to an MTA process by the imap server. SMTP therefore need not be supported on the client.
3. IMSP allowed config options (amongst other things) to be stored in a directory service, but this was obsoleted by ACAP, which then died a death.
imap5 would include functionality derived from the above. In addition, imap5 should:
1. Encapsulate all communication in HTTPS.
2. Only require the user to input his email address, password and a URL (preferably the URL of his webmail service) into his client. Further settings would be read from HTML metadata.
3. Allow server options to be set, including password, display name, autoreply, forward, and arbitrary settings (e.g. filtering) to be defined in a companion protocol.
However (unlike RPC over HTTPS) imap5 would not try to support address books, calendaring or other groupware features – open protocols for these (LDAP, iCal) already exist.
The advantages of imap5 over RPC/HTTPS would be threefold:
1. Three-field client configuration form.
2. Scope limited to email service provision.
3. Open, incremental improvements to well-understood protocols.
The Fifth Wheel of andrewg 