try
mail# sendmail -bt -d0.1
Version 8.x.y
Compiled with: DNSMAP IPV6_FULL LOG MAP_REGEX MATCHGECOS MILTER
MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS
PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TLS_EC
TLS_VRFY_PER_CTX USERDB XDEBUG
You should see SASLv2 in the list. It's sendmail's job to read Sendmail.conf and it has to be in the sasl2 lib directory. On my host that translates to:
/usr/local/lib/sasl2/Sendmail.conf
On 9/05/2022 2:00 pm, John Covici
wrote:
Thanks, I will try some of those -- neither in my system (gentoo) nor in my other systems do I have a saslauthd.conf anywhere (except under logwatch).. I will see if I can find where sendmail reads Sendmail.conf. Thanks. On Sun, 08 May 2022 21:57:10 -0400, Deborah Pickett wrote:On 9/05/2022 08:43, John Covici wrote:Thanks for your response, but no joy -- I get the same output from saslauthd -v and sendmail still thinks it has no mechanisms.I can only speak to the cyrus-sasl side of things (we use Postfix not Sendmail here), but this smells like there's another config file that you're not editing because you don't know it exists. Maybe your sendmail is running chrooted? If so, the socket that saslauthd is listening on might not be visible to sendmail, or at least not be at the path you think it is. On Debian, saslauthd listens in two locations, one for chrooted postfix and one for non-chrooted cyrus. Maybe some exploratory breaking of things will help. Introduce a deliberate typo into a config file to be sure that something is reading it. Run saslauthd under strace or equivalent and see what files it is asking the OS to read. Stop saslauthd entirely and see if sendmail's behaviour changes. Also: saslauthd (auth server) doesn't itself read sendmail.conf; that looks like it's something that the libsasl (auth client) library is doing under Sendmail. Make sure that you look at saslauthd's config file (/etc/saslauthd.conf) too. Deborah Pickett System Administrator Polyfoam Australia Pty Ltd
