Ticket #403 (closed defect: fixed)

Opened 15 years ago

Last modified 14 years ago

mitmailutils should use krb5

Reported by: broder Owned by:
Priority: normal Milestone: Karmic Deploy (Canceled)
Component: mail Keywords: karmic
Cc: Fixed in version:
Upstream bug:


mitmailutils are currently using krb4 and Hesiod. Instead they should use username.mail.mit.edu and GSSAPI.

We still need a check for if the user is on Exchange. Hopefully mark will be exposing that to us over LDAP some time soon, and we can use that.

We should also be sure that Cyrus::IMAP resolves username.mail.mit.edu to poNN.mail.mit.edu before attempting to get a service ticket.

Change History

comment:1 Changed 15 years ago by broder

  • Component changed from -- to mail

comment:2 Changed 15 years ago by broder

Well, the CNAME resolution isn't an issue, but we seem to have a different one instead:

dr-wily:/mit/broder/sipb/src/athena/athena/bin/mitmailutils> ./from.pl 
from: Premature end-of-file on IMAP connection to sipb0.mail.mit.edu

With some more debugging, this seems like it's a bug in imclient's handling of particularly long return values from GSSAPI-encrypted connections:

dr-wily:/mit/broder/sipb/src/athena/athena/bin/mitmailutils> imtest sipb0.mail.mit.edu
S: A01 OK Success (privacy protection)
Security strength factor: 56
Protection error: decoding error: generic failure; SASL(-1): generic failure: Unable to find a callback: 32775
Connection closed.

I can work around this with imtest by using SSL. However, it doesn't look like Cyrus::IMAP can do SSL connections, so we need a new IMAP library.

The two options I see are Mail::Cclient. One might hope that the Perl module can do everything c-client can, although one might also hope that Cyrus::IMAP could do everything imtest can.

Another option would be to use Python's imaplib with some GSSAPI binding.  offlineimap does this with Apple's python-kerberos library, which is available for all the platforms we care about, except Etch. We could probably backport it ourselves.

There's also  sxw's GSSAPI bindings. Since I know almost nothing about GSSAPI and had no example code, I wasn't able to make these work as an imaplib authenticator, but I'm sure it's possible.

comment:3 Changed 15 years ago by broder

I should clarify that imclient only breaks when the IMAP command is returning a lot of data - seems to be order of hundreds, not order of tens.

comment:4 Changed 15 years ago by broder

  • Keywords karmic added

comment:5 Changed 15 years ago by rbasch

It looks like Mail:Cclient can do almost everything we need for mitmailutils, with the exception of getting the quota; the latter is apparently supported in the c-client library, but not in the perl module. We might be able to get by with a wrapper around imtest for mailquota, since it is pretty simple; note that the Exchange server currently does not support the IMAP quota extension anyway. I might be a bit concerned about long term support for the module, as it does not appear to have changed since 2004, but the current version (1.12) is in all platforms we care about, including lucid.

Python's imaplib does seem to support all of the functionality needed, including quota. I played a bit with a test client program to get the quota from a PO server, using the python-kerberos (PyKerberos) GSSAPI bindings, but it was unable to complete authentication successfully, apparently due to a bug in PyKerberos' wrapping of the username; I reported this upstream ( https://trac.calendarserver.org/ticket/355). Note that we would require version 1.1 of python-kerberos, or 1.0+svn2455 (in lenny and intrepid); version 1.0 (hardy) does not have bindings for gss_(un)wrap, which are needed.

I have not yet looked at sxw's GSSAPI bindings.

comment:6 Changed 14 years ago by jdreed

I propose the following:

  • We disable encryption by setting -maxssf => 0 in authenticate() (possibly conventionalizing on whether we're using GSSAPI or not), thus disabling encryption. That gets it working in Karmic with minimal changes. It's not really a change from previous behavior, since until quite recently, we weren't encrypting connections anyway.
  • We force it to connect to poXX.mail.mit.edu

Then we look into new command-line IMAP tools down the road that work with both Exchange and Cyrus.

Zephyr discussion from around 13:49 today suggests that this will likely be fine.

Here's a diff that gets from.pl working, the others are likely similar:

--- from.pl	(revision 24283)
+++ from.pl	(working copy)
@@ -61,7 +61,7 @@
 usage "Too many arguments" if @ARGV > 0;
 my $checkall = $opts{'A'} && ($search_key = "all");
 my $debug = $opts{'d'};
-my $host = $opts{'h'} || (split(" ", `hesinfo $username pobox`))[1] ||
+my $host = $opts{'h'} || (split(/\./, (split(" ", `hesinfo $username pobox`))[1]))[0] . ".mail.mit.edu" ||
     errorout "Cannot find Post Office server for $username";
 errorout "Exchange accounts are not supported yet. Try http://owa.mit.edu/." if $host =~ /EXCHANGE/;
 my $mbox = $opts{'m'} || "INBOX";
@@ -88,7 +88,7 @@
 # Connect to the server, and authenticate.
 my $client = Cyrus::IMAP->new($host) ||
     errorout "Cannot connect to IMAP server on $host";
-unless ($client->authenticate(-authz => $username)) {
+unless ($client->authenticate(-authz => $username, -maxssf => 0)) {
     errorout "Cannot authenticate to $host";

comment:7 Changed 14 years ago by jdreed

We decided at release-team to use maxssf => 0, and to rewrite mitmailutils with Cclient as a summer project.

comment:8 Changed 14 years ago by geofft

  • Status changed from new to proposed

I've taken essentially that patch in r24300 and uploaded it to -proposed; it seems to get me krb5 mitmailutils.

Remember to restore the hard dependency of mitmailutils and the use thereof (reverting r24086, r24088, and r24094 and possibly r24089 and r24095) when this gets moved to production.

comment:9 Changed 14 years ago by geofft

  • Status changed from proposed to closed
  • Resolution set to fixed

mitmailutils was moved to production a little while back; Evan also reverted r24086, r24094, and r24089/r24095 in r24307 and r24308, and I've just moved the three packages those touch (clients, dotfiles, and xsession) to production.

Note: See TracTickets for help on using tickets.