saslauthd stops working

[Dan White]

On 04/12/09 16:47 -0600, Cliff Hayes wrote:
>I don't understand the authentication process.  I have all those auth
>options in sendmail.mc (EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN) but
>telnet ehlo only reports LOGIN and PLAIN.  Do email users need anything more
>than that?  Will their email clients make use of EXTERNAL, GSSAPI, DIGEST,
>CRAM?  If so, then I have to learn how to turn them on.  Would you happen to
>know of a how-to link?  I have two fat sendmail books and they are next to
>useless.  Internet searches have turned up nothing.

While this problem is happening, does testsaslauthd work? That should help
to narrow the issue down.

As I understand, all mechanisms will be advertised, except where restricted
by a mech_list statement in your smtpd.conf command, and where the
mechanism can be initialized. I don't have any experience with configuring
your mechanisms within the sendmail.mc config.

You can use pluginviewer/saslpluginviewer to see which mechanisms are
installed and can be initialized.

In my ISP experience, I have not ran into imap/smtp clients that require
anything more than PLAIN and LOGIN. Some will use stronger mechanisms like
DIGEST-MD5 and fall back to PLAIN/LOGIN if that fails. 

Usually imap/pop3 clients will fall back to PLAIN, and smtp clients will
fall back to LOGIN. If only offering PLAIN/LOGIN, you should offer SSL/TLS
support.

If you're dealing with Microsoft imap/smtp clients that have SPA (Secure
Password Authentication) checked, then you need to offer the NTLM
mechanism. But even then, SPA authentication is hit and miss depending on
the client (which version of NTLM it's expecting). I would recommend you
encourage your users to turn that option off if you have SSL/TLS support.

Your pwcheck_method statement only applies to how PLAIN and LOGIN
mechanisms authenticate (and how the older IMAP 'login' command
authenticates). saslauthd does not authenticate EXTERNAL, GSSAPI,
DIGEST-MD5 or CRAM-MD5.

DIGEST-MD5 and CRAM-MD5 will use your auxprop plugin(s) to authenticate the
user, which will reference the auxprop's database to retrieve the user's
clear text password. Typically, those are retrieved from /etc/sasldb2,
unless you're using the ldapdb or sql auxprop plugins.

GSSAPI won't initialize without the sasl library finding an appropriate
kerberos ticket cache, in my experience.

EXTERNAL is dependant on the server (sendmail/imapd) informing the sasl
library that there's an external security layer present (such as TLS).
I don't believe you can force EXTERNAL support from the cyrus library
configuration (e.g. smtpd.conf).

-- 
Dan White