On 9/28/2012 8:32 AM, Wietse Venema wrote:
> Noel Jones:
>> 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
>
Thanks for the clarification. Now I see what you intend, and I agree.
-- Noel Jones
