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 <rt...@sciencetools.com> > To: postfix-us...@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.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 rt...@sciencetools.com, http://ScienceTools.com/