lmtpengine.c -- sasl_server_new call doesn't specify config_servername

[Michael Bacon]

I think we may have run across a bug in the lmtpengine.c code.

In trying to set up LMTP across the network with GSSAPI authentication, we 
were running into a problem.  For various reasons, we have servername: set 
to something other than the hostname, and our GSSAPI server principals are 
coded to the alternate name.  (as in, lmtp/imap.duke.edu rather than 
lmtp/hostname.domain).  On all of the other services, this works just fine, 
but on lmtp, the client fails to authenticate.

Looking in the code, there is a difference in how sasl_server_new is called 
in lmtpengine.c.  There are two calls to it.  The first (in execution) is 
in lmtpmode(), and passes NULL to the serverFQDN argument of 
sasl_server_new.

<line 1098 in lmtpengine.c, current CVS>
if (sasl_server_new("lmtp", NULL, NULL, NULL,
    NULL, (func->preauth ? localauth_override_cb : NULL),
    0, &cd.conn) != SASL_OK) {

The second, in reset_saslconn(), specifies config_servername in the second 
argument, the way it is called in all of the other services:

<line 949 in lmtpengine.c, current CVS>
ret = sasl_server_new("lmtp", config_servername,
                       NULL, NULL, NULL,
                       NULL, 0, conn);

When we attach a debugger to the process, the sasl_server_new in 
reset_saslconn() is definitely getting the right value passed to it, but 
for some reason it's not overwriting the original NULL, which then 
apparently defaults to the local host FQDN.

Was specifying NULL in the call in lmtpmode() intentional, or is it just a 
bug that got overlooked?  We're reasonably certain this will fix our 
problem, but wanted to know if it would break something else we hadn't 
thought of...

Michael Bacon
OIT Systems and Core Services
Duke University
---
Home Page: http://asg.web.cmu.edu/cyrus
Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html