This bug is actively exploited by IMP version 4.1.1, since it may send username data as a string literal as part of the LOGIN command, and could be exploited by any host on the internet if a crafted IMAP command is sent to imapproxy in Not Authenticated State.
As a temporary workaround, do not upgrade to IMP 4.1.1 if you're currently
running an older version and use a firewall (either host-based or external)
to limit access to imapproxy such that only your webmail server may connect
This bug has been worked around in 1.2.5rc2, but not fixed. If imapproxy encounters a string literal instead of a username, it will simply close that connection instead of exiting. A full fix will be released in a later version of imapproxy, once the parsing engine has been rewritten.