I have not done extensive research on this error yet, but on Plesk servers running Postfix you may see this in your /usr/local/psa/var/log/maillog file from legit clients:
Aug 14 11:36:58 server1 postfix/smtpd[23419]: warning: customer-isp.net[192.0.2.1]: SASL DIGEST-MD5 authentication failed: authentication failure
Aug 14 11:36:58 server1 postfix/smtpd[1477]: A5CC82CA87F: client=customer-isp.net[192.0.2.1], sasl_method=CRAM-MD5, [email protected]
Notice that the failed DIGEST-MD5 authentication was immediately followed by a successful CRAM-MD5 authentication by the same customer (going by IP). This is where I need to do some more research, but for the time being, my theory is that there exists some email client(s) that does not handle DIGEST-MD5 properly, so it tries it first, since the server advertises the ability to do it, fails, backs down to CRAM-MD5 which works fine.
Now, also in the logs, I very occasionally see successful DIGEST-MD5 authentications. This tells me that some rarely used email client, or perhaps a rarely configured option in a common email client, does indeed support DIGEST-MD5 properly, and that Plesk/Postfix also support it properly, so turning it off may prevent someone from using it. After turning it off, the same user who had been using it, flipped to CRAM-MD5, so at this point in time I’m going to assume that any email program that can do DIGEST-MD5 can also likely do CRAM-MD5 so turning digest off will have no negative effects.
Why did I want to turn it off to begin with? Well, after implementing Fail2Ban (article on how to do that) on the server to block IP addresses of spammers and script kiddies, legit customers whose email clients were attempting DIGEST-MD5, failing, and then dropping to CRAM-MD5 started getting blocked by Fail2Ban because of their initial failures. Rather than tune Fail2Ban to ignore DIGEST-MD5 attempts, which would mean spammers could then just brute force away using DIGEST-MD5 with no consequence, I chose to remove the option of using DIGEST-MD5, at least until the point at which more email clients want to use it, and use it properly.
So, the fix is to simply get rid of DIGEST-MD5 as an option. To do that, edit /usr/lib64/sasl2/smtpd.conf. The default contents of the file will be:
pwcheck_method: auxprop saslauthd auxprop_plugin: plesk saslauthd_path: /var/spool/postfix/private/plesk_saslauthd mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN auto_transition: yes sql_engine: intentionally disabled log_level: 4
So change it to:
pwcheck_method: auxprop saslauthd auxprop_plugin: plesk saslauthd_path: /var/spool/postfix/private/plesk_saslauthd mech_list: CRAM-MD5 PLAIN LOGIN auto_transition: yes sql_engine: intentionally disabled log_level: 4
That does require a Postfix restart to take effect; i.e. (centos/redhat/scientific):
/etc/rc.d/init.d/postfix restart
Hello I found your article searching answers for a problem that I have with fail2ban blocking small group of users. I´m using Plesk 11.5 on CentOs 6.5.
My server provider helped me to install and setup fail2ban. It is working great it’s blocking lots of brute force attacks to my email accounts. But I’m having problems with a small group of users that are being blocked constantly. I’ve checked with them if their mail clients are showing login errors but everything seems to be fine. I’ve tried many different settings in jail.conf like increasing the maxretry to 10, 20, 30 but nothing seems to work to avoid the problem I´ve described.
I´ve searched in the logs looking for incorrect logins or any other entry related to a user IP´s and I found the following entries related to SASL Failed LOGINS:
Jun 4 09:20:51 server1 postfix/smtpd[34321]: connect from unknown[95.72.242.250]
Jun 4 09:20:51 server1 postfix/smtpd[25415]: warning: unknown[95.72.242.250]: SASL LOGIN authentication failed: authentication failure
Jun 4 09:20:51 server1 postfix/smtpd[25415]: lost connection after AUTH from unknown[95.72.242.250]
Jun 4 09:20:51 server1 postfix/smtpd[25415]: disconnect from unknown[95.72.242.250]
Jun 4 09:20:52 server1 postfix/smtpd[34321]: warning: unknown[95.72.242.250]: SASL LOGIN authentication failed: authentication failure
Jun 4 09:20:52 server1 postfix/smtpd[34321]: lost connection after AUTH from unknown[95.72.242.250]
Jun 4 09:20:52 server1 postfix/smtpd[34321]: disconnect from unknown[95.72.242.250]
Jun 4 09:22:07 server1 postfix/smtpd[24182]: warning: 95.72.242.250: hostname dsl-95-72-242-250-dyn.maxspee… verification failed: Name or service not known
I found your article and thought that it will resolve the problem so I disabled digest md5 in plesk as you recommend, but I still have users blocked by the jail.
At this point my only solution was disabling digest md5 in plesk but did not worked I’m guessing that the problem may be the way that my jail is configured.
This is the how the jail is configured:
[email-iptables]
enabled = true
filter = email-iptables
logpath = /usr/local/psa/var/log/maillog
action = iptables-multiport[name=smtp, port=”25,587,110,143,995,465,993″, protocol=tcp]
sendmail-whois[name=smtp, dest= [email protected], [email protected]]
maxretry = 10
findtime = 600
bantime = 7200
Additional notes:
I did a test configuring my Apple Mail to authenticate with the server using> TLS remote certificate and opened the Conection inspector, the connection to the server failed and after a few seconds my IP get blocked:
[root@serv1 ~]# cat /var/log/messages | grep fail2ban | grep 188.216.116.82
Jun 11 01:08:06 sat4 fail2ban.actions: WARNING [email-iptables] Ban 188.216.116.82
What do you think? Do you have any ideas? I hope someone can help me.
Thank you very much in advance!
Javcove