saslauthd problems

[Greg Groth]

Just a report that I have determined the problem.  It turns out there 
was nothing wrong at all with my configuration, the port, or anything 
else.  The culprit was in fact a pix box (http://tinyurl.com/nnovb). 
Apparently there's an option for "smtp fixup" which blocks EHLO.  Once 
that was deactivated, everything worked fine.  I didn't notice that EHLO 
was being mangled until I bumped up the logging on Sendmail.  Sorry to 
put everyone through the trouble they did, and thanks again for all of 
your help.

Best regards,
Greg Groth

Patrick Ben Koetter wrote:
> * Greg Groth <ggroth at gregs-garage.com>:
> 
>>
>>Marek Turczyniak wrote:
>>
>>
>>>What about saslauthd.conf?
>>
>>At the risk of sounding ignorant, what file is that?  As I mentioned 
>>earlier, this was installed via a FreeBSD port, not the official 
>>release.  I read the man page that was installed for saslauthd and could 
>>find no mention of this file.  I do have a Sendmail.conf file, but I 
>>don't think that saslauthd is reading it for some reason.  Is there a 
>>way for me to increase the logging level of saslauthd?  Outside of 
>>maillog, which message I posted previously, the only instance I can find 
>>in the logs are as follows:
> 
> 
> I do neither run FreeBSD or do I run Sendmail, but this is how it usually has
> to fit together:
> 
> + Sendmail has linked libsasl to its binary
> + The libsasl library acts on behalf of Sendmail when authentication is
>   required.
> + libsasl reads Sendmail.conf to find out which password verification service
>   it should turn to to process authentication (in your case: saslauthd)
> + The standalone password verification daemon saslauthd creates a socket that
>   libsasl can connect to and process authentication
> + saslauthd must be configured to know where it should look for usernames and
>   passwords. Either you start it from command line and give it command line
>   options or you do have a script that does the job (and sources vars that
>   set the command line options).
> 
> Debugging usually goes like this:
> 
> Don't look at the application seeking authentication services from
> Cyrus-SASL.2.x.
> Turn to the password verification service and check that it runs and uses the
> correct method (to access an authentication backend such as a system password
> file).
> Then use "testsaslauthd -u <username> -p <password>" to verify you can
> authenticate. If that fails your application, Sendmail, will never succeed.
> To debug saslauthd, stop saslauthd if it is running and use the same command
> line options and add "-d" like in this example:
> 
> # /usr/sbin/saslauthd -m /var/run/saslauthd -a shadow -d
> 
> saslauthd will stick to the terminal and you can read debug output.
> Open another terminal, run "testsaslauthd" as describeb above and see what
> happens. If that succeeds, turn to your app.
> 
> For a start the app should not be running chrooted, so you can be sure, it
> will 'see' the saslauthd socket. Some systems restrict access to the socket
> directory. you might need to add the Sendmail user to the group the socket dir
> belongs to (Debian does it that way...).
> 
> Use <http://www.jetmore.org/john/code/#gen-auth> to generate a base64 encoded
> string using PLAIN as mechanism. Copy the string, telnet to your app, say
> "EHLO foo" and then, after it has shown the list of capabilities, do this:
> 
> AUTH PLAIN <base64 string>
> 
> Sendmail should tell you then if authentication worked or not.
> 
> p at rick
>