Ticket #507 (closed defect: wontfix)

Opened 12 years ago

Last modified 9 years ago

pursue upstream bugs in Cyrus IMAP

Reported by: geofft Owned by:
Priority: normal Milestone: Upstream Utopia
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

  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.

Change History

comment:1 Changed 12 years ago by 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).

comment:2 Changed 12 years ago by 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.
  1. 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.

comment:3 Changed 10 years ago by jdreed

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

comment:4 Changed 10 years ago by geofft

Vaguely curious if cyrus-clients-2.4 helps here.

comment:5 Changed 9 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.