On 06/13/2015 06:06 AM, Viktor Dukhovni wrote:
> If the expected maximum downtime for the backend system is well
> below the positive cache time on the frontend, you can ignore the
> possibility of backend downtime. Once the cache is primed with
> all the addresses that routinely receive email, the backend system
> is not needed to validate incoming email.
> Otherwise, there's only one correct solution: Automate replication
> of recipient validation tables from the backend system to the
> front-end system. Stop using recipient verification probes, and
> just use local (replicated) tables on both systems. Anything else
> has warts. You can tweak the exact manner in which you lose, but
> you can't not lose.
>
On 06/13/2015 06:08 AM, Wietse Venema wrote:
> Question: an up-stream server must not reject unverified recipients
> when the down-stream server is unavailable.
>
> Answer: let the address verification cache (address_verify_map) in
> the up-stream server work for you.
>
> Once an address is stored in the address verification cache (this
> requires that the down-stream mail server is sometimes available)
> the address remains cached for 31 days.
>
> Also, when the down-stream mail server is available, the up-stream
> server will "refresh" a cached address that is older than 15 days.
> This refresh happens only when an address receives mail; an inactive
> address will be dropped from the cache when it is older than 31 days.
>
> If you are really worried that a "new" or "inactive" user isn't
> cached, you could use a small program that runs on the down-stream
> server and that sends "rcpt to" commands to the up-stream mail
> server. That script has to respect the smtpd_recipient_limit setting
> (default: 1000).
Useful reminders.
Particularly "You can tweak the exact manner in which you lose, but you can't
not lose."
I'd missed the 31/15 days cache expiry durations. That helps evaluate risk.
At those cache times, the 'healing & recovery' mechanisms inherent in recipient
validity caching and sender redelivery appear more than adequate.
For this particular implementation, however, the backend is considered
unreliable. I'd rather deploy a standalone, higher-availability solution, but
will have to leave that for other deployments.
I prefer the 'clean & simple' nature of remote address verification, and have a
general reticence to complicating the front-end with yet another database or
sync process for table replication.
However, a periodically sync'd list of users appears to ameliorate the problem.
Of the 2 simplest options
(1) warming the already in-place 'address verification cache
(address_verify_map) in the up-stream server', by sending emails from the
backend to the frontend clustered into recipient lists < its
smtpd_recipient_limit
&
(2) rsync-ing a simple list of known users from the backend to the
frontend in/as a regularly postmap'd lmdb table or a no-reload-needed pcre
table, either replacing, or complementing (not sure yet if that's wise),
recipient verification
both are trivial scripts.
Is there any particular preference for using one over the other?
