I ran across a system today that was using the VHCS control panel. It looks like the system wasn’t correctly configured to allow SMTP authentication. It uses Postfix as the MTA and Courier-IMAP for the Imap/POP3 server. It was populating the Courier-authentication database with email addresses and passwords to use for logging into the incoming mail server, but postfix wasn’t configured to use the same database for authenticating and providing an outgoing mail server.
This is what I had to do to get it working
Edit your system’s smtpd.conf file (/var/lib/sasl2/smtpd.conf for RedHat and derivatives. /etc/postfix/sasl/smtpd.conf for Debian and Ubuntu derivatives). And put in this content:
I think this is a default install looks like:
pwcheck_method: saslauthd mech_list: PLAIN LOGIN
So change it to this:
pwcheck_method: authdaemond mech_list: PLAIN LOGIN authdaemond_path: /var/run/courier/authdaemon/socket
Of course, make sure that the authdaemond_path is correct for your system, and change as needed.
Then restart postfix and see if that works. You can use my SMTP Authentication String tool to get your encoded password and try it through telnet. Tail your mail log to see if it gets any errors.
On the system I was working on. Postfix was configured to chroot the smtpd processes (in /etc/postfix/master.cf). I got errors in the mail log that looked like this:
Jan 24 19:52:46 host postfix/smtpd[14528]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory Jan 24 19:52:46 host postfix/smtpd[14528]: warning: SASL authentication failure: Password verification failed Jan 24 19:52:46 host postfix/smtpd[14528]: warning: host.local[127.0.0.1]: SASL plain authentication failed: generic failure
So, in that case, I simply hard-linked the courier authdaemon socket file inside of the chroot (/var/spool/postfix)
cd /var/spool/postfix ln /var/run/courier/authdaemon/socket courier-authdaemon-socket
Then change the authdaemond_path to just ‘courier-authdaemon-socket’. Restart postfix and it should work
Brandon,
thanks a lot ! this solves my problem, could you please explain why ? 🙂
I add a 777 chmod on “/var/run/courier/authdaemon/socket” !
@Stephane
It has been a while since I looked at this and don’t have access to that system to re-look at the configuration. You might need to chmod the socket file depending on which user needs access to it.
The technique ln /var/run/courier/authdaemon/socket courier-authdaemon-socket works nicely – but doesn’t survive a reboot when the link has to be deleted and recreated. Have you find a technique that will solve the same problem *and* also survive a reboot?
You can simply run smtpd process in unchrooted environment. That would solve this problem.