[pfx] Re: What features to deprecate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2024-02-13 at 18:32 +0100, Geert Hendrickx via Postfix-users wrote: > On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix- > users wrote: > > - masquerade_domains complicates table-driven address validation. > > Log a deprecation warning with compatibility_levels>=3.9. > > > What's the alternative for masquerade_domains ? FWIW I use multi-master LDAP with a bunch of virtual transport and relay records in main.cf. This also has the benefit that my MX hosts can authenticate users and allow them to send email out via that route in the event of the main [submission] host being down. The solution may not be for everyone, but has worked for me in a number of scenarios - even one where the actual mail server was "hidden" (the bosses term, not mine) behind a couple of layers of MX and was (I'm not going to name names) a particular "collaboration suite" that was a java web frontend with a combination of different FOSS tools underneath - the ones that were of use to me were openldap, postfix, dovecot, and mysql/maraidb. This allowed us to extract lists of valid domains, and email addresses to let through the remote MX's (both in and out) - all we had to do was run a small script once an hour to get those lists, and if they had changed push them out to the MX hosts. This solution was _almost_ as good as having either multi-master or slave nodes for LDAP (or a database server if that is you weapon of choice). Distributing your data like this can be good for redundancy purposes as well (being able to dump and backup a database, ldap directory, or even just text lists in multiple locations can save your bacon when things get rough), it can also make it easier for failover and faster for passing through only legitimate mail. Three of the documentation pages with either relevant information, or config directives that can help with this are: https://www.postfix.com/SMTPD_ACCESS_README.html https://www.postfix.com/VIRTUAL_README.html https://www.postfix.com/SMTPD_POLICY_README.html And if that's not enough just start reading the page with _all_ the configuration directive and figure out what you need - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMvx8ACgkQ4ZaDRV2V L6RgOQ//bzBsmvF8G/lxIfhUhZ/tBlWv0kHpeYnUzizj93R9P6ODfv3UjTm+gYH1 RlCe0zbeQ+rbnx7H4jTJRnp1Uy9R8zhw+RVj3zPtFEQYXAc+iN45P6GeZh6K+a6q /v3Qw5G18qHJ5fFOmo2ojMNl/s9hjecuaMUwLRrFrf93JlQkBERTctKiSWRAv5eq /WaicL/hlpk+U1cwFrWTcxoAaZ+DTBrBmBZVG5zpRY/s2vvhx+wbY7rRAViirmM2 6kqIOwEmNOuxYNd7yFMQEQS2DRNkfmX8XjrN/XW5Il+Z0aS4TyswNderc/KLR/rg Zs2RiCKot8l/9Pr1vBxPbYBGu4D074mJTOGicOodYeQC6BhA1QFbAh5TzkQxnuJ1 vqC+2lHkD4eyVogvLPfkrI6xU5Birn/Fh/G5xCER3fWq0Ae1SVksakriBCOMSw02 izrd0Ehdh5BSxjiHc2ixVR7uSOjNu6l8OgNBntw8PnXiwvcTUVOyPKelYIsGT6u0 7kOe81I+E9qm1wa8tg4HRoB7+sMLpsxqbhDNAW3x0DzsW7vbkcDtt2slxiwzDcRT CH0EGAInFZeLh2weoLalNDcpp5QCAz4GzOyxfjmtS7WMfuJghtpmBO7ar0CqvZQC nVKxIeaSWJsVxbu/AkFLZajuR1scjyBP5rmXdmWBN47YyoENJO8= =4/pO -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
> On 14. Feb 2024, at 09:23, Geert Hendrickx via Postfix-users > wrote: > >> Of course it is best dealt with at the source by configuring the >> client systems to use the correct domain. > > > Perhaps, but not all client systems are under our control (trusted but not > necessarily cooperative), and it is convenient to manage the (evolving) > mail policy in a central place, rather than on a large number of variour > client systems. (and even there, a single masquerade_domains setting would > be handier than an explicit canonical_maps). Having just introduced ‘masquerade_domains’, I can not agree more, “trusted but not necessarily cooperative” is a beautiful way to put it ;) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 12:51:51 -0500, Viktor Dukhovni via Postfix-users wrote: > On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users > wrote: > > What's the alternative for masquerade_domains ? > > It is canonical_maps, ideally with explicit mappings for each expected > non-canonical address. For an outbound-only Postfix relay or submission > instance, the canonical mapping could use wildcards or regular > expression mappings. Though in the same context (no inbound mail) the > use of "masquerade_domains" has little down-side. Yes, we use masquerade_domains on an outbound mail relay for a large group of internal servers (typically sending cron mail or other automated reports, so no inbound mail). This was/is the classical case for masquerade_domains? We rewrite only envelope_sender from user@host.domain to user@domain for SPF compliance (not needing an SPF record for each individual hostname). The From header is left alone, as it is DMARC aligned. Achieving the same with canonical_maps would require regular expressions, as there is no catch-all ".domain" support in canonical(5) ? > Of course it is best dealt with at the source by configuring the > client systems to use the correct domain. Perhaps, but not all client systems are under our control (trusted but not necessarily cooperative), and it is convenient to manage the (evolving) mail policy in a central place, rather than on a large number of variour client systems. (and even there, a single masquerade_domains setting would be handier than an explicit canonical_maps). Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 01:20:00PM -0500, Wietse Venema via Postfix-users wrote: > > Obsoleted by automatic negotiation in the SSL code: > > > > - smtpd_tls_dh1024_param_file = auto > > - smtpd_tls_eecdh_grade = auto > > > > [ We could delete the underlying support code for the explicit choices, > > and always use 'auto' with a warning if the configuration specifies > > a different choice. Mind you, automatic DH group negotiation is > > prone to choosing largish > 2048-bit groups, when the server will sign > > with a large RSA private key, but this feels somewhat justifiable. ] > > Isn't that TLS version dependent, or have we already lost support for > the old way? For EECDH, "auto" has worked for a long time, and is basically an interoperability requirement! Automatic (FF)DH group selection in the SSL stack requires OpenSSL 3.0, but recent Postfix versions emulate "auto" by using a compiled in DH group, which is quite "good enough" in practice. So "auto" already works. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
Viktor Dukhovni via Postfix-users: > On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users > wrote: > > > Over 25 years, Postfix has accumulated some features that > > are essentially obsolete. > > > > - permit_mx_backup is fundamentally incompatible with recipient > > address validation. There is no way to work around that with > > reject_unverified_recipient, because that requires that a domain > > is reachable, and in that case permit_mx_backup is not needed. > > Log a deprecation warning with compatibility_levels>=3.9. > > > > - masquerade_domains complicates table-driven address validation. > > Log a deprecation warning with compatibility_levels>=3.9. > > > > - disable_dns_lookups can be migrated to smtp_dns_support_level > > which implements a superset of the functionality. Log a deprecation > > warning with compatibility_levels>=3.9. > > > > What else needs to go? > > Obsoleted by TLS security levels: > > - lmtp_enforce_tls > - lmtp_use_tls > - postscreen_enforce_tls > - postscreen_use_tls > - smtp_enforce_tls > - smtp_use_tls > - smtpd_enforce_tls > - smtpd_use_tls > - tlsproxy_client_enforce_tls > - tlsproxy_client_use_tls > - tlsproxy_enforce_tls > - tlsproxy_use_tls > > Obsoleted by TLS policy maps: > > - lmtp_tls_per_site > - smtp_tls_per_site > - tlsproxy_client_per_site The above are easy to flag if explicitly set. No risk of breaking code. > Obsoleted by automatic negotiation in the SSL code: > > - smtpd_tls_dh1024_param_file = auto > - smtpd_tls_eecdh_grade = auto > > [ We could delete the underlying support code for the explicit choices, > and always use 'auto' with a warning if the configuration specifies > a different choice. Mind you, automatic DH group negotiation is > prone to choosing largish > 2048-bit groups, when the server will sign > with a large RSA private key, but this feels somewhat justifiable. ] Isn't that TLS version dependent, or have we already lost support for the old way? > Perhaps more controversial: > > - parent_domains_matches_subdomains > > This should IMHO be empty, with all parent-domain rules being explicit. > Its convenience is offset by not entirely infrequent user confusion > about where ".domain" is required (transport(5) table) and where it is > not by default (access(5) table). That's a lot of code that would have to become compatibility level dependent. This is likely too invasive for Postfix 3.9. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
Geert Hendrickx via Postfix-users: > On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix-users wrote: > > - masquerade_domains complicates table-driven address validation. > > Log a deprecation warning with compatibility_levels>=3.9. > > > What's the alternative for masquerade_domains ? The proper alternative is a two-way 1:1 mapping between internal email addresses and the corresponding addresses in 'publicly visible' domains. On an inbound email gateway, accept only recipients in 'publicly visible' domains, and map the envelope recipient to the corresponding internal address. On an outbound email gateway, accept only sender addresses that have a 'publicly visible' equivalent, and convert internal address forms to the 'public' forms. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users wrote: > On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix-users wrote: > > - masquerade_domains complicates table-driven address validation. > > Log a deprecation warning with compatibility_levels>=3.9. > > > What's the alternative for masquerade_domains ? It is canonical_maps, ideally with explicit mappings for each expected non-canonical address. For an outbound-only Postfix relay or submission instance, the canonical mapping could use wildcards or regular expression mappings. Though in the same context (no inbound mail) the use of "masquerade_domains" has little down-side. Of course it is best dealt with at the source by configuring the client systems to use the correct domain. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users wrote: > Over 25 years, Postfix has accumulated some features that > are essentially obsolete. > > - permit_mx_backup is fundamentally incompatible with recipient > address validation. There is no way to work around that with > reject_unverified_recipient, because that requires that a domain > is reachable, and in that case permit_mx_backup is not needed. > Log a deprecation warning with compatibility_levels>=3.9. > > - masquerade_domains complicates table-driven address validation. > Log a deprecation warning with compatibility_levels>=3.9. > > - disable_dns_lookups can be migrated to smtp_dns_support_level > which implements a superset of the functionality. Log a deprecation > warning with compatibility_levels>=3.9. > > What else needs to go? Obsoleted by TLS security levels: - lmtp_enforce_tls - lmtp_use_tls - postscreen_enforce_tls - postscreen_use_tls - smtp_enforce_tls - smtp_use_tls - smtpd_enforce_tls - smtpd_use_tls - tlsproxy_client_enforce_tls - tlsproxy_client_use_tls - tlsproxy_enforce_tls - tlsproxy_use_tls Obsoleted by TLS policy maps: - lmtp_tls_per_site - smtp_tls_per_site - tlsproxy_client_per_site Obsoleted by automatic negotiation in the SSL code: - smtpd_tls_dh1024_param_file = auto - smtpd_tls_eecdh_grade = auto [ We could delete the underlying support code for the explicit choices, and always use 'auto' with a warning if the configuration specifies a different choice. Mind you, automatic DH group negotiation is prone to choosing largish > 2048-bit groups, when the server will sign with a large RSA private key, but this feels somewhat justifiable. ] Perhaps more controversial: - parent_domains_matches_subdomains This should IMHO be empty, with all parent-domain rules being explicit. Its convenience is offset by not entirely infrequent user confusion about where ".domain" is required (transport(5) table) and where it is not by default (access(5) table). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix-users wrote: > - masquerade_domains complicates table-driven address validation. > Log a deprecation warning with compatibility_levels>=3.9. What's the alternative for masquerade_domains ? Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
