[Dovecot] FIXED Re: Trouble adding sasl support via dovecot

[Richard Troy]

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 at ScienceTools.com>
> To: postfix-users at cloud9.net, dovecot at 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.html
> and
>     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 at ScienceTools.com, http://ScienceTools.com/