slackware 12.2; sendmail 8.14; sasl 2.1; authentication always fails (Thunderbird 2.0)

I just don't see anything else being logged, besides what I've provided.  I've already got sendmail dumping out everything for transactions (using -X/log/file which is the authentication log I've provided above) and got the debug category set to 95 (AUTH as per TRACEFLAGS), which provides no additional information in the log files during the auth process.  

Saslauthd itself is providing nothing in the log files aside from its startup and shutdown. Even debug mode provides no information relating to the auth.  In fact, here's a saslauthd debug session during a failed auth:
------------------------------
/usr/share/sendmail/cf> /usr/sbin/saslauthd -a shadow -d
saslauthd[13369] :main            : num_procs  : 5
saslauthd[13369] :main            : mech_option: NULL
saslauthd[13369] :main            : run_path   : /var/state/saslauthd
saslauthd[13369] :main            : auth_mech  : shadow
saslauthd[13369] :ipc_init        : using accept lock file: /var/state/saslauthd/mux.accept
saslauthd[13369] :detach_tty      : master pid is: 0
saslauthd[13369] :ipc_init        : listening on socket: /var/state/saslauthd/mux
---[here the mail got sent]---
saslauthd[13369] :main            : using process model
saslauthd[13369] :have_baby       : forked child: 13370
saslauthd[13370] :get_accept_lock : acquired accept lock
saslauthd[13369] :have_baby       : forked child: 13371
saslauthd[13369] :have_baby       : forked child: 13372
saslauthd[13369] :have_baby       : forked child: 13373
---[here I hit ctrl-C]---
saslauthd[13370] :server_exit     : child exited: 13370
saslauthd[13369] :server_exit     : pid file lock removed: /var/state/saslauthd/saslauthd.pid.lock
saslauthd[13369] :ipc_cleanup     : accept lock file removed: /var/state/saslauthd/mux.accept
saslauthd[13369] :ipc_cleanup     : socket removed: /var/state/saslauthd/mux
saslauthd[13369] :handle_sigchld  : child exited: 13370
saslauthd[13369] :server_exit     : master exited: 0
saslauthd[13371] :server_exit     : child exited: 13371
saslauthd[13372] :server_exit     : child exited: 13372
saslauthd[13373] :server_exit     : child exited: 13373
------------------------------

   Can you be more specific about what log file is being affected and what option or switch causes this information to be logged?   I just don't see anything else that shows any problems or errors, other than the auth stuff previously mentioned.

After digging around in the sendmail source code, I found the place in the code that the sasl call and error are occurring.  It is 'srvrsmtp.c' in smtp() about 25% of the way down in the source file.  The sasl server connection is initialized and setup within the source and the auth parameter is decoded and the user is set as needed.  

Then (right before the message("235 2.0.0 OK Authenticated") line), sasl_server_step is called to validate the username and encoded password (in the 'in' variable).  The return value (stored in result) is not SASL_OK (which it should be), and the out variable is null after the function call.

The error I pull from the call is "user not found: no secret in database".  This tells me that sasl within sendmail is NOT using the shadow password, but maybe 'sasldb' instead.  

I think perhaps its a setup problem with sendmail not initializing the sasl server correctly.  I'm not sure at this point how to verify this is truly the problem, but I will continue to hack the sendmail source to see if I can validate my findings and perhaps find a solution.

Of course, if anyone has any other ideas, I would appreciate it!

While perusing the Cyrus sasl documentation, I read something in the "Shared Secrets Mechanism" that says:

So, if I want to maintain CRAM or DIGEST, I have to maintain a second database of usernames and passwords.  I understand why (because in order to match against a shadow password, you have to have either the plain password that created the shadow or the shadow itself created from sendmail).  I just don't like the idea of maintaining a second database.  But, I can permission it so that only root has access (or the user running sendmail if that's the way it needs to be).  

During my course, I've read about OTP (One Time Password), which seems to be the next step in the CRAM/DIGEST authorization mech..  I know very little about it nor if sendmail even supports it...  I see that SASLv2 does, along with something called OPIE, so I might look into this..  

At any rate, I've recompiled both SASLv2 and sendmail to make sure all the necessary pieces are available in both.  I've also got a sasldb2 setup with the given user 'caveman' and a password..  but it is still not authenticating, and it makes me wonder if the libsasl2 is looking in a different location for the db file, or if it hasn't found the Sendmail.conf file.  I see no evidence in the logs (even with debugging on) for sasl that indicate it is opening it.  Looks like I'll be hacking the sasl source code now to see if the libsasl is finding the config files and the database.

Hi,

Yeah in fact it was what I was expecting :)

BTW you don't need digging into the source. You'd better inrease LogLevel in sendmail.log.

Somewhere in your logs you should have something like that:
saslauthd[30034]: ipc_init        : listening on socket: /var/run/saslauthd/mux

please check if this is the Socket that sendmail is listening:

# cat /usr/local/lib/sasl2/Sendmail.conf
pwcheck_method: saslauthd
mech_list: login plain
saslauthd_path: /var/run/saslauthd

Check if both are  looking for the socket in the same place.

BTW I think this will end-up as config errors rather than some compiletime problems. So Lets go over it together.

I understand that you're quite knowlegable in the area but it might still hinder you from looking for simple config files instead.

re: socket

Using saslauthd, it sets the socket to /var/state/saslauthd/mux and I've got Sendmail.conf confirming that (using saslauthd_path) and the debug log confirms it, too.  

I've been focusing on using CRAM/DIGEST, since I wanted to avoid plain-text authorization.  But, for the sake of getting this working (and since the connection is encrypted using SSL anyway), I'll set up sendmail and SASL2 to use plain.

[...time passes...]

OK, both are now setup for PLAIN authorization.  sasluthd is running:
---------------------------
~> ps auwx | grep saslauthd
root     19268  0.0  0.0   1992   608 pts/0    S    10:11   0:00 /usr/sbin/saslauthd -a shadow -d
root     19270  0.0  0.0   2208   716 pts/0    S    10:11   0:00 /usr/sbin/saslauthd -a shadow -d
root     19271  0.0  0.0   1992   412 pts/0    S    10:11   0:00 /usr/sbin/saslauthd -a shadow -d
root     19272  0.0  0.0   1992   196 pts/0    S    10:11   0:00 /usr/sbin/saslauthd -a shadow -d
root     19273  0.0  0.0   1992   196 pts/0    S    10:11   0:00 /usr/sbin/saslauthd -a shadow -d
---------------------------

and provided the following information during its startup:
---------------------------
saslauthd[19260] :main            : num_procs  : 5
saslauthd[19260] :main            : mech_option: NULL
saslauthd[19260] :main            : run_path   : /var/state/saslauthd
saslauthd[19260] :main            : auth_mech  : shadow
saslauthd[19260] :ipc_init        : using accept lock file: /var/state/saslauthd/mux.accept
saslauthd[19260] :detach_tty      : master pid is: 0
saslauthd[19260] :ipc_init        : listening on socket: /var/state/saslauthd/mux
saslauthd[19260] :main            : using process model
saslauthd[19260] :have_baby       : forked child: 19261
saslauthd[19261] :get_accept_lock : acquired accept lock
saslauthd[19260] :have_baby       : forked child: 19262
saslauthd[19260] :have_baby       : forked child: 19263
saslauthd[19260] :have_baby       : forked child: 19264
---------------------------


Sendmail.conf is set:
---------------------------
~> cat /usr/lib/sasl2/Sendmail.conf
pwcheck_method: saslauthd
mech_list: plain
saslauthd_path: /var/state/saslauthd
log_level: 7
otp_mda: sha1
---------------------------

Sendmail itself is configured to use plain:
---------------------------
define(`confAUTH_MECHANISMS', `PLAIN')dnl
---------------------------

I rebuilt the sendmail.cf, then stopped and restarted sendmail.

Now, when I try to authenticate the user, I get these lines from sendmail:
---------------------------
Aug 18 10:15:49 www sm-mta[19285]: cannot connect to saslauthd server: Connection refused
Aug 18 10:15:49 www sm-mta[19285]: Password verification failed
---------------------------

The saslauthd daemon is obviously running...  and, despite the -d on the saslauthd command line, and the log_level: 7 in the Sendmail.conf, saslauthd is not logging anything during this connection.  In fact, saslauthd is only showing the startup stuff in the log, and then when I stop the process, the shutdown stuff.

re: configuration issue vs compilation issue

I'm certain you are right on this.  The nice thing about hacking the source is that I can insert log points and show information in them that the program wouldn't normally show even with logging enabled.   Of course, this can be a very complicated way to solve problems with things like this...  and more than likely it is simply a matter of a configuration problem.

re: migrating to Postfix

I see this complaint often.  Sendmail is very complex.  If I didn't already have so much time invested in the issue, I might consider switching (of course, I know you're not suggesting I switch...  ), but that means learning a whole new system, and frankly I'm not ready to do that.  I still like Sendmail despite this setback. :)

But, I do appreciate your time and hope that we can hammer this solution out.

when the failure occurs, here is what sendmail is logging:
------------------------
AUTH failure ((null)): generic failure (-1) SASL(-1): generic failure: Password verification failed
------------------------

What little research I've done on this suggests what you've suggested, that sendmail is not finding the socket.
As you can see above, my Sendmail.conf points to the right place for the socket.  As well, I've got a symlink from /var/state/saslauthd to /var/run/saslauthd, just in case.

Although I don't have a solution yet, I do know more specifically where the error is occurring.  The problem is in the SASLv2 'plain' plugin, when it makes the called to check the password.

It is this:
---------------------------------
    /* verify password - return sasl_ok on success*/
    result = params->utils->checkpass(params->utils->conn, oparams->authid, oparams->alen, passcopy, password_len);
---------------------------------

in plugins/plain.c in  plain_server_mech_step.  Although I have verified it is receiving the authen (user name) and password correctly, I do not know why checkpass is failing. but I will soon. :)

Yeah in fact i was leading to find the source of the probelm I had told that this was a configuration issue ;-)

Certainly you did.  But why did you object to me closing this issue as I did?  

As much as I am very grateful for the extra insight, I only awarded you partial points because I ended up discovering which config file and what the actual problem was.  Your comments helped, but were more generic in reference to a socket problem.  In fact, your Sendmail.conf config file posted above does not have the correct socket path in it (it should be /path/to/statedir/mux not just /path/to/statedir).  

That is why I only awarded you partial points.  

In fact the problem is you did not close the question properly. But you've applied for a close. When a question in close progress updated it means an objection.

BTW you say:

> (it should be /path/to/statedir/mux not just /path/to/statedir).  

I did not know specifically what path sendmail uses on slackware so I've deliberately told literally "Path to statedir" hoping that you would update the path you2re using which you've later did on your further updates. This is why I've later updated the path in my further notes.