On 9/28/2012 8:37 AM, Michael Storz wrote: > Am 2012-09-28 14:44, schrieb Wietse Venema: >> Michael Storz: > If smtpd_relay_restrictions behaves like all the other restriction > classes, > that means after the permit has fired, the first restriction of > smtpd_recipient_restrictions is executed, then take the following > scenario: > > Before introduction of smtpd_relay_restrictions, the restrictions > would be > > smtpd_recipient_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject_unauth_destination > uce_restriction1 > ... > uce_restrictionn > > after the introduction > > smtpd_relay_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject_unauth_destination > > smtpd_recipient_restrictions = > uce_restriction1 > ... > uce_restrictionn > > if I understand you correctly. In this case you have a major > semantic change: > permitted recipients will be evaluated against the uce_restrictions, > whereas > in the old configuration this is not the case. > > Michael >
No, this is wrong. The new feature means you may *optionally* separate relay decisions from smtpd_recipient_restrictions, providing a little more safety and flexibility than currently available. It is not a major semantic change -- IMHO not a semantic change at all, just an added feature. -- Noel Jones
