-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/29/2014 3:14 PM, Dennis Putnam wrote: > On 1/29/2014 9:35 AM, Dennis Putnam wrote: >> On 1/29/2014 8:49 AM, Dennis Putnam wrote: >>> On 1/28/2014 9:44 PM, Viktor Dukhovni wrote: >>>> On Tue, Jan 28, 2014 at 09:15:02PM -0500, Dennis Putnam >>>> wrote: >>>> >>>>> The following is in my main.cf. >>>>> >>>>> smtp_sasl_auth_enable = yes smtp_sasl_password_maps = >>>>> hash:/etc/postfix/sasl_passwd >>>>> smtp_sasl_security_options = >>>> You might think so, but that does not make it so. >>>> >>>>> However, when I run postconf, I get this: >>>>> >>>>> smtp_sasl_auth_enable = no >>>> That's the actual setting in main.cf, or else there is >>>> no setting of this parameter in main.cf, and so the >>>> default value is in effect. >>>> >>>> Run "postconf -n | grep smtp_sasl_auth_enable", and see >>>> for yourself where your mistake is. Some whitespace is >>>> more equal than other whitespace. >>>> >>>>> Can anyone explain what has happened? >>>> You have not set "smtp_sasl_auth_enable = yes", and >>>> perhaps other required settings are not in fact set as >>>> intended. >>>> >>> Thanks for the reply. I did not thing to use -n as >>> normally I use -d. The output is: >>> >>> smtp_sasl_auth_enable = yes >>> >>> Since there are no errors in the log, I can't imagine why >>> the difference. >>> >>> Can you confirm from my log that I am correct in that it >>> is not even attempting to authenticate (as opposed to some >>> failed authentication attempt)? The only change that may >>> have occurred is an automatic update. I am running this on >>> CentOS 6 and the current postfix version is 2.6.6. I would >>> need to dig through the 'yum' log to see what the previous >>> version was and whether or not an update occurred at the >>> same time as this problem. >>> >> I have just made another discovery. I have another mail >> relay that also requires authentication. That relay still >> works so it cannot be the sasl parameters per se. What >> actually triggers the authentication sequence? Is it some >> prompt from the relay host or does the local server just know >> when and how to authenticate? Could something have changed on >> the relay host that would stop the local server from trying >> to authenticate? >> > I have made yet another discovery. Perhaps this is the > problem. When the EHLO command is send, should there not be the > line: > > 250-AUTH LOGIN DIGEST-MD5 CRAM-MD5 PLAIN > > Is that not what triggers the sasl authentication? That line > is missing. Is that perhaps the crux problem? If so is there a > way for forced postfix to authenticate anyway? Thanks. > > >
Postfix won't send authentication if the server doesn't offer it. And if you sent it anyway, it's quite unlikely the server would accept it. How are you testing this? Many servers are configured to only offer AUTH on encrypted TLS connections, and/or only on the "submission" port 587. Test with openssl: # openssl s_client -connect host.example.com:25 -starttls smtp or :587 to test the submission port. If this is the problem, postfix must be built with TLS support and have set: # main.cf smtp_tls_security_level = may To indicate in the log if a connection uses TLS, set #main.cf smtp_tls_loglevel = 1 -- Noel Jones -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6XO2AAoJEJGRUHb5Oh6ghZkH/0EaDG0pLVZPd93ACDbXdAfP 3KDfoe4DvOONfJqfI8i7EIVWrjUZ/kbXIql2nSyw8TRlXSvLNt33DDf9iVbDawpp CTgaVo1B5YPE1t9Gc4U1P68WBhrpSPLRmy+Wg4zV4MhW8ajF3eD7jmsWaNOJXTCf +Pw/YDtALtMxMrSNzjcR4UxeY7crumh97iAxrjOOpbm4RfltFENvpBsJaClU34VI gtit3XmvTe3GZuX+y5p6J0I29bH6Qfa5ZHUwsE3tDUQc9QDUhxj5jiGRcQtj0LzV AKDNfwm5BLY0yTiqInlsdxWDjawivLgW40ibSyjJMo4XOhk6UBXJlY8OAWFmA00= =XNZq -----END PGP SIGNATURE-----
