On Mon, Feb 13, 2012 at 10:56:49AM +1300, Adrien de Croy wrote: > Finally, one of the things I am keen to see disappear with IMAP5 > (for want of a better name) is the requirement for clients, admins > etc to deploy multiple protocols - e.g. allow submission in IMAP. > This is because it's frankly a large (and should be unnecessary) > admin burden trying to support 2 protocols for mail (e.g. SMTP + > POP3/IMAP4). Mail users don't understand the significance, they > just submit support tickets because they can retrieve mail but not > send. Firewalls block ports, ISPs intercept / block port 25 (NZ > largest ISP does this), multiple protocols = multiple realms for > credentials, multiple implementations of authentication and > authorization etc.
Absolutely agree. There has to be a way to do basic "client wants to upload a message to Sent (possibly upload it to Drafts first and then move it to Sent, with a copy going out to the destination too) within the one protocol. If you're doing something more fancy, there's still SMTP. > Having to have another protocol to implement to get notifications > back probably over another channel etc makes this issue worse not > better. Similarly, there needs to be a way to do notifications in-protocol. I still think that being compatible with an external protocol as well is good. Either way the notification should need to be nothing more than a new HIGHESTMODSEQ value from which the client can update whichever views it's interested in. To reduce roundtrips, it would be nice to register a view on which you want updates pushed rather than just getting a new modseq and having to ask for the updates... but that's a minor optimisation compared to having to run a "STATUS loop" over all your folders or open hundreds of separate TCP connections to get information. Bron. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
