> > 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-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/