On 2007-12-20 at 14:23 +0100, Wouter Verhelst wrote: > Look for 'smtp_reserve_hosts'. With this, you can allow the backup MX to > connect to the master even when the master is already 4xx'ing other > hosts because of things like smtp_load_reserve.
Look up Single Point Of Failure. The point of secondary MX is to remove SPOFs whilst still accepting email to within your administrative control, so that you can clear things up quickly when problems are resolved and don't have to worry about broken remote systems doing things like auto-unsubscribing you from a mailing-list, etc. If you're happy for mail to remain with the senders' systems, then you don't need secondary MXs; if you treat email as sufficiently mission-critical that you should be able to deliver mail within a certain time-period, then secondary MXs aren't enough. Fully redundant parallel delivery which works is hard, secondary MX is "good enough" for most people. "The router crashed, mail couldn't get through for 10 minutes, but all the stuff sent by real MTAs went to the backup MX on the different network and I've flushed the queues, so all delayed email has now been delivered. If you don't have the important business document yet, it wasn't sent or is still in the sender's systems for some reason and it's their technical problem, not ours" It's ensuring that delivery is as timely as possible with recovery that's as quick as possible because delayed mail flushing is under the control of people who _know_ when the problem is gone. -Phil -- ## 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/
