On 5 Apr 2016, at 10:59, jaso...@mail-central.com wrote:
looking at my notes, I found
...
With smtpd_delay_reject=no milters always follow built-in restriction
processing.
With smtpd_delay_reject=yes, milters process: connect -> helo/ehlo ->
from: before any smtpd_mumble_restrictions are evaluated, and then
restrictions starting with "rcpt to:".
...
Of course as usual that's not clear enough - NOW -
The milter protocol is somewhat analogous to Postfix's native
smtpd_*_restrictions in that each milter is passed a set of session (and
eventually message) attributes at each step of the SMTP conversation and
answers with its judgment of whether and how to proceed. *As I
understand it* (Viktor or Wietse will surely correct me if I
misunderstand) this is not changed by smtpd_delay_reject=yes in the same
way that setting modifies smtpd_*_restrictions action: the milters are
still called and answered at the protocol-defined times in their
specified order and if one tells Postfix to reject a message, that
rejection is immediate. However, as documented, smtpd_delay_reject=yes
delays *evaluation* of smtpd_{client,helo,sender}_restrictions until
RCPT time, so there is no way to override a pre-RCPT milter rejection
with any sort of exceptions implemented in smtpd_*_restrictions.
Note that this is not purely a Postfix issue. Rejection before RCPT in
some cases can result in some (faulty) clients retrying transactions
which should not be retried. This issue was discovered early in the days
of spam filtering and is part of why smtpd_delay_reject exists. It is
also why some milters (e.g. MIMEDefang) by default do not enable
pre-RCPT action and instead encourage only taking per-RCPT actions at
RCPT time, leaving everything else to the DATA phases.
& I can't remember the specific problem I was trying to solve, if any.
:-/
I can't help you there...
