I have recently upgraded from Dovecot 1.2.10 to 2.0.beta3.
I have Postfix 2.3.3 and use Dovecot to provide SASL auth for Postfix.
# dovecot -n
# 2.0.beta3: /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 2.6.18-8.1.14.el5 i686 CentOS release 5 (Final)
auth_mechanisms = plain apop login
auth_worker_max_count = 5
mail_location = mbox:~/Mail:INBOX=/var/spool/mail/%u
mail_privileged_group = mail
mbox_write_locks = fcntl dotlock
passdb {
args = /usr/local/etc/dovecot.passwd
deny = no
driver = passwd-file
master = no
pass = no
}
passdb {
deny = no
driver = pam
master = no
pass = no
}
protocols = imap pop3
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
}
ssl_cert = </etc/postfix/sbh16-cert.pem
ssl_key = </etc/postfix/sbh16-key.pem
userdb {
driver = passwd
}
Since upgrading to 2.0.beta3 I have started seeing notices like
Mar 6 07:06:20 sbh16 postfix/smtpd[30273]: warning: SASL: Connect to
private/auth failed: Resource temporarily unavailable
Mar 6 07:06:20 sbh16 postfix/smtpd[30273]: fatal: no SASL
authentication mechanisms
in my maillog. I don't see them too often (an average of about 2
occurences per day), and they seem to be related to spam or some kind
of attack. I am able to send using SASL authentication from my own
client OK.
The relevant postfix config settings are
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
Postfix and its configuration haven't changed from what I used with
Dovecot 1.2.10.
With Dovecot 1.2.10, I rarely if ever saw these failures.
Is this a case of the socket being in use when another auth request
arrives or is it something else? And if it is the socket in use, is
there some change in 2.0.beta that would cause the socket to be busy
longer?
--
Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan