On 22/12/2025 05:30, Wietse Venema via Postfix-users wrote:
[redacted]
I don't think that one default TLS security level can meaningfully
cover both UNIX-domain and TCP conenctions. Maybe we need two (one
parameter for each connection type, or one list-valued parameter
that is indexed by connection type).
We can still revert lmtp_tls_security_level back to its Postfix
3.10 default (empty), and then figure out in Postfix 3.12 what
the configurtation model shuld be.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Having different defaults is an additional complexity that may not be
worth it, looking at the various use cases.
It's clear that for lmtp over unix socket the pre 3.11 of empty that is
interpreted to be "none" is fine.
If I were using tcp on the loopback interface I might be happy with the
same value. Nevertheless I would probably, maybe due to my
incomprehension of the real risks, be over cautious and set it "encrypt"
after making sure the receiving lmtp server was configured for that.
If I had the lmtp server on a separate server to postfix I'd go for
"encrypt". Some might not if there were a vpn connection, but I probably
still would for the same reason above.
I don't really see much use for a "may" default for lmtp over tcp. The
logic that makes "may" a good default for smtp where there is no
guarantee of end to end encryption, but better be encrypted if you can,
doesn't fit the lmtp use cases. "may" is going to be useful in the
context where people accidentally configure ssl on the lmtp server and
then postfix can take advantage of it. But also then, if it accidently
breaks, it will downgrade without warning, maybe fine for smtp, not so
good for lmtp. This is one case where I think the system admin needs to
make a choice. I'd go with the empty default and then leave the choice
to the good sense of the system admin.
John
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
