fwiw this is what gpt-5 said:
Short version: don’t assume your 587/submission is “good.” Require
STARTTLS there and enable SASL *only after* TLS. Keep 465/smtps around
for clients (like some appliances) that only do implicit-TLS. The “hex
garbage” in logs is just Postfix showing a TLS/SSH/RDP handshake that
hit the wrong listener.
What “correct” looks like
|master.cf| (minimal, safe overrides)
|# 587 Submission (STARTTLS -> then AUTH) submission inet n - n - -
smtpd -o syslog_name=postfix/submission -o smtpd_sasl_auth_enable=yes -o
smtpd_tls_security_level=encrypt -o smtpd_tls_auth_only=yes -o
smtpd_relay_restrictions=permit_sasl_authenticated,reject -o
smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_pipelining
# 465 SMTPS (implicit TLS) smtps inet n - n - - smtpd -o
syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o
smtpd_sasl_auth_enable=yes -o
smtpd_relay_restrictions=permit_sasl_authenticated,reject -o
smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_pipelining
|
|main.cf| (relevant bits)
|# TLS smtpd_tls_cert_file=/etc/ssl/your.crt
smtpd_tls_key_file=/etc/ssl/your.key smtpd_tls_eecdh_grade=strong
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3 # SASL (with Dovecot example)
smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth
smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous
smtpd_sasl_authenticated_header = yes # Don’t advertise AUTH on port 25
by default smtpd_sasl_auth_enable = no |
*Why this matters:* On 587, clients must see *STARTTLS* first; only
/after/ TLS is up should they see |AUTH|. If your 587 advertises |AUTH|
before STARTTLS (or allows AUTH in clear), some clients will say “SASL
unavailable” or refuse to proceed.
Quick triage / tests
*
Check 587 offers STARTTLS and /not/ AUTH in clear:
|openssl s_client -starttls smtp -crlf -connect mail.example:587
</dev/null | sed -n '/^250-/,/^[45]../p' |
You should see |250-STARTTLS| but no |250-AUTH| yet. After STARTTLS
completes and you send a new |EHLO|, you should then see |250-AUTH PLAIN
LOGIN …|.
*
Check 465 implicit TLS:
|openssl s_client -crlf -connect mail.example:465 </dev/null | sed -n
'/^250-/,/^[45]../p' |
Here you should immediately be inside TLS and see |250-AUTH …|.
*
End-to-end auth test (handy):
|swaks --to you@example --from test@example \ --server mail.example
--port 587 --tls --auth \ --auth-user USER --auth-password PASS swaks
--to you@example --from test@example \ --server mail.example --port 465
--tls --auth \ --auth-user USER --auth-password PASS |
About those “decimal/hex lines” in logs
Postfix escapes non-printable input when a client speaks the wrong
protocol to a socket. A TLS ClientHello sent to 587 *without* issuing
STARTTLS first (or a client that hit 25/587 with implicit-TLS
expectations) shows up as “noise”/escaped bytes. You’ll also
occasionally see stray SSH or RDP handshakes that port-scanners spray at
everything—normal, ignorable.
Ceph angle
Some Ceph components / third-party “notifier”/appliance clients only
support *implicit TLS on 465*. Many modern MUAs use 587+STARTTLS. So:
enable *both* with essentially identical policy; the only functional
difference is |smtpd_tls_wrappermode=yes| on 465.
If you want, paste a couple of your |postconf -n| lines for
submission/smtps and I’ll sanity-check them.
On 26/09/2025 2:51 am, Wietse Venema via Postfix-users wrote:
Viktor Dukhovni via Postfix-users:
On Thu, Sep 25, 2025 at 05:37:18PM +0200, lejeczek via Postfix-users wrote:
Inasmuch I do not, well, did not until now, use 465 but I've been using -
not with Ceph though - 587 all the time.
Is it ok to assume that, that part - 587 - of the config is good and it's
only Ceph which is incapable to of working with that?
I would not assume anything abouit your port 587 service, but that
service should support SASL login only after the client sends
STARTTLS. Otherwse, the client may complain that SASL is unavailable.
At this point in time you would typically expect a mixture of SMTP
submission client behaviours, with some using "implicit TLS" on port 465
and others usine "STARTTLS" on port 587. Expect to support both for
some time to come, with essentially identical settings, other than
wrapper mode = yes/no.
Lastly - that decimal/hex lines or whichever non-human notations, in my logs
- that has got be this way & it's only for source-code-speakers or can be
tweaked so "regular" humans could make use of it?
Postfix logs unexpected input, converting non-printable data to escaped
numeric form. When a client sends a TLS packet instead of ASCII SMTP
commands, the result will look like noise to neophytes, but others will
recognise the payload as misdirected TLS traffic (or a misconfigured
service that should be, but isn't, expecting TLS).
Indeed, Postfix has no built-in translator for unexpected protocols.
An unexpected TLS HELLO is not the only connection error: I regularly
see what looks like fragments of SSH negotiation, and RDP handshake
attempts, though they are less common.
Wietse
_______________________________________________
Postfix-users mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
