Noel Jones:
[ Charset ISO-8859-1 unsupported, converting... ]
> 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.
Indeed.
> > 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.
That would not help the transition at all. It would nullify the new
parameter, and would merely time-shift the W*T*F bounces that will
happen when the compatibility shim is removed; it does nothing to
encourage sites to set up smtpd_relay_restrictions the way they
want it to be (empty or otherwise) before the new default takes
effect.
> 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.
That is exactly what I want; just like local_recipient_maps, this
temporary compatibility shim prevents mail from beiing W*T*F bounced,
so that sites have an opportunity to set up smtpd_relay_restrictions
the way that they really want it to be (either empty, or otherwise)
before the shim is removed from the install procedure.
[an entirely different approach is to have a "config_version"
parameter in main.cf, but everyone will hate this (me because it
increases the amount of testing, you because it increases the number
of configurations that people may have even when they run the latest
release, and everyone because the documentation will require an
if-then-else preprocessor to make sense of it all).
Wietse
>
> -- 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
> >
>
>
