> > The corollary and implication of this is that if you have routers
> > that will only work properly once the message is fully received
> > (because they require headers or ACL variables only set then), you
> > need to mark them as no_verify, and possibly write verify_only
> > versions that do address validation of some sort but no actual
> > router processing.
>
> But what do you mean by "properly"? How does a router do verification
> "improperly"? What will in fact happen in the situation I staged in
> the first paragraph above, which in my estimation is not at all
> unusual (it may even be in the example config, I haven't checked; of
> course the added wrinkle is the .forward filter file, but that too
> isn't too exotic, I hope).
To use a non-hypothetical example, we have routers that behave
differently depending on the spam score assigned to an email message.
This spam score is only available at the end of DATA, so in the general
sense these routers don't work properly if used during RCPT TO; their
proper operation requires information that's not yet available. If you
allow people to write Exim filters (in Sieve or Exim format) and then
evaluate these filters as part of routers (the usual case), people can
write filters that behave differently depending on what header fields
are present and what their value is, and these header fields won't be
available at RCPT TO time.
(Technically what we mostly have is routers with 'condition = ...',
with some routers acting on 'the score is high enough' and other routers
acting otherwise.)
You can construct situations where a RCPT TO check (without the headers
or other information available) results in the mail going to one
address, and the normal routing and delivery process sends it to a
different one. If one of those addresses is invalid or nonexistent and
the other one is valid, you have a situation where the RCPT TO
verification will give a different result than the normal delivery.
This is a relatively obscure and probably rare case, and often people
don't really care if RCPT TO accepts an address as 'verified' when
your main router processing with the full message will later cause it to
bounce. Things bounce after being accepted all the time.
(Rejecting things at RCPT TO time that you would have delivered is
usually rarer and people tend to notice it pretty fast.)
- cks
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
