Seems to me we're getting bogged in the implementation details, or at
least going too far down that path. We don't even have a clearly
defined set of objectives for the features we want the protocol to provide.
here's my first cut off-the-cuff list:
* mail access
for obvious reasons.
* mail submission
For reasons I've stated already including ease of administrative and
configuration and support. This breaks down into:
- composing messages on the server
- providing delivery information (e.g. destination address)
* storage of mail client configuration
So that clients can be dumb, and you can hook a new client to your
mailstore and you don't need to configure anything else.
* server-side mail processing rules
Save downloading headers + MOVE etc to process filtering rules. Also
saves synchronising such rules amongst multiple clients
* ability for server to "comment" on anything, e.g:
- that destination email address you gave me doesn't resolve (with MX or
A) or is otherwise bad.
- that attachment you uploaded contains a virus
- that subject is offensive...
- etc etc etc
this could be part of a broader notification framework. In the cases
where the IMAP server co-exists (as in WinGate for example) with SMTP
delivery agent, then delivery information could be communicated back to
the connected client. If we allow for it in the protocol, it can
provide benefit where it's available, and causes no issues if it isn't.
The general idea though is that anything should be able to be remarked
upon by the server.
* address book
* calendaring
* Any other feature to compete with Exchange.
* Any other feature we think would give us an edge.
In terms of design, I'd propose the following:
* single port. This minimises problems traversing firewalls etc.
* ability to access all mail (in all folders) through a single
connection, and receive notifications about all state changes to
anything of importance (probably with client-controlled filter)
* layered protocol. Bottom layer deals with connection security (e.g.
negotiating TLS) authentication, and advertisement of and connection to
sub-services. Next layer are the sub-services e.g. mail, calendar,
config etc. This eases gateway development, since a calendar gateway
can simply connect through to the calendar sub-service.
* compact yet extensible protocol message structure.
The debate of text-based vs binary protocols will forever rage, I tend
to prefer binary, since then you don't need to parse text which requires
escaping of characters which would otherwise be protocol delimiters.
Some of the downsides of text-based protocols can be averted by using
length prefixes instead of searching for (and therefore needing to
escape) delimiters. Even a mixture. Literal+ is a damn good design in
my view, since it allows a large literal to be transferred without it
having to survive parsing. It also allows any character set to go
through. HTTP is a nightmare in this respect.
* configuration attributes to be clearly defined (e.g. take a page from
various MIBs) so that attributes can be re-used between different
clients to the maximum extent. Clients can store arbitrary
configuration attributes against the mail account.
Regards
Adrien
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
