Victor discussed smtpd_relay_restrictions 6 years, see
http://archives.neohapsis.com/archives/postfix/2006-05/0598.html.
The article also discussed a number of other ideas that have potential
to increase the Postfix learning curve. I'll leave those for now.
My current goal is to make Postfix easier to use by eliminating one
opportunity for human error.
It seems that smtpd_relay_restrictions can be introduced with little
pain, and that it can simplify configuration, with the direct benefit
that it would prevent easy-to-make mistakes when all anti-spam
features are placed in smtpd_recipient_restrictions.
I'm considering the idea to place smtpd_relay_restrictions before
smtpd_recipient_restrictions, so that it can eliminate unnecessary
work (there is little benefit from querying policy servers or DNSBLs
when smtpd_relay_restrictions rejects a recipient).
As the built-in default value I consider adopting Victor's suggestion:
smtpd_relay_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
This default setting would almost never need to be changed (by the
way, that by itself presents a small usability problem - if people
don't need to change this setting then its existence is not obvious).
>From a user interface point of view there need be no surprises;
both smtpd_relay_restrictions and smtpd_recipient_restrictions can
behave identically. That reduces the human learning curve, and the
effort of implementation and documentation.
For usability reasons, I would allow one desirable difference: when
smtpd_relay_restrictions contains reject_unauth_destination or
reject, then they are not needed in smtpd_recipient_restrictions.
This means that sites can avoid a backwards compatibility break
simply by setting "smtpd_relay_restrictions =" in main.cf, and get
the exact same behavior of previous Postfix versions.
Perhaps for the first few years the install procedure should introduce
smtpd_relay_restrictions with a safety net, to prevent mail from
bouncing unexpectedly:
smtpd_relay_restrictions = permit_mynetworks
permit_sasl_authenticated
permit_auth_destination
defer
This is similar to the way that local_recipient_maps was introduced
in Postfix 2.0 without unexpectedly bouncing mail after an upgrade.
On the other hand the likelihood of breakage is much smaller with
smtpd_relay_restrictions than it ever was with local_recipient_maps,
so perhaps smtpd_relay_restrictions does not need the temporary
safety net.
In any case, smtpd_relay_restrictions would feature first in a
non-production release so that we can get some experience with it.
Wietse
