John Horne wrote: >>> I know the proper way to do it would be to have an up-to-date list of >>> existing users on the Exim box for all "remote users", but it's not >>> always possible. >> That's a great use case for Exim's recipient callout verification. As >> long as the destination server rejects unknown recipients at SMTP >> time, your Exim will 'learn' (ie cache) which users are valid and >> which are not and reject invalid users. >> > The problem then (as seen here recently) is that Exim's cache gets out > of step with the recipient server. Exim then accepts the message, but > the recipient server rejects it. A bounce goes back to the sender, which > is what the OP was trying to avoid. > > In our case we have reduced the positive cache time, but I see no way > around some window of time existing in which a bounce could be sent out > other than not using Exim's positive cache at all.
I'm a big fan of rejecting at SMTP time, but there are cases were it's acceptable to have your system configured in such a way that it might cause the occasional unlikely bounce. What you've described above is one of those cases imo. /me waits for the "bouncing is NEVER acceptable" fascists to jump in. -- Mike Cardwell (https://secure.grepular.com/) (http://perlcv.com/) -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
