pursue upstream bugs in Cyrus IMAP

[geofft]

1. As described in Trac #403, if you get a long IMAP response while SASL confidentiality protection is enabled, either Cyrus SASL or Cyrus IMAP barfs. This can be replicated in imtest. Is this fixed in a newer version, or do we need to report this uptream?
2. As described in Trac #403, you can't tell Cyrus::IMAP to use SSL (or TLS or whatever), although you can tell imtest to use it (with -s) which works around the above bug. A cursory glance indicates that it's simply missing an XS binding for the C function to STARTTLS.

Fixing both of these will make mitmailutils happy.

[jdreed]

The version of Cyrus::IMAP that comes with the latest release of imapd (2.3.16) does in fact support TLS. However, 2.3 isn't in Jaunty (or Karmic, or Lucid even).

[rbasch]

1. I believe the crash we see using privacy protection with SASL GSSAPI is actually likely a server-side bug,  https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2457, reported (by Sam) and apparently patched upstream over five years ago.

2. RHEL 5 has version 2.3 of Cyrus IMAP. I took a quick look at this, and don't believe it will help us; the perl module only seems to add support for the STARTTLS IMAP extension, which our servers apparently do not support.

[jdreed]

Anyone working on this should keep in mind that the future of e-mail at MIT does not involve Cyrus IMAP.

[geofft]

Vaguely curious if cyrus-clients-2.4 helps here.