Discussion:
smtp_sasl_auth_enable Being Ignored
(too old to reply)
Dennis Putnam
2014-01-29 02:15:02 UTC
Permalink
My authentication has recently stopped working (at least it appears to
me there is no attempt to authenticate). The problem appears to be that
the sasl parameters are being ignored. 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 =

However, when I run postconf, I get this:

smtp_sasl_auth_enable = no

Here is the maillog output with debug on:

Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 220 smtp.att.yahoo.com ESMTP ready
Jan 28 18:08:21 dap002 postfix/smtp[29878]: >
smtp.att.yahoo.com[98.138.31.74]:587: EHLO home.bellsouth.net
Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 250-smtp.att.yahoo.com
Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 250-PIPELINING
Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 250-SIZE 41697280
Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 250-8 BITMIME
Jan 28 18:08:21 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 250 STARTTLS
Jan 28 18:08:21 dap002 postfix/smtp[29878]: server features: 0x101d size
41697280
Jan 28 18:08:21 dap002 postfix/smtp[29878]: Using ESMTP PIPELINING, TCP
send buffer size is 4096
Jan 28 18:08:21 dap002 postfix/smtp[29878]: >
smtp.att.yahoo.com[98.138.31.74]:587: MAIL FROM:<>
Jan 28 18:08:21 dap002 postfix/smtp[29878]: maps_find:
smtp_generic_maps: ***@bellsouth.net: not found
Jan 28 18:08:21 dap002 postfix/smtp[29878]: match_string: bellsouth.net
~? dap002.dap.localnet
Jan 28 18:08:21 dap002 postfix/smtp[29878]: match_string: bellsouth.net
~? localhost.dap.localnet
Jan 28 18:08:21 dap002 postfix/smtp[29878]: match_string: bellsouth.net
~? localhost
Jan 28 18:08:21 dap002 postfix/smtp[29878]: match_list_match:
bellsouth.net: no match
Jan 28 18:08:21 dap002 postfix/smtp[29878]: maps_find:
smtp_generic_maps: @bellsouth.net: not found
Jan 28 18:08:21 dap002 postfix/smtp[29878]: mail_addr_find:
***@bellsouth.net -> (not found)
Jan 28 18:08:21 dap002 postfix/smtp[29878]: mail_addr_map:
***@bellsouth.net -> (not found)
Jan 28 18:08:21 dap002 postfix/smtp[29878]: smtp_map11_external:
***@bellsouth.net not found
Jan 28 18:08:21 dap002 postfix/smtp[29878]: >
smtp.att.yahoo.com[98.138.31.74]:587: RCPT TO:<***@bellsouth.net>
Jan 28 18:08:22 dap002 postfix/smtp[29878]: >
smtp.att.yahoo.com[98.138.31.74]:587: DATA
Jan 28 18:08:22 dap002 postfix/smtp[29878]: <
smtp.att.yahoo.com[98.138.31.74]:587: 530 5.7.1 Authentication required
Jan 28 18:08:22 dap002 postfix/smtp[29878]: connect to subsystem
private/bounce
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr nrequest = 0
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr flags = 0
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr queue_id = 9566E26457
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr original_recipient
= ***@dap002.dap.localnet
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr recipient =
***@bellsouth.net
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr offset = 175
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr dsn_orig_rcpt =
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr notify_flags = 0
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr status = 5.7.1
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr diag_type = smtp
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr diag_text = 530
5.7.1 Authentication required
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr mta_type = dns
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr mta_mname =
smtp.att.yahoo.com
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr action = failed
Jan 28 18:08:22 dap002 postfix/smtp[29878]: send attr reason = host
smtp.att.yahoo.com[98.138.31.74] said: 530 5.7.1 Authentication required
(in reply to MAIL FROM command)
Jan 28 18:08:22 dap002 postfix/smtp[29878]: private/bounce socket:
wanted attribute: status
Jan 28 18:08:22 dap002 postfix/smtp[29878]: input attribute name: status
Jan 28 18:08:22 dap002 postfix/smtp[29878]: input attribute value: 0
Jan 28 18:08:22 dap002 postfix/smtp[29878]: private/bounce socket:
wanted attribute: (list terminator)
Jan 28 18:08:22 dap002 postfix/smtp[29878]: input attribute name: (end)
Jan 28 18:08:22 dap002 postfix/smtp[29878]: 9566E26457:
to=<***@bellsouth.net>, orig_to=<***@dap002.dap.localnet>,
relay=smtp.att.yahoo.com[98.138.31.74]:587, delay=0.46,
delays=0.07/0/0.31/0.08, dsn=5.7.1, status=bounced (host
smtp.att.yahoo.com[98.138.31.74] said: 530 5.7.1 Authentication required
(in reply to MAIL FROM command))
Jan 28 18:09:21 dap002 postfix/smtp[29878]: smtp_get: EOF
Jan 28 18:09:21 dap002 postfix/smtp[29878]: 9566E26457: lost connection
with smtp.att.yahoo.com[98.138.31.74] while sending RCPT TO
Jan 28 18:09:21 dap002 postfix/smtp[29878]: name_mask: resource
Jan 28 18:09:21 dap002 postfix/smtp[29878]: name_mask: software
Jan 28 18:09:21 dap002 postfix/qmgr[29870]: 9566E26457: removed


Can anyone explain what has happened?

For reference I can send the entire postconf and main.cf if necessary
but including it with this email exceeds the max size. Thanks.
Viktor Dukhovni
2014-01-29 02:44:34 UTC
Permalink
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
--
Viktor.
Dennis Putnam
2014-01-29 13:49:25 UTC
Permalink
Post by Viktor Dukhovni
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Dennis Putnam
2014-01-29 14:35:21 UTC
Permalink
Post by Dennis Putnam
Post by Viktor Dukhovni
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
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?
Viktor Dukhovni
2014-01-29 15:31:04 UTC
Permalink
Post by Dennis Putnam
Post by Viktor Dukhovni
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.
That's rather useless in this context, the "-d" option reports
compiled-in default settings.
Post by Dennis Putnam
smtp_sasl_auth_enable = yes
Is that only output of "postconf -n | grep smtp_sasl_auth_enable"?
In that case authentication is enabled, but perhaps the other
settings you reported earlier are not. Another possibility is that
the upgrade replaced Berkeley DB, and you need to rebuild the sasl
password database.

Save everyone some time and post unedited output of:

postconf -n smtp_sasl_auth_enable
smtp_sasl_mechanism_filter smtp_sasl_password_maps \
smtp_sasl_security_options smtp_sasl_tls_security_options \
smtp_sasl_tls_verified_security_options smtp_sasl_type | cat -ev

Perhaps you're not configured to use SASL without TLS, and IIRC you
don't seem to have used TLS.
--
Viktor.
Dennis Putnam
2014-01-29 21:14:16 UTC
Permalink
Post by Dennis Putnam
Post by Dennis Putnam
Post by Viktor Dukhovni
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
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.
l***@rhsoft.net
2014-01-29 21:22:50 UTC
Permalink
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the problem. When the
to the destination server i assume
Post by Dennis Putnam
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.
please post the complete output i bet there is "250-STARTTLS" too and
you do have http://www.postfix.org/TLS_README.html#server_tls_auth
enabled which means there is no AUTH announcement before STARTLS
was finished
Noel Jones
2014-01-29 21:33:42 UTC
Permalink
Post by Dennis Putnam
Post by Dennis Putnam
Post by Dennis Putnam
On Tue, Jan 28, 2014 at 09:15:02PM -0500, Dennis Putnam
Post by Dennis Putnam
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.
Post by Dennis Putnam
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.
Post by Dennis Putnam
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
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
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
Viktor Dukhovni
2014-01-29 21:55:42 UTC
Permalink
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the problem. When the
250-AUTH LOGIN DIGEST-MD5 CRAM-MD5 PLAIN
To repeat what I posted previously:

Save everyone some time and post unedited output of:

postconf -n smtp_sasl_auth_enable
smtp_sasl_mechanism_filter smtp_sasl_password_maps \
smtp_sasl_security_options smtp_sasl_tls_security_options \
smtp_sasl_tls_verified_security_options smtp_sasl_type | cat -ev

Perhaps you're not configured to use SASL without TLS, and IIRC you
don't seem to have used TLS.

You should also post the complete output of "postconf -n". The
reason I asked for the above variant is that it less likely to
craete misleading output when you cut/paste the output and change
how lines are folded.
--
Viktor.
Dennis Putnam
2014-01-29 22:44:28 UTC
Permalink
Post by l***@rhsoft.net
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the problem. When the
to the destination server i assume
Post by Dennis Putnam
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.
please post the complete output i bet there is "250-STARTTLS" too and
you do have http://www.postfix.org/TLS_README.html#server_tls_auth
enabled which means there is no AUTH announcement before STARTLS
was finished
Thanks for the reply. You are correct but what does it mean and what do
I do?

220 smtp.att.yahoo.com ESMTP ready
EHLO home.bellsouth.net
250-smtp.att.yahoo.com
250-PIPELINING
250-SIZE 41697280
250-8 BITMIME
250 STARTTLS
l***@rhsoft.net
2014-01-29 22:57:26 UTC
Permalink
Post by Dennis Putnam
Post by l***@rhsoft.net
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the problem. When the
to the destination server i assume
Post by Dennis Putnam
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.
please post the complete output i bet there is "250-STARTTLS" too and
you do have http://www.postfix.org/TLS_README.html#server_tls_auth
enabled which means there is no AUTH announcement before STARTLS
was finished
Thanks for the reply. You are correct but what does it mean and what do
I do?
220 smtp.att.yahoo.com ESMTP ready
EHLO home.bellsouth.net
250-smtp.att.yahoo.com
250-PIPELINING
250-SIZE 41697280
250-8 BITMIME
250 STARTTLS
enable opportunistic TLS on your postfix smtp-client since you
don't control the destination and maybe you need also use port
587 in your transport because port 25 may or may not support
authentication

in mordern setups only port 587 (submission) should be used for
send authenticated mails and if someone can do that (we can't
because too many client configurations out of control) someone
could disable authentication on port 25 completly which blocks
any didctionary attack from the first start

http://www.postfix.org/TLS_README.html#client_tls

smtp_use_tls = yes
smtp_tls_loglevel = 1
smtp_tls_security_level = may
Dennis Putnam
2014-01-29 22:58:15 UTC
Permalink
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the problem. When the
250-AUTH LOGIN DIGEST-MD5 CRAM-MD5 PLAIN
postconf -n smtp_sasl_auth_enable \
smtp_sasl_mechanism_filter smtp_sasl_password_maps \
smtp_sasl_security_options smtp_sasl_tls_security_options \
smtp_sasl_tls_verified_security_options smtp_sasl_type | cat -ev
Perhaps you're not configured to use SASL without TLS, and IIRC you
don't seem to have used TLS.
You should also post the complete output of "postconf -n". The
reason I asked for the above variant is that it less likely to
craete misleading output when you cut/paste the output and change
how lines are folded.
Thanks for the reply. Keep in mind this is not a new installation. This
has been working until recently and still works for servers requiring
authentication other then smtp.att.yahoo.com. Clearly something must
have changed for that particular server.

I thought I posted postconf output earlier but here it is again:

$ postconf -n smtp_sasl_auth_enable ...
smtp_sasl_auth_enable = yes$
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd$
smtp_sasl_security_options = $

TLS is indeed set via

$ postconf -n smtp_tls_policy_maps
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

The entry in that file is set to:

smtp.att.yahoo.com may
l***@rhsoft.net
2014-01-29 23:07:54 UTC
Permalink
Post by Dennis Putnam
Thanks for the reply. Keep in mind this is not a new installation. This
has been working until recently and still works for servers requiring
authentication other then smtp.att.yahoo.com. Clearly something must
have changed for that particular server.
$ postconf -n smtp_sasl_auth_enable ...
smtp_sasl_auth_enable = yes$
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd$
smtp_sasl_security_options = $
TLS is indeed set via
$ postconf -n smtp_tls_policy_maps
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp.att.yahoo.com may
you may need transports with port 587 to that server and whereever you
"talk about that host" you need to do it the same way (transports,
smtp_sasl_password_maps...) like below

as said: nobody needs to accept smtp-auth on port 25 which is
the standard port if MTA's are talking with each other while
MUA's should use port 587 and these are typically clients
doing authentication

as also said: a good reason is to avoid dictionary attacks on port 25
at all, few to zero bots for now try to deal with 587 and so fail
__________________________________

the [] are to avoid MX looksups!

[smtp.att.yahoo.com]:587
Noel Jones
2014-01-29 23:08:08 UTC
Permalink
Post by Dennis Putnam
Post by l***@rhsoft.net
Post by Dennis Putnam
I have made yet another discovery. Perhaps this is the
problem. When the EHLO command is send, should there not be
to the destination server i assume
Post by Dennis Putnam
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.
please post the complete output i bet there is "250-STARTTLS"
too and you do have
http://www.postfix.org/TLS_README.html#server_tls_auth
enabled which means there is no AUTH announcement before
STARTLS was finished
Thanks for the reply. You are correct but what does it mean and
what do I do?
220 smtp.att.yahoo.com ESMTP ready EHLO home.bellsouth.net
250-smtp.att.yahoo.com 250-PIPELINING 250-SIZE 41697280 250-8
BITMIME 250 STARTTLS
Yahoo/ATT/Bellsouth requires TLS before they offer AUTH. Test
with openssl rather than telnet.

# openssl s_client -connect smtp.att.yahoo.com:25 -starttls smtp
(... ssl handshake output redacted ...)
ehlo host.example.com
250-smtp.att.yahoo.com
250-PIPELINING
250-SIZE 41697280
250-8 BITMIME
250 AUTH PLAIN LOGIN XYMCOOKIE
quit
221 2.0.0 Bye




Verify postfix is using TLS by setting in main.cf:
smtp_tls_loglevel = 1
which will log a "TLS connection established" line.


-- Noel Jones
Viktor Dukhovni
2014-01-29 23:22:56 UTC
Permalink
Post by Dennis Putnam
TLS is indeed set via
$ postconf -n smtp_tls_policy_maps
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp.att.yahoo.com may
Your original message reports problems with delivery to a bellsouth.net
recipient via:

relay=smtp.att.yahoo.com[98.138.31.74]:587

presumably, you've set "relayhost=[smtp.att.yahoo.com]:587" or some
similar setting. Per the Postfix documentation (both TLS_README
and SASL_README). The lookup key for both TLS and SASL policy
should be verbatim next-hop destination, namely:

tls_policy:
# Ideally use "secure" after configuring a suitable CAfile.
[smtp.att.yahoo.com]:587 encrypt

sasl_passwords:
[smtp.att.yahoo.com]:587 user:pass
--
Viktor.
Dennis Putnam
2014-01-30 00:14:34 UTC
Permalink
Post by Viktor Dukhovni
Post by Dennis Putnam
TLS is indeed set via
$ postconf -n smtp_tls_policy_maps
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp.att.yahoo.com may
Your original message reports problems with delivery to a bellsouth.net
relay=smtp.att.yahoo.com[98.138.31.74]:587
presumably, you've set "relayhost=[smtp.att.yahoo.com]:587" or some
similar setting. Per the Postfix documentation (both TLS_README
and SASL_README). The lookup key for both TLS and SASL policy
# Ideally use "secure" after configuring a suitable CAfile.
[smtp.att.yahoo.com]:587 encrypt
[smtp.att.yahoo.com]:587 user:pass
Thanks again for the reply but no joy. I have been using port 587 for a
couple of years until this recent problem. The only difference is I had
my tls_policy set like this:

[smtp.att.yahoo.com] may

That has been working all that time. I changed it per your suggestion to:

[smtp.att.yahoo.com]:587 encrypt


It did not help.

I ran Noel's suggestion with openssl and got the same thing he got.

# openssl s_client -connect smtp.att.yahoo.com:587 -starttls smtp
(certificate stuff)
250 STARTTLS
ehlo home.bellsouth.net
250-smtp.att.yahoo.com
250-PIPELINING
250-SIZE 41697280
250-8 BITMIME
250 AUTH PLAIN LOGIN XYMCOOKIE
quit
221 2.0.0 Bye


Repeating the debug output:

Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 220 smtp.att.yahoo.com ESMTP ready
Jan 29 19:03:29 dap002 postfix/smtp[6808]: > smtp.att.yahoo.com[98.138.31.74]:587: EHLO home.bellsouth.net
Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 250-smtp.att.yahoo.com
Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 250-PIPELINING
Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 250-SIZE 41697280
Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 250-8 BITMIME
Jan 29 19:03:29 dap002 postfix/smtp[6808]: < smtp.att.yahoo.com[98.138.31.74]:587: 250 STARTTLS
Jan 29 19:03:29 dap002 postfix/smtp[6808]: server features: 0x101d size 41697280

Why is this different than the openssl output? Does this imply that smtp is not immediately starting TLS?
Viktor Dukhovni
2014-01-30 00:41:58 UTC
Permalink
Post by Dennis Putnam
Thanks again for the reply but no joy. I have been using port 587 for a
couple of years until this recent problem. The only difference is I had
Not "no joy", rather failure to execute correctly. Whatever your
relayhost setting or transport endpoint is configured to be, that's
what goes into the tls policy table, which has to be rebuilt with
postmap, ... Clearly you need to be modifying the configuration
of the right Postfix instance, and not have any conflicting overrides
in master.cf, ...

The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
--
Viktor.
Dennis Putnam
2014-01-30 01:20:44 UTC
Permalink
Post by Viktor Dukhovni
Post by Dennis Putnam
Thanks again for the reply but no joy. I have been using port 587 for a
couple of years until this recent problem. The only difference is I had
Not "no joy", rather failure to execute correctly. Whatever your
relayhost setting or transport endpoint is configured to be, that's
what goes into the tls policy table, which has to be rebuilt with
postmap, ... Clearly you need to be modifying the configuration
of the right Postfix instance, and not have any conflicting overrides
in master.cf, ...
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
Viktor Dukhovni
2014-01-30 02:17:17 UTC
Permalink
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.

You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
--
Viktor.
Wietse Venema
2014-01-30 02:42:00 UTC
Permalink
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
All TLS (and SASL) parameters are defined whether or not the feature
is compiled in. However, the SMTP client and server will log warning
when the feature is turned on.
Post by Viktor Dukhovni
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
This is correct.

Wietse
Viktor Dukhovni
2014-01-30 03:32:08 UTC
Permalink
Post by Wietse Venema
Post by Viktor Dukhovni
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
All TLS (and SASL) parameters are defined whether or not the feature
is compiled in. However, the SMTP client and server will log warning
when the feature is turned on.
Yes, I neglected to check whether parameters that are conditionally
compiled into smtp(8) and friends are also conditionally compiled
into postconf(1). It seems that nowdays, postconf picks up all
parameters even for features disabled at compile time. Was it
always this way? I have dim memories of seeing fewer parameters
from "postconf -d" in some long ago release when compiling without
TLS support.
Post by Wietse Venema
Post by Viktor Dukhovni
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
This is correct.
Or also "strings /usr/libexec/postfix/smtp | grep smtp_tls_loglevel",
the delivery agent definitely includes this only when TLS is enabled.

You should also have warnings in the logs:

TLS has been selected, but TLS support is not compiled in

when TLS is enabled in main.cf (even when site-dependent), but smtp(8)
is not compiled with TLS support. That warning dates back to
postfix-2.2-20050119.
--
Viktor.
Benny Pedersen
2014-01-30 06:33:45 UTC
Permalink
Post by Dennis Putnam
250-8 BITMIME
should it not be 8BITMIME ?
l***@rhsoft.net
2014-01-30 08:19:03 UTC
Permalink
Post by Dennis Putnam
250-8 BITMIME
should it not be 8BITMIME?
ask yahoo, it's their server
Wietse Venema
2014-01-30 12:51:11 UTC
Permalink
Post by Viktor Dukhovni
Post by Wietse Venema
Post by Viktor Dukhovni
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
All TLS (and SASL) parameters are defined whether or not the feature
is compiled in. However, the SMTP client and server will log warning
when the feature is turned on.
Yes, I neglected to check whether parameters that are conditionally
compiled into smtp(8) and friends are also conditionally compiled
into postconf(1). It seems that nowdays, postconf picks up all
parameters even for features disabled at compile time. Was it
always this way? I have dim memories of seeing fewer parameters
from "postconf -d" in some long ago release when compiling without
TLS support.
Yes, this has always worked this way. Just like the postconf(5)
manpage shows all parameters even when the corresponding features
are not built into Postfix.
Post by Viktor Dukhovni
TLS has been selected, but TLS support is not compiled in
when TLS is enabled in main.cf (even when site-dependent), but smtp(8)
is not compiled with TLS support. That warning dates back to
postfix-2.2-20050119.
That's around the time that TLS was merged into Postfix.

Wietse
LuKreme
2014-01-30 12:53:19 UTC
Permalink
Post by l***@rhsoft.net
in mordern setups only port 587 (submission) should be used for
send authenticated mails and if someone can do that (we can't
because too many client configurations out of control) someone
could disable authentication on port 25 completly which blocks
any didctionary attack from the first start
This is exactly what I do on my mailserver. All submissions have to come in over port 587 and there is no authentication at port 25.

The few people who “can’t” (or more likely won’t) use submission have to use the webmail, which also uses port 587 to send mail.

On the up side, I get a lot less attacks, on the down side my fail2ban fills up a lot more slowly with IPs to block.
--
"A musicologist is a man who can read music but can't hear it." - Sir
Thomas Beecham (1879 - 1961)
Dennis Putnam
2014-01-30 13:30:21 UTC
Permalink
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
Rats! That is not it.

$ postconf smtp_tls_loglevel
smtp_tls_loglevel = 0
Dennis Putnam
2014-01-30 13:32:04 UTC
Permalink
Post by Wietse Venema
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
All TLS (and SASL) parameters are defined whether or not the feature
is compiled in. However, the SMTP client and server will log warning
when the feature is turned on.
Post by Viktor Dukhovni
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
This is correct.
Wietse
libssl3 and libcrypto are both present.
Dennis Putnam
2014-01-30 13:34:17 UTC
Permalink
Post by Viktor Dukhovni
Post by Wietse Venema
Post by Viktor Dukhovni
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
All TLS (and SASL) parameters are defined whether or not the feature
is compiled in. However, the SMTP client and server will log warning
when the feature is turned on.
Yes, I neglected to check whether parameters that are conditionally
compiled into smtp(8) and friends are also conditionally compiled
into postconf(1). It seems that nowdays, postconf picks up all
parameters even for features disabled at compile time. Was it
always this way? I have dim memories of seeing fewer parameters
from "postconf -d" in some long ago release when compiling without
TLS support.
Post by Wietse Venema
Post by Viktor Dukhovni
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
This is correct.
Or also "strings /usr/libexec/postfix/smtp | grep smtp_tls_loglevel",
the delivery agent definitely includes this only when TLS is enabled.
TLS has been selected, but TLS support is not compiled in
when TLS is enabled in main.cf (even when site-dependent), but smtp(8)
is not compiled with TLS support. That warning dates back to
postfix-2.2-20050119.
No warning in log. SSL must be linked in. It just occurred to me that
the working server is using TLS also so that cannot be the issue. It has
to be something specific with the smtp.att.yahoo.com server that has
changed.
l***@rhsoft.net
2014-01-30 13:49:19 UTC
Permalink
Post by Dennis Putnam
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
Rats! That is not it.
$ postconf smtp_tls_loglevel
smtp_tls_loglevel = 0
disables any SSL related logging
so fix that and watch the logs
Dennis Putnam
2014-01-30 14:00:18 UTC
Permalink
Post by l***@rhsoft.net
Post by Dennis Putnam
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
Rats! That is not it.
$ postconf smtp_tls_loglevel
smtp_tls_loglevel = 0
disables any SSL related logging
so fix that and watch the logs
I changed the loglevel to 1. I am not sure where or what I am supposed
to see but the normal maillog contained nothing different.
l***@rhsoft.net
2014-01-30 14:10:12 UTC
Permalink
Post by Dennis Putnam
Post by l***@rhsoft.net
Post by Dennis Putnam
Post by Viktor Dukhovni
Post by Dennis Putnam
Post by Viktor Dukhovni
The only other thing that comes to mind is that your "upgrade" may
have installed a version of Postfix with no TLS support. Then none
of these settings matter.
Hmmm. I hadn't thought of that. How do I check?
If postconf(1) is the same version of Postfix as smtp(8), then you
check with "postconf smtp_tls_loglevel". This parameter is not
defined when TLS support is not available.
You can also run "ldd /usr/libexec/postfix/smtp" (adjust to where-ever
your daemon_directory is) to see whether the smtp(8) delivery
agent is linked with libssl and libcrypto.
Rats! That is not it.
$ postconf smtp_tls_loglevel
smtp_tls_loglevel = 0
disables any SSL related logging
so fix that and watch the logs
I changed the loglevel to 1. I am not sure where or what I am supposed
to see but the normal maillog contained nothing different.
lines like while connect to the destination

Jan 27 19:16:17 mail postfix/smtp[14368]: Trusted TLS connection established to
gmail-smtp-in.l.google.com[173.194.70.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Dennis Putnam
2014-01-30 14:18:13 UTC
Permalink
Post by l***@rhsoft.net
Post by Dennis Putnam
I changed the loglevel to 1. I am not sure where or what I am supposed
to see but the normal maillog contained nothing different.
lines like while connect to the destination
Jan 27 19:16:17 mail postfix/smtp[14368]: Trusted TLS connection established to
gmail-smtp-in.l.google.com[173.194.70.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
I changed the level to 2. I am not seeing what you suggest but there is
one additional line initializing TLS engine. Here is the output:

Jan 30 09:09:37 dap002 postfix/smtp[10649]: initializing the client-side
TLS engine
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 220 smtp.att.yahoo.com ESMTP ready
Jan 30 09:09:37 dap002 postfix/smtp[10649]: >
smtp.att.yahoo.com[98.139.221.42]:587: EHLO home.bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 250-smtp.att.yahoo.com
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 250-PIPELINING
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 250-SIZE 41697280
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 250-8 BITMIME
Jan 30 09:09:37 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 250 STARTTLS
Jan 30 09:09:37 dap002 postfix/smtp[10649]: server features: 0x101d size
41697280
Jan 30 09:09:37 dap002 postfix/smtp[10649]: Using ESMTP PIPELINING, TCP
send buffer size is 4096
Jan 30 09:09:37 dap002 postfix/smtp[10649]: maps_find:
smtp_generic_maps: ***@dap002.dap.localnet: not found
Jan 30 09:09:37 dap002 postfix/smtp[10649]: maps_find:
smtp_generic_maps: hash:/etc/postfix/generic(0,lock|fold_fix): root =
***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: mail_addr_find:
***@dap002.dap.localnet -> ***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: connect to subsystem
private/rewrite
Jan 30 09:09:37 dap002 postfix/smtp[10649]: send attr request = rewrite
Jan 30 09:09:37 dap002 postfix/smtp[10649]: send attr rule = local
Jan 30 09:09:37 dap002 postfix/smtp[10649]: send attr address =
***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: private/rewrite socket:
wanted attribute: flags
Jan 30 09:09:37 dap002 postfix/smtp[10649]: input attribute name: flags
Jan 30 09:09:37 dap002 postfix/smtp[10649]: input attribute value: 0
Jan 30 09:09:37 dap002 postfix/smtp[10649]: private/rewrite socket:
wanted attribute: address
Jan 30 09:09:37 dap002 postfix/smtp[10649]: input attribute name: address
Jan 30 09:09:37 dap002 postfix/smtp[10649]: input attribute value:
***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: private/rewrite socket:
wanted attribute: (list terminator)
Jan 30 09:09:37 dap002 postfix/smtp[10649]: input attribute name: (end)
Jan 30 09:09:37 dap002 postfix/smtp[10649]: rewrite_clnt: local:
***@bellsouth.net -> ***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: mail_addr_map:
***@dap002.dap.localnet -> 0: ***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: smtp_map11_external:
***@dap002.dap.localnet -> ***@bellsouth.net
Jan 30 09:09:37 dap002 postfix/smtp[10649]: >
smtp.att.yahoo.com[98.139.221.42]:587: MAIL FROM:<***@bellsouth.net>
Jan 30 09:09:37 dap002 postfix/smtp[10649]: maps_find:
smtp_generic_maps: ***@bellsouth.net: not found
Jan 30 09:09:37 dap002 postfix/smtp[10649]: match_string: bellsouth.net
~? dap002.dap.localnet
Jan 30 09:09:37 dap002 postfix/smtp[10649]: match_string: bellsouth.net
~? localhost.dap.localnet
Jan 30 09:09:37 dap002 postfix/smtp[10649]: match_string: bellsouth.net
~? localhost
Jan 30 09:09:37 dap002 postfix/smtp[10649]: match_list_match:
bellsouth.net: no match
Jan 30 09:09:37 dap002 postfix/smtp[10649]: maps_find:
smtp_generic_maps: @bellsouth.net: not found
Jan 30 09:09:37 dap002 postfix/smtp[10649]: mail_addr_find:
***@bellsouth.net -> (not found)
Jan 30 09:09:37 dap002 postfix/smtp[10649]: mail_addr_map:
***@bellsouth.net -> (not found)
Jan 30 09:09:37 dap002 postfix/smtp[10649]: smtp_map11_external:
***@bellsouth.net not found
Jan 30 09:09:37 dap002 postfix/smtp[10649]: >
smtp.att.yahoo.com[98.139.221.42]:587: RCPT TO:<***@bellsouth.net>
Jan 30 09:09:37 dap002 postfix/smtp[10649]: >
smtp.att.yahoo.com[98.139.221.42]:587: DATA
Jan 30 09:09:38 dap002 postfix/smtp[10649]: <
smtp.att.yahoo.com[98.139.221.42]:587: 530 5.7.1 Authentication required
Jan 30 09:09:38 dap002 postfix/smtp[10649]: connect to subsystem
private/bounce
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr nrequest = 0
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr flags = 0
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr queue_id = 5D9FF1FD62
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr original_recipient
= ***@bellsouth.net
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr recipient =
***@bellsouth.net
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr offset = 199
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr dsn_orig_rcpt =
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr notify_flags = 0
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr status = 5.7.1
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr diag_type = smtp
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr diag_text = 530
5.7.1 Authentication required
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr mta_type = dns
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr mta_mname =
smtp.att.yahoo.com
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr action = failed
Jan 30 09:09:38 dap002 postfix/smtp[10649]: send attr reason = host
smtp.att.yahoo.com[98.139.221.42] said: 530 5.7.1 Authentication
required (in reply to MAIL FROM command)
Jan 30 09:09:38 dap002 postfix/smtp[10649]: private/bounce socket:
wanted attribute: status
Jan 30 09:09:38 dap002 postfix/smtp[10649]: input attribute name: status
Jan 30 09:09:38 dap002 postfix/smtp[10649]: input attribute value: 0
Jan 30 09:09:38 dap002 postfix/smtp[10649]: private/bounce socket:
wanted attribute: (list terminator)
Jan 30 09:09:38 dap002 postfix/smtp[10649]: input attribute name: (end)
Jan 30 09:09:38 dap002 postfix/smtp[10649]: 5D9FF1FD62:
to=<***@bellsouth.net>, relay=smtp.att.yahoo.com[98.139.221.42]:587,
delay=0.82, delays=0.26/0.2/0.29/0.08, dsn=5.7.1, status=bounced (host
smtp.att.yahoo.com[98.139.221.42] said: 530 5.7.1 Authentication
required (in reply to MAIL FROM command))

To repeat my previous question, is there no way to force a login
regardless of the EHLO responses?
Noel Jones
2014-01-30 14:34:35 UTC
Permalink
Post by Dennis Putnam
Post by l***@rhsoft.net
Post by Dennis Putnam
I changed the loglevel to 1. I am not sure where or what I
am supposed to see but the normal maillog contained nothing
different.
lines like while connect to the destination
Jan 27 19:16:17 mail postfix/smtp[14368]: Trusted TLS
connection established to
gmail-smtp-in.l.google.com[173.194.70.27]:25: TLSv1.2 with
cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
I changed the level to 2. I am not seeing what you suggest but
there is one additional line initializing TLS engine. Here is
... useless debug output deleted
Post by Dennis Putnam
To repeat my previous question, is there no way to force a
login regardless of the EHLO responses?
No, there is no way to force a login if the server doesn't offer
AUTH. Even if you did force it, it's highly unlikely the server
would accept it, and it wouldn't be safe since you're not
encrypting your connection -- no encryption is the root of the
problem.

Your TLS is screwed up. Show "postconf -n" output.



-- Noel Jones
Wietse Venema
2014-01-30 14:51:25 UTC
Permalink
smtp.att.yahoo.com[98.139.221.42]:587: 220 smtp.att.yahoo.com ESMTP ready
smtp.att.yahoo.com[98.139.221.42]:587: EHLO home.bellsouth.net
smtp.att.yahoo.com[98.139.221.42]:587: 250-smtp.att.yahoo.com
smtp.att.yahoo.com[98.139.221.42]:587: 250-PIPELINING
smtp.att.yahoo.com[98.139.221.42]:587: 250-SIZE 41697280
smtp.att.yahoo.com[98.139.221.42]:587: 250-8 BITMIME
smtp.att.yahoo.com[98.139.221.42]:587: 250 STARTTLS
smtp.att.yahoo.com[98.139.221.42]:587: MAIL FROM:<***@bellsouth.net>

Your SMTP client sends mail without turning on TLS. Therefore the
remote SMTP server does not announce AUTH, and the Your SMTP client
must not send AUTH.

Wietse
Dennis Putnam
2014-01-30 14:51:30 UTC
Permalink
Post by Noel Jones
Post by Dennis Putnam
I changed the level to 2. I am not seeing what you suggest but
there is one additional line initializing TLS engine. Here is
... useless debug output deleted
Post by Dennis Putnam
To repeat my previous question, is there no way to force a
login regardless of the EHLO responses?
No, there is no way to force a login if the server doesn't offer
AUTH. Even if you did force it, it's highly unlikely the server
would accept it, and it wouldn't be safe since you're not
encrypting your connection -- no encryption is the root of the
problem.
Your TLS is screwed up. Show "postconf -n" output.
-- Noel Jones
Thanks for your patience but why wouldn't the working server also be
failing if TLS was indeed screwed up?

Here is the postconf -n output:

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debug_peer_list = smtp.att.yahoo.com
html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 51200000
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks_style = host
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relayhost = [smtp.att.yahoo.com]:587
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
manpage_directory = /usr/share/man
message_size_limit = 51200000
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks_style = host
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relayhost = [smtp.att.yahoo.com]:587
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_generic_maps = hash:/etc/postfix/generic
smtp_helo_name = home.bellsouth.net
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_sender_dependent_authentication = yes
smtp_tls_loglevel = 2
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (CentOS Linux)
syslog_name = postfix
unknown_local_recipient_reject_code = 550

In case it is needed here is the content of tls_policy:

in.mailjet.com may
smtp.att.yahoo.com:587 encrypt


MailJet is the server that is working (Note: until this thread the entry
for yahoo was the same).
l***@rhsoft.net
2014-01-30 14:59:45 UTC
Permalink
Thanks for your patience but why wouldn't the working server also be failing if TLS was indeed screwed up?
because he does not force TLS
snipped
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
MailJet is the server that is working (Note: until this thread the entry for yahoo was the same)
[***@rh:/downloads]$ cat copy-paste.txt | grep tls
smtp_tls_loglevel = 2
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
_____________________________________

that above is a grep on your "postconf -n"
where is "smtp_use_tls = yes"

and that is why you should always start with output of "postconf -n"
instead waste that much time for all involved people
_____________________________________

[***@rh:~]$ postconf -n | grep smtp_tls
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
l***@rhsoft.net
2014-01-30 15:04:02 UTC
Permalink
Post by l***@rhsoft.net
Thanks for your patience but why wouldn't the working server also be failing if TLS was indeed screwed up?
because he does not force TLS
snipped
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
MailJet is the server that is working (Note: until this thread the entry for yahoo was the same)
smtp_tls_loglevel = 2
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
_____________________________________
that above is a grep on your "postconf -n"
where is "smtp_use_tls = yes"
and that is why you should always start with output of "postconf -n"
instead waste that much time for all involved people
_____________________________________
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
relayhost = [smtp.att.yahoo.com]:587
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
besides the above you where told to use [smtp.att.yahoo.com]:587
everywhere, so even if TLS would be enabled the config is
not really consistent
Noel Jones
2014-01-30 15:05:00 UTC
Permalink
Post by Dennis Putnam
Post by Noel Jones
Post by Dennis Putnam
I changed the level to 2. I am not seeing what you suggest
but there is one additional line initializing TLS engine.
... useless debug output deleted
Post by Dennis Putnam
To repeat my previous question, is there no way to force a
login regardless of the EHLO responses?
No, there is no way to force a login if the server doesn't
offer AUTH. Even if you did force it, it's highly unlikely
the server would accept it, and it wouldn't be safe since
you're not encrypting your connection -- no encryption is the
root of the problem.
Your TLS is screwed up. Show "postconf -n" output.
-- Noel Jones
Thanks for your patience but why wouldn't the working server
also be failing if TLS was indeed screwed up?
alias_database = hash:/etc/postfix/aliases alias_maps =
hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
command_directory = /usr/sbin config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix data_directory =
/var/lib/postfix debug_peer_level = 2 debug_peer_list =
smtp.att.yahoo.com
Turn off debug logging. It's not needed to solve this problem and
just pollutes the logs.
Post by Dennis Putnam
html_directory = no inet_interfaces = all inet_protocols = all
mail_owner = postfix mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man message_size_limit =
51200000 mydestination = $myhostname, localhost.$mydomain,
localhost mynetworks_style = host newaliases_path =
/usr/bin/newaliases.postfix queue_directory =
/var/spool/postfix readme_directory =
/usr/share/doc/postfix-2.6.6/README_FILES relayhost =
[smtp.att.yahoo.com]:587
Ok.
Post by Dennis Putnam
sample_directory = /etc/postfix sender_dependent_relayhost_maps
= hash:/etc/postfix/sender_relay manpage_directory =
/usr/share/man message_size_limit = 51200000 mydestination =
$myhostname, localhost.$mydomain, localhost mynetworks_style =
host newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix readme_directory =
/usr/share/doc/postfix-2.6.6/README_FILES relayhost =
[smtp.att.yahoo.com]:587
Eh? why are some entries listed twice? Cut & Paste error or trash
in main.cf?
Post by Dennis Putnam
sample_directory = /etc/postfix sender_dependent_relayhost_maps
= hash:/etc/postfix/sender_relay sendmail_path =
/usr/sbin/sendmail.postfix setgid_group = postdrop
smtp_generic_maps = hash:/etc/postfix/generic smtp_helo_name =
home.bellsouth.net smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_sender_dependent_authentication = yes smtp_tls_loglevel =
2 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
So you're using the default smtp_tls_security_level = none.
Post by Dennis Putnam
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
(CentOS Linux) syslog_name = postfix
unknown_local_recipient_reject_code = 550
in.mailjet.com may smtp.att.yahoo.com:587 encrypt
and this entry doesn't exactly match your relayhost setting.


First, set main.cf
smtp_tls_security_level = may

and then fix your tls_policy entries.



-- Noel Jones
Post by Dennis Putnam
MailJet is the server that is working (Note: until this thread
the entry for yahoo was the same).
Noel Jones
2014-01-30 15:07:34 UTC
Permalink
Post by l***@rhsoft.net
Thanks for your patience but why wouldn't the working server also be failing if TLS was indeed screwed up?
because he does not force TLS
snipped
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
MailJet is the server that is working (Note: until this thread the entry for yahoo was the same)
smtp_tls_loglevel = 2
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
_____________________________________
that above is a grep on your "postconf -n"
where is "smtp_use_tls = yes"
That is the old deprecated setting. Please use the current
smtp_tls_security_level = may


-- Noel Jones
Post by l***@rhsoft.net
and that is why you should always start with output of "postconf -n"
instead waste that much time for all involved people
_____________________________________
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
Dennis Putnam
2014-01-30 15:09:02 UTC
Permalink
Post by l***@rhsoft.net
Thanks for your patience but why wouldn't the working server also be failing if TLS was indeed screwed up?
because he does not force TLS
snipped
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
MailJet is the server that is working (Note: until this thread the entry for yahoo was the same)
smtp_tls_loglevel = 2
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
_____________________________________
that above is a grep on your "postconf -n"
where is "smtp_use_tls = yes"
and that is why you should always start with output of "postconf -n"
instead waste that much time for all involved people
_____________________________________
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_polic
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
Sorry but I thought I did post that early on but I had trouble with max
size on my initial posting so perhaps that was inadvertently left off as
I tried to shrink the size.

In any case that was it but the real puzzle is how did it get removed
and that is on me. Thanks.
Viktor Dukhovni
2014-01-30 15:13:34 UTC
Permalink
Post by Dennis Putnam
relayhost = [smtp.att.yahoo.com]:587
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
in.mailjet.com may
smtp.att.yahoo.com:587 encrypt
It is rather sad that the problem is staring you in the face, and
the required configuration was explicitly communicated upthread:o

http://archives.neohapsis.com/archives/postfix/2013-12/0785.html

Your original message reports problems with delivery to a bellsouth.net
recipient via:

relay=smtp.att.yahoo.com[98.138.31.74]:587

presumably, you've set "relayhost=[smtp.att.yahoo.com]:587" or some
similar setting. Per the Postfix documentation (both TLS_README
and SASL_README). The lookup key for both TLS and SASL policy
should be verbatim next-hop destination, namely:

tls_policy:
# Ideally use "secure" after configuring a suitable CAfile.
[smtp.att.yahoo.com]:587 encrypt

sasl_passwords:
[smtp.att.yahoo.com]:587 user:pass

The "[", "]" around the relay name in the tls policy and sasl password
tables are NOT optional.
--
Viktor.
Loading...