> ISPs were doing more and more blocking of port 25 and 587 from user connections to fight spam, and some mobile carriers had even more strict filter

Honestly, I personally (and FWIW, I understand that my personal opinion is not terribly valuable here ;P) feel like being part of an arms race against the ISP to not get blocked to be a battle that isn't ever going to end: I mean, even if you get to the point where they can't look at the traffic stream and see that it is SUBMIT-over-HTTP (as maybe it is SUBMIT-over-HTTPS) they can always block by endpoint. Is the next step SUBMIT-over-TOR? The devices that people are using are getting more and more locked down: they can just start checking the data streams before they are encrypted.

> we were actually proposing SUBMIT-over-HTTP because, drum roll, HTTP routeability was less complex and more predictable

Yeah, if a design criteria is "not get blocked", then "over HTTP" seems like a better option. For outright simplicity, you could even just have a very tiny shim protocol (along the lines of the first step of WebSocks) that allows an HTTPS connection to upgrade to an already-authenticated SUBMISSIONS connection that is nothing more than a direct proxy through to a SUBMISSION server. This could be specified in just a few page document and, as it doesn't allow access to the SUBMISSION server until you've already authenticated against the HTTPS one, probably adds fewer security issues than might otherwise be imagined.

(Although, if you want to deal with HTTPS blocking, you'd need something more complex; but if you drop all the way down to HTTP you only gain yourself a couple years before your opponent just starts blocking you using deep packet inspection: if the ISP wants to block you, and they have made it clear that they do by explicitly and knowingly blocking port 587, and you feel that the correct way to fix these blocks is using technology, then if you don't go the full HTTPS route it seems like nothing more than a waste of everyone's time; and once you go HTTPS, you get the advantage of guaranteed-to-be-proxied bidirectional sockets.)

> if you want to forward an email, on a mobile device, you'd have to download the email + all attachments, and then reupload the message through SMTP

Yeah, this is definitely a good case for having some kind of integration. I will again state that I haven't yet looked into BURL, but I intend to do so to get a better understanding of the issues involved here.

> When you consider someone like Google implementing mail on a BigTable cluster,

The main thing I've run across that is difficult to implement in this context is that of message sequence numbers, especially with regards to how they interact with EXPUNGE (but also somewhat in general). I almost brought this up to imap-protocols a couple months ago, but I found a solution (as yet unimplemented: right now I'm still pretty-much-linear for that one case of EXPUNGE as I rebuild my MSN cache; it turns out there are some cute algorithms that should allow me to store a fairly small block of data in a single row and update it fairly efficiently during EXPUNGE) that tided me over long enough to now see Brandon Long bringing up the complaint himself.

If anything, I'd be then looking for just one small extension that I call (temporary name) UIDFTW, which when ENABLEd removes the client's ability to ever again use a message sequence number, forces the return of UID in untagged FETCH responses, forces the return of VANISHED instead of EXPUNGED, and replaces the message sequence number in an untagged FETCH response with "*" or "-" or "NIL" or "0" or some other "blank" token. This feature would be trivially implemented by existing e-mail servers: in fact, the first and final requirement could be made optional (as the client now also knows to ignore them) making this somewhat equivalent to the requirements of QRESYNC for servers that have no trouble with message sequence numbers.

However, for servers that do have a serious issue attempting to maintain message sequence numbers, they could then "relieve their burden" once this extension is activated, and not have to generate or keep around a message sequence number map for sessions that ENABLE this feature. If it is then supported by just a couple major clients, that will already be a help for servers that were willing to implement message sequence numbers, but just hated it from a resource-management and performance perspective. But, you could go further: one might eventually see clients that simply refuse to talk to a server that doesn't have it, or vice-versa. This, though, seems like a highly-minimal modification to the existing system that provides a very nice forward-looking path to something that has no problems with "big data".

Otherwise: IMAP seems fine, but I certainly have nowhere near as much context as you do; I would thereby find it utterly fascinating if you'd be willing to elucidate any (or even just one) other issues (than the message sequence number problem) that I haven't yet noticed that are going to cause me serious problems as I polish up my "big data" implementation of IMAP or make more progress on a mobile IMAP clients (not certain if I will actually be releasing either publicly, but certainly intend to switch to the server for my company's needs in the near future, and would start using the client myself).