On 23 Jul 2016, at 17:31, techlist06 wrote:
-----
test tunneled TLS connections to port 465
openssl s_client -connect tn2.myserver.com:465
Appears to work
-----
From remote server
test STARTTLS connections on port 25 or 587 with:
openssl s_client -connect tn2.myserver.com:587 -starttls smtp
appears to work, shows a bunch of info and the certificate text.
Nothing
that looks like errors except a line that says:
verify error:num=18:self signed certificate
verify return:1
-----
You can confirm or refute on your "appears to work" conclusions 2 ways:
1. Look in your server logs for lines with content like this:
postfix/smtpd[123]: Anonymous TLS connection established from
host.example.com[192.0.2.1]: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
2. When using openssl s_client, you should be left connected in a SMTP
session so you can issue a EHLO command and should get a reasonable
reply. If not, there's something wrong.
------------------
MS Outlook is happy using port 587 (SASL only I think)
Your logs should tell you whether that session is doing TLS or not. It
is a misconfiguration to allow submission on port 587 without TLS. You
didn't include your settings for port 87 (the 'submission' service in
master.cf) but if STARTTLS via openssl s_client is working and Outlook
can submit mail, it is likely that Outlook used STARTTLS.
I can deliver a test
message. POP also works and it will retrive same.
POP and IMAP are irrelevant here, since they are not part of Postfix,
but it's good to know that you don't seem to have any issues with
Dovecot complicating things and obscuring your Postfix issues...
But with Outlook set to use port 465 it will not work. Times out.
Serious question: why do you care? Port 465 SSL-wrapped SMTP was never
made a standard and correctly never will be. No software that I'm aware
of can use that botch and cannot use STARTTLS except for a few clients
so outdated as to be inherently unsafe (e.g. antique versions of
Outlook.) Make sure Outlook is using STARTTLS on port 587 and be happy
with that: it's a service defined by a RFC which is supported by any
client software that isn't a danger to its users. Since port 465 service
owes its zombie existence to an early draft for SSLv3 that was never
made into any sort of standard, it is formally improper to offer ANY TLS
version over it, while all versions of SSL should be treated as broken
and obsolete. Do you see the problem?
Assuming you have a concrete need (e.g. The Boss uses Outlook Express on
Windows ME and won't upgrade,) if s_client is working to port 465 and
Outlook is not, you have an Outlook problem. Talk to your vendor about
that. Since you've not included your master.cf configuration for the
smtps (port 465) service, there's no hope of diagnosis here at present.
The maillog for the timed out test shows below. It gets to that last
line
and just hangs.
Jul 23 16:09:27 tn2 postfix/smtps/smtpd[10110]: connection established
[...]
Jul 23 16:09:27 tn2 postfix/smtps/smtpd[10110]:
SSL_accept:before/accept
initialization
1. Back off smtpd_tls_loglevel to 1. All of the above happened within a
second and provides no useful clues.
2. Without knowing the config of the smtps service (i.e. the relevant
lines from master.cf) it is impossible to do anything more than make
wild guesses. I'm going to make the wild guess that you didn't uncomment
all of the essential continuation lines after the first one for smtps:
the indented ones starting with '-o'.
Can someone see what I'm doing wrong? How to fix it? Hoping it's a
config
error.
Very likely, but we'd need the whole relevant config to know.
Side note on this:
Telnet to the server and STARTTLS seems happy:
220 tn2.myserver.com ESMTP Postfix
ehlo sample.com
250-tn2.myserver.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
You didn't say which port that was, so it isn't clear which service
config applies, but on a modern system there is rarely any good reason
to have an EHLO response in any circumstance that includes both AUTH and
STARTTLS. Modern best practice is to use STARTTLS and authenticate
inside the encrypted tunnel with plaintext mechanisms that do not
require the server to store passwords in recoverable forms. The above
response indicates that you are offering plaintext mechanisms over an
unencrypted connection, which is an invitation to cracked accounts and a
world of hurt. On most mail systems, port 25 should offer STARTTLS and
no AUTH even after TLS is established, with port 587 being the only
place you accept authenticated message submission and then only after
STARTTLS.
There's a chance that the above is in fact not dangerous because Dovecot
will refuse to allow authentication due to its disable_plaintext_auth
setting but I don't recall whether it can 'see' whether there's TLS or
not when servicing Postfix smtpd, and my guess would be not...
In any case, a safer config if for some reason you do want to allow
authentication over port 25 would use these settings:
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
One reason you might want this is if you're providing relay services for
a 3rd party and want to apply the restrictions applied to inbound mail
to their transiting mail rather than the different and maybe less strict
ones applied to initial submissions by your direct users.
