1. General
  2. Questions
0
Under review

SMTP Authentication Failing

JL Griffin 10 years ago • updated by Jeff Brown 7 years ago • 18
After workingfor several weeks, i upgraded my digitalocean droplet from a 1gb ram to a 2gb or ram system. somehow this broke a few things even though nothing else actually changed, i seem to have everything else sorted except this. now n roundcube and all desktop mail applications i can no longer send mail out i get the error (435 SMTP Authentication Failure). any idea what migh tbe casuing this or how to fix it?
Under review
Eugene Pankov (Project coordinator) 10 years ago
See /var/log/exim4/mainlog for more info
JL Griffin 10 years ago
thanks fo rthe location there, im used to postfix and didnt think to check the exim folder (duh)

ok this is what i am seeing in there:

2014-11-26 04:50:02 login authenticator failed for (mail.webnetvn.com) [127.0.0.1]: 435 Unable to authenticate at present (set_id=jlgriffin@webnetvn.com): failed to connect to socket /var/run/courier/authdaemon/socket: Permission denied
Eugene Pankov (Project coordinator) 10 years ago
Is Courier authd running? Are permissions on the folder ok? Is SELinux disabled?
JL Griffin 10 years ago
courier is running permissions for the folder are 777 and im on ubuntu so it'd be apparmour which is enabled by default.
JL Griffin 10 years ago
ok i chowened the dir for authdaemon to mail instead of root and changed permissions from 777 to 755 (i dont think the world should have write access to authdeamon...) and everything seems to be working now.
Ronnie 10 years ago
had the same error - re-creating new tls certs helped me here.
JL Griffin 10 years ago
Alright so i updated ajenti and the issue returned! this time the file authdaemon was owned by daemon:daemon so i once again switched it from daemon:daemon to mail:mail however the issue still persisted, so i gave it back 777 permissions and it once again worked. switching the owner back to daemon:daemon breaks it again. It must be mail:mail and 777 permissions. the concerning part there is the 777 permissions. why should the world have read write and execute access to something like that?
+4
Jester 10 years ago
I just got the same issue. It appears my /var/run/courier/authdaemon/socket was set as root:root 777.

I ran # chown daemon:daemon on the socket file and it appears to be working again.

Update: I rebooted the server and it appears that /var/run/courier/authdaemon/socket was run as root:root again. Anybody have any idea how to make it so it is run as a different user:group when courier service starts?
+1
Jester 10 years ago
Upon further investigation leaving the socket ownership to root:root is ok. To make the permanent change to fix this issue for me I changed the permission of the authdaemon directory to 755 which will probably remain fixed (even after reboot) until there is an update to courier-authdaemon.
JL Griffin 10 years ago
Interesting. For me out refuses to work unless ownership is mail:mailmail and permissions are 777. It worked no problem as 755 until the last update for me
Jester 10 years ago
It may be useful to note that I am running Debian, so the users for courier may be different depending on setup.
JL Griffin 10 years ago
Ah! that could be a factor. im on Ubuntu!
Mike Hodson 9 years ago
I'm seeing this when I attempt to debug authdaemon logging:

May 29 22:21:58 serv-pbx authdaemond[6533]: received auth request, service=exim, authtype=login
May 29 22:21:58 serv-pbx authdaemond[6533]: authuserdb: trying this module
May 29 22:21:58 serv-pbx authdaemond[6533]: Unsupported authentication type: login
May 29 22:21:58 serv-pbx authdaemond[6533]: authuserdb: REJECT - try next module
May 29 22:21:58 serv-pbx authdaemond[6533]: authpam: trying this module
May 29 22:21:58 serv-pbx authdaemond[6533]: incomplete username or missing password
May 29 22:21:58 serv-pbx authdaemond[6533]: authpam: REJECT - try next module
May 29 22:21:58 serv-pbx authdaemond[6533]: FAIL, all modules rejected

Mike Hodson 9 years ago
Nevermind. this was a broken script sending no actual username or password, during AUTH LOGIN .. it was sending blank lines..

+5
kptkip 9 years ago

Hi there,


I had the same issue. The phenomenon was that the permissions of the /var/run/courier/authdaemon/ folder was 750 after reboot. When I saved the mail configuration in ajenti it went properly (then it was 755). But after a new reboot everything was broken again....


So I searched for the init script of the courier-authdaemon and this led me to success.

This script overrides the permissions on every reboot.


In /etc/init.d/courier-authdaemon there is this line (around 39): 

mkdir -m 0750 $rundir

change it by: 

mkdir -m 0755 $rundir

save it, that's it!

Giordano Ricci 9 years ago

Same problem, this one worked for me.


Thank you.

Robert Bethke 9 years ago

Same issue here and this fix resolved the issue. At least until I update courier. Is there a way to fix without needing to modify this script?

Jeff Brown 7 years ago

I believe the correct solution, for Debian servers, is to add the user Debian-exim to the daemon group.

Customer support service by UserEcho