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/)
