[Dovecot] Trouble adding sasl support via dovecot
Hello Folks,
I've been the admin of a site that uses Postfix with Dovecot on RedHat since, oh, gosh, maybe 1996? It's been a long time. I've never built it from source, though, just used the rpms (and I wonder if maybe that's my problem now). It just works, is reliable, and lets me be a very-part-time administrator.
Repeatedly over the last few years I've been asked to have our mail system "join the modern age" and provide mail sending capabilities for clients that aren't on our internal network - via their smart-phones, from home, etc. OK... Well, way back when the site was set up, smtp servers didn't do any kind of "auth", but along the way to solving this problem (trying to configure pop-before-smtp, someone mentioned that Postfix now has an auth mechanism that uses Dovecot and I should use that instead! Great! ... Except that I've spent between 16 and 20 hours on this with no joy, and while I hate having to ask for help, it's time to ask what things that are obvious to the less ignorant that I must be doing wrong... Certainly, given the solid history of Postfix and Dovecot, I must be the problem!
My problem statement is simply, "it should be working", but doesn't, and I don't get any announcement of "auth" when testing connections to Postfix as per directions here:
http://www.postfix.org/SASL_README.html#server_test
At least I haven't broken the normal functionality!
I'm building a new server on the latest Fedora Core (16), but it's lacking in some hardware and won't be ready for a while, so I'm working with FC 14, running Postfix 2.5.6, and Dovecot 1.2.8. It uses the "cram-md5" auth scheme (which works fine and I'd hate to change it if I don't have to). The system has been up and functional on these versions for a couple of years, and quite stable, we just can't send if we're not local.
When I do "postconf-a" it indicates cyrus and dovecot, so I take it that means Postfix has been built with sasl support. (I presume this means I don't have to compile it from source.)
First Dovecot. Its set up to provide all protocols, but only imaps and pop3s have ports forwarded through the firewall. Plain-text auth is disabled, ssl is set to yes, ssl_listen is not specified, and the cert and key files are in the default locations - and work. No cipher list is used. Dovecot's chrooted. The protocol sections imap and pop3 take ALL the defaults, as does lda (I've ignored sendmail_path = /usr/lib/sendmail) as I don't think it matters. "auth default {" has mechanisms set to cram-md5, digest-md5, plain, and login, with passdb passwd-file pointing to a file in /etc where the cram data goes. It's not using pam, and there's an OLD comment in the config:
# Experience says we need an empty passdb - passwd group:
which is followed by passdb passwd{}. Later, there's "userdb passwd {}.
All of that was configured long ago and has been functional.
The changes I've made to add sasl support primarily pertain to the "socket listen section of "auth default". There, the master section remains commented out while the client section has been uncommented, the path set to /var/spool/postfix/private/auth, mode set to 0660, and the user and group have been set to postfix. ...This is all as described here:
http://www.postfix.org/SASL_README.htmland http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
That's it for Dovecot. Now, to Postfix itself.
From the working environ, only listening on port 25, I simply added the following (as per directions already cited above):
smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous, noplaintext smtp_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous
And, of course, permit_sasl_authenticated was added to smtpd_recipient_restrictions.
I got the impression from the baove sources that Postfix will then use Dovecot's authentication mechanism via a socket it finds in its private/auth subdirectory.
NOT documented in any of those places, someone suggested I must turn on TLS. OK...
The documentation found here:
http://www.postfix.org/TLS_README.html
claims (intimates) that it's not possible to run a site on a self-signed certificate, however, there's ZERO budget for a signed certificate, so unless I can get one for ten bucks somewhere, that could be a deal-breaker here. However, we've been using self-signed certificates for a while now and wonder why an "exception" mechanism wouldn't exist. As that web page talks about "Netscape" I suspect it's very old and may no longer apply.
In any event, I tried this, too (after trying without). On the good side, an available Android phone, previously reading fine, but unable to send, no longer complained when the setup was changed to the imap username and password, same server address, TLS security type, and the server port of 25. HOWEVER, no mail has passed through it successfully, it just gives no error whatsoever, so far, while the server's log reports "Relay access denied."
Notably, when setting up TLS, Postfix complained when the smtpd_tls_key_file was incorrect, but did not complain when it was provided properly, suggesting it's reading and accepting my self-signed certificate and private key.
Ideas, please?!
And, by the way, what's port 465 all about? Some clients propose that's what should be used to send...
Thanks in advance for your help, Richard
Hi All,
it turned out to be the order of entries in stmpd_recipient_restrictions.
Regards, Richard
On Mon, 12 Mar 2012, Richard Troy wrote:
Date: Mon, 12 Mar 2012 10:14:09 -0700 (PDT) From: Richard Troy <rtroy@ScienceTools.com> To: postfix-users@cloud9.net, dovecot@dovecot.org Subject: [Dovecot] Trouble adding sasl support via dovecot
Hello Folks,
I've been the admin of a site that uses Postfix with Dovecot on RedHat since, oh, gosh, maybe 1996? It's been a long time. I've never built it from source, though, just used the rpms (and I wonder if maybe that's my problem now). It just works, is reliable, and lets me be a very-part-time administrator.
Repeatedly over the last few years I've been asked to have our mail system "join the modern age" and provide mail sending capabilities for clients that aren't on our internal network - via their smart-phones, from home, etc. OK... Well, way back when the site was set up, smtp servers didn't do any kind of "auth", but along the way to solving this problem (trying to configure pop-before-smtp, someone mentioned that Postfix now has an auth mechanism that uses Dovecot and I should use that instead! Great! ... Except that I've spent between 16 and 20 hours on this with no joy, and while I hate having to ask for help, it's time to ask what things that are obvious to the less ignorant that I must be doing wrong... Certainly, given the solid history of Postfix and Dovecot, I must be the problem!
My problem statement is simply, "it should be working", but doesn't, and I don't get any announcement of "auth" when testing connections to Postfix as per directions here:
http://www.postfix.org/SASL_README.html#server_test
At least I haven't broken the normal functionality!
I'm building a new server on the latest Fedora Core (16), but it's lacking in some hardware and won't be ready for a while, so I'm working with FC 14, running Postfix 2.5.6, and Dovecot 1.2.8. It uses the "cram-md5" auth scheme (which works fine and I'd hate to change it if I don't have to). The system has been up and functional on these versions for a couple of years, and quite stable, we just can't send if we're not local.
When I do "postconf-a" it indicates cyrus and dovecot, so I take it that means Postfix has been built with sasl support. (I presume this means I don't have to compile it from source.)
First Dovecot. Its set up to provide all protocols, but only imaps and pop3s have ports forwarded through the firewall. Plain-text auth is disabled, ssl is set to yes, ssl_listen is not specified, and the cert and key files are in the default locations - and work. No cipher list is used. Dovecot's chrooted. The protocol sections imap and pop3 take ALL the defaults, as does lda (I've ignored sendmail_path = /usr/lib/sendmail) as I don't think it matters. "auth default {" has mechanisms set to cram-md5, digest-md5, plain, and login, with passdb passwd-file pointing to a file in /etc where the cram data goes. It's not using pam, and there's an OLD comment in the config:
# Experience says we need an empty passdb - passwd group:
which is followed by passdb passwd{}. Later, there's "userdb passwd {}.
All of that was configured long ago and has been functional.
The changes I've made to add sasl support primarily pertain to the "socket listen section of "auth default". There, the master section remains commented out while the client section has been uncommented, the path set to /var/spool/postfix/private/auth, mode set to 0660, and the user and group have been set to postfix. ...This is all as described here:
http://www.postfix.org/SASL_README.htmland http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
That's it for Dovecot. Now, to Postfix itself.
From the working environ, only listening on port 25, I simply added the following (as per directions already cited above):
smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous, noplaintext smtp_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous
And, of course, permit_sasl_authenticated was added to smtpd_recipient_restrictions.
I got the impression from the baove sources that Postfix will then use Dovecot's authentication mechanism via a socket it finds in its private/auth subdirectory.
NOT documented in any of those places, someone suggested I must turn on TLS. OK...
The documentation found here:
http://www.postfix.org/TLS_README.html
claims (intimates) that it's not possible to run a site on a self-signed certificate, however, there's ZERO budget for a signed certificate, so unless I can get one for ten bucks somewhere, that could be a deal-breaker here. However, we've been using self-signed certificates for a while now and wonder why an "exception" mechanism wouldn't exist. As that web page talks about "Netscape" I suspect it's very old and may no longer apply.
In any event, I tried this, too (after trying without). On the good side, an available Android phone, previously reading fine, but unable to send, no longer complained when the setup was changed to the imap username and password, same server address, TLS security type, and the server port of 25. HOWEVER, no mail has passed through it successfully, it just gives no error whatsoever, so far, while the server's log reports "Relay access denied."
Notably, when setting up TLS, Postfix complained when the smtpd_tls_key_file was incorrect, but did not complain when it was provided properly, suggesting it's reading and accepting my self-signed certificate and private key.
Ideas, please?!
And, by the way, what's port 465 all about? Some clients propose that's what should be used to send...
Thanks in advance for your help, Richard
-- Richard Troy, Chief Scientist Science Tools Corporation 510-717-6942 rtroy@ScienceTools.com, http://ScienceTools.com/
Since you got it working, I'll just comment on a couple of things...
On Mon, 12 Mar 2012, Richard Troy wrote:
When I do "postconf-a" it indicates cyrus and dovecot, so I take it that means Postfix has been built with sasl support. (I presume this means I don't have to compile it from source.)
Correct...
From the working environ, only listening on port 25, I simply added the following (as per directions already cited above):
You really should separate AUTH to the port that is designed for it: port 587 (aka the 'submission' port/service)... just uncomment it (and its attendant lines) in master.cf
The documentation found here:
http://www.postfix.org/TLS_README.html
claims (intimates) that it's not possible to run a site on a self-signed certificate,
Where does it state any such thing? I've been using self-signed certs for 8+years with postfix...
You do have to 'accept' the certs in the clients though, and that cn scare some users. I've had zero problems with this in Android, and none in recent versions of iOS, although earlier versions required you to install the cert manually (could be done using Safari on the iPhone)...
Also, Outlook provides no simple way to Accept a Cert and store it permanently (Thunderbird does), so unless/until Outlook users import the Cert, they'll have to accept it each time they fire up Outlook and check mail.
And, by the way, what's port 465 all about? Some clients propose that's what should be used to send...
It is the *deprecated* SMTPS (smtp over SSL). All modern clients can use the submission service, but some older versions of Outlook/Outlook Express can only use 465. It doesn't hurt anything to have it enabled, but you shoiuld absolutely tell all other clients to use the normal submissions service (STARTTLS on port 587).
--
Best regards,
Charles
participants (2)
-
Charles Marcus
-
Richard Troy