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…