2

I'm running Postfix on Debian as an MX for a small LAN and trying to get SMTPS working with mobile.charter.net over port 587. I followed a few links off google for setting this up along with a post on serverfault with a similar question. I've tried sending a few emails but getting this error about "initial server greeting" in the mail log:

 Nov 17 03:39:14 edgemx postfix/smtp[30355]: 9B39AA4: to=<xxxxxxxx@charter.net>, relay=mobile.charter.net[47.43.18.12]:587, delay=473, delays=173/0.03/300/0, dsn=4.4.2, status=deferred (conversation with mobile.charter.net[47.43.18.12] timed out while receiving the initial server greeting)

I ran a tcpdump on port 587 while sending and I don't see the certificate transfer happening between Postfix and Charter. There's like three SYN packets and that's it. If I use openssl in client mode to connect, the tcpdump traffic is much different and I can see a cert transfer happen.

openssl s_client -connect mobile.charter.net:587

Anyone know what's up? What is openssl doing that Postfix isnt? relevant SASL/SSL edits in main.cf are below.

main.cf

smtp_sasl_auth_enable         = yes
smtp_sasl_password_maps       = hash:/etc/postfix/relayhost_passwd
smtp_sasl_security_options    = noanonymous
smtp_use_tls                  = yes
smtp_tls_security_level       = encrypt
relayhost                     = [mobile.charter.net]:587
smtp_tls_mandatory_ciphers    = high

relayhost_passwd file (postmap'd already)

[mobile.charter.net]:587      xxxxxxxx@charter.net:sUp3rS3kr1t
0

The remote mail server you are trying to reach is misconfigured.

On port 587 a mail server should answer in plain text and expect the originator to send the STARTTLS command to begin TLS negotiation.

This mail server is not doing this. Instead it is immediately going to TLS negotiation (implicit TLS). This is the expected behavior for port 465 (on which it is behaving exactly the same, which is correct for that port).

You can work around this broken behavior by setting smtp_tls_wrappermode:

smtp_tls_wrappermode = yes

Also consider changing the port from 587 to 465 (you'll still need to add the above setting), as when the mail server administrators fix their misconfiguration, your delivery would break again.

  • That did the trick. Thanks so much!. Configuring for port 465 left this notice in the logs SMTPS wrappermode (TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger). After adding smtp_tls_wrappermode=yes, I got sender non-delivery notification errors so switched back to port 587 and delivery is now working. – Nstevens Nov 17 '20 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.