Re: [Imap-protocol] Re: Suspend/Restore feature proposal
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <20121126184814.Horde.pVkfF8iCAZNxKh-rRJmQ2g1@bigworm.curecanti.org> |
Quoting Brandon Long <[email protected]>: > On Mon, Nov 26, 2012 at 4:32 PM, Michael M Slusarz > <[email protected]>wrote: >> >> >> Because there's still no guarantee it's the same server/connection: that >> is the key to all of this. A server can "look" the same but that doesn't >> proves anything. >> >> What happens when the server is upgraded and UTF-8 searching now works? >> The CAPABILITY string is exactly the same. But UTF-8 has been marked as a >> bad charset so it will still not be available. And what about those >> commands that have been determined to be broken previously in the session? >> It is reasonable to expect the CAPABILITY string to be the same between >> point releases of an IMAP server, but the server may have fixed the bug >> that was causing bad command behavior. > > So, you deduce bugs in the server and then remember them... and this is > better than violating the ID spec? Yes. In fact we are quite proud of this. 100% foolproof and works on every server past, present, and future. Not sure how you are supposed to do this on IMAP servers that don't support ID. Or don't send version information: Dovecot, for one, doesn't by default. Or for installations that use a version of your software released before a particular IMAP server even breaks (full disclosure: the recent Cyrus break is weird because it sent a BYE and terminated instead of a failed command, so that wasn't previously scanned for so we weren't catching this until recently. so we're not perfect either.). IMAP command sniffing = javascript browser sniffing. The days of parsing a browser's User-Agent field are so 1999. michael _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol