0
Under review

SMTP Authentication Failing

JL Griffin 9 year бұрын updated by Jeff Brown 6 year бұрын 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?
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
Is Courier authd running? Are permissions on the folder ok? Is SELinux disabled?
courier is running permissions for the folder are 777 and im on ubuntu so it'd be apparmour which is enabled by default.
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.
had the same error - re-creating new tls certs helped me here.
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
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
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.
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
It may be useful to note that I am running Debian, so the users for courier may be different depending on setup.
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

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

+5

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!

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?

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