I do still feel the server in question is in violation of the RFC however the above point makes this unimportant. Violating both word and spirit of the RFC seems to be the norm rather than the exception with the IMAP servers we've been testing against.
I disagree. The IMAP community (with a couple of notable exceptions) tends to be quite good about sticking very closely to the RFCs. The implementations that are in violation tend to be written by people who don't actively participate on the IMAP mailing list, or with groups like IMAPEXT.
Large ISPs rolling their own IMAP interfaces are the worst offenders imho, alas this is exactly the kind of server our mostly consumer user base is likely to connect to!
The best thing you can do for the IMAP community is to publicly identify those implementations. In almost every case the problem can be solved by educating the writers of the offending software. IMAP is complex, and developing IMAP clients and servers in isolation tends to lead to incomplete and incorrect implementations. You won't be helping interoperability by working around bugs, and most people in this forum will *strongly* encourage you not to do that.
Identify the broken servers, and help bring the authors of that software to this forum. If you approach the problem from that angle, we can most likely solve the problem at the source, and not compromise general IMAP interoperability.
--lyndon
