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 =
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@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan