Hello all - couple of questions…

#### Q1: Recipient & relay restriction evaluation order

Regarding the evaluation order of the SMTPD_RECIPIENT & SMTPD_RELAY restriction lists, there have been a few message threads that discuss the disparity between the Postfix documentation and the actual behavior. The docs say RELAY first but the actual behavior is RECIPIENT first and the reason given was for backwards compatibility.

So, a few questions:

* Can anyone confirm that the current behavior is actually required for backward compatibility?

* Are there any use-cases that state it is desirable to have RELAY eval’d first? * If both methods are required, are there plans to **(a)** add an entry for this in the backwards-compatibility safety net; and\or **(b)** add a config knob to change the evaluation order? * Aside from the above, are there plans to resolve the disparity between the docs and actual behavior?


#### Q2: Log entry START & STOP discrepancy

When using higher verbosity logging, each stage of the restriction list evaluations are bookended with a set of START & STOP lines that help delineate the eval steps for a particular restriction list. For example:

- - -

>>> END Sender address RESTRICTIONS <<<
>>> START Recipient address RESTRICTIONS <<<

Lots of log messages related to SMTPD_RECIPIENT_RESTRICTIONS evaluation

>>> END Recipient address RESTRICTIONS <<<
>>> START Recipient address RESTRICTIONS <<<

Lots of log messages related to SMTPD_RELAY_RESTRICTIONS evaluation

>>> END Recipient address RESTRICTIONS <<<
>>> CHECKING Recipient address VALIDATION MAPS <<<

- - -

Note in the above that the same START & STOP lines are listed for both the SMTPD_RECIPIENT & SMTPD_RELAY stages. I also confirmed that there are no START & STOP lines that mention RELAY — only CLIENT, HELO, SENDER, & RECIPIENT.

This seems to be an error but would like to see what the community thinks here…

Reply via email to