First, thanks _a lot_ for the guide, I followed it and it worked nearly flawlessly. I only had issues with SASL and Roundcube playing nice together (over TLS), which seems to be the main headache anyways
Maybe it's because the guide does non-TLS config first and then specifies changes to have a TLS config but since the final configuration states that the smtps/submission listener should restrict to sasl authenticated (logical) and does not allow unauthenticated local webclients by default I had to change a couple of things.
Of course, I could have just added
to
Code:
-o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
in /etc/postfix/master.cf for both smtps and submission, but it would not have been as clean.
Instead, I first changed the submission to launch in chroot, since the guide does not have it chrooted. Plus submission on port 587 is much newer than smtps on port 465 and should be used for Roundcube.
In /etc/postfix/master.cf use the following line (remove the second 'n' from the guide).
Code:
submission inet n - - - - smtpd
Then make sure that in /etc/default/saslauthd you follow the guide (The different path for the socket are described just above in the same file):
Code:
OPTIONS="-r -c -m /var/spool/postfix/var/run/saslauthd"
Then Roundcube needs to be modified in order to use submission on the correct port, and this is the big difference : authenticate itself.
So in main.inc.php (whatever your location is, if you're using Ubuntu 12.04 LTS and do not want the old 0.7.x version, you can just use a manual installation following Roundcube's own guide and point your webserver to it).
Code:
$rcmail_config['smtp_server'] = 'tls://localhost';
$rcmail_config['smtp_port'] = 587;
$rcmail_config['smtp_user'] = '%u';
$rcmail_config['smtp_pass'] = '%p';
$rcmail_config['smtp_auth_type'] = 'LOGIN';
- You must use tls:// for port 587 and ssl:// for port 465 since they are different protocols and won't work interchangeably.
- You must tell Roundcube to give login/pw info to the smtp server, otherwise it will not be authenticated and since you only allow sasl authenticated clients, it will fail.
- The only method that worked for me was "LOGIN", using CRAM-MD5 or MD5-DIGEST had the pam authentication fail (I guess maybe because it's stored in the DB as a crypt token derived directly from a plaintext and not from an MD5 digest but I might be wrong). Eventhough this is not the most secure login type since it's basically plaintext/base64, it goes through TLS (if you force submission TLS only as described in the guide) and therefore shouldn't be that much of an issue.
If anyone has a way to get any of the digest method to work, please do reply.
Also things to consider that weren't mentionned in the guide :
- Make sure /etc/pam.d/smtp is empty from anything else than what the guide mentions.
- You can test SASL with testsaslauthd command such as
Code:
testsaslauthd testsaslauthd -r <DOMAIN> -u <USER_WITHOUT_@DOMAIN> -p '<CLEARTEXT_PASSWORD>' -f /var/spool/postfix/var/run/saslauthd/mux -s smtp
and see what goes on in sasl (/var/log/mail.log), the pam.d (/var/log/auth.log) module and mysql (/var/log/mysql/mysql.log) database getting hit with the SELECT query.
- Some options that are worth considering since they help a lot debugging postfix :
Code:
debug_peer_list=<IP_OF_PEER_TO_DEBUG>
debug_peer_level=3
One last thing concerning the guide, at one point the term 'apassword' is used for both the mail users themselves (when generating the encrypt/salted string) and the database user for the maildb (virtual hosts files etc.), it could become a bit confusing.
Bookmarks