On Wed, Sep 10, 2025 at 05:31:54PM +0200, A. Schulze via Postfix-users wrote:
> We've an SMTP-Server, running intentionally with "smtpd_tls_security_level =
> encrypt"
>
> If an SMTP-Client fail to establish an TLS connection, the client fallback
> to plaintext.
That, despite apparently some clients caught off guard. This choice
feels too aggressive to me. But, if you're willing to go out on a limb,
perhaps you're also willing to deploy a Postfix development snapshot,
in which case you'll find in Postfix 3.11-<recent-enough-date>:
smtpd_reject_filter_maps (default: empty)
An optional filter that can replace a reject response from the
Postfix SMTP server itself, or from a program that replies
through the Postfix SMTP server. The filter is applied before the
optional reject footers are appended. Typically, the filter
will be a regexp: or pcre: table, where the left-hand side
specifies a pattern, and the right-hand side specifies
replacement text.
The input is a server response that starts with a 4XX or 5XX
reply code (see RFC 5321), usually followed by an enhanced
status code (see RFC 3463) and text. The filter returns
replacement text or indicates that there was no match. This
feature cannot be used to change a reject reply into a non-reject
one or vice versa.
LIMITATION: smtpd_reject_filter_maps will not replace text that
was already logged before the Postfix SMTP server replies to the
remote SMTP client. To help with logfile analysis, the Postfix
SMTP server logs both the unmodi‐ fied reply (logged below as
"reject filter in") and the replacement reply (logged below as
"reject filter out").
...
My choice would be to not insisnt on TLS with unsuspecting clients that
are unable to comply.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
