Viktor Dukhovni via Postfix-users:
From the HISTORY file (corrected date from original 20241031):
20251031
Bugfix (defect introduced: Postfix 3.10, date 20250117):
support for "TLS-Required: no" broke client-side TLS wrappermode
support, by downgrading a connection to TLS security level 'may'.
The solution is to change the downgrade level for wrappermode
connections to 'encrypt'. Rationale: by design, TLS can be
optional only for connections that use STARTTLS. The downgrade
to unauthenticated 'encrypt' allows a sender to avoid an email
delivery problem. Problem reported by Joshua Tyler Cochran.
Files: smtp/smtp_tls_policy.c, smtp/smtp_tls_policy_test.c.
Postfix sometimes downgrades the effective security to "may", e.g. with
"RequireTLS = no". This makes sense for handoffs to an SMTP relay (MX
host, ...), but perhaps not for a submission handoff, where TLS might be
required because otherwise also no SASL...
Fortunately, with port 465, there's no choice, and with the above bug
fixed the downgrade is now to "encrypt". But now I think that perhaps
we should not do TLS downgrades on ports other than 25...
If you have a Postfix 3.10 version without the fix, that would be the
explanation. Note that the fix from the dev snapshot release series
has not yet appeared in an official 3.10 release.
# postconf mail_version
mail_version = 3.10.5
That would then be the problem, assuming you have messages in your queue
with "TLS-Required: no".
Hello Viktor,
good catch! Every deferred message in the queue do have the header
"TLS-Required: no"
postconf -e 'tls_required_enable=no' && postfix reload && queue is empty :-)
To me, it looks like a race condition, that happen very rarly.
good no now, that there is *not* a random race condition in postfix
Andreas
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
