On 9/27/2012 4:38 PM, Wietse Venema wrote:
> 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.
Sounds useful.
>
> 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
I agree this is a reasonable built-in default. I suppose
smtpd_recipient_restrictions will be set empty as its built-in default.
>
> 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
I think a better upgrade compatibility shim would be to set
smtpd_relay_restrictions empty, ie. perform relay checks in
smtpd_recipient_restrictions as they are now; no behavior change.
and your proposed safety net looks to me as if it would defer all
{!mynetworks, !sasl, !auth_destination} mail before
smtpd_recipient_restrictions is evaluated. This would be surprising
upgrade behavior.
-- Noel Jones
>
> 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
>
