On Sun, 26 Mar 2006, Tim Jackson wrote: [...] > 2. Enable recipient verification callouts on the secondary. e.g. " > deny !verify = recipient/callout=use_sender,defer_ok ". This will > forward recipient checks onto the primary, which is OK as long as > the primary is up and/or the callout details are in Exim's cache (it > hangs onto them for a while, see manual for details of callout > cache). If your primary is down for long periods you might want to > tweak the expiry times of data in the callout cache.
Agreed. A couple of additional points, if I may: a) We get the impression that some spammers deliberately try the secondary MX, without having attempted to deliver to the primary, presumably in the hope that the anti-spam measures on the secondary will be less stringent. This has been discussed before - some folks have suggested having three MX records, the first choice for the primary, the second choice for the real secondary, and a spoof third choice, intended to catch- out abusers who will try the last choice first. It's open to discussion what the spoof MX should do: as long as spammers rarely implement a retry strategy, it might be sufficient for it to simply respond to every request with a "defer" status. That should be harmless to bona fide requests, in the event of them ever getting there. b) When spammers are hammering the primary MX, then they can use up the max SMTP calls limit (global, or per host), resulting in the primary rejecting the call, and they then fall back to using the secondary. Both kinds of behaviour can be discerned if one looks for the patterns in the log of the primary MX. The fact that an abuser is trying the secondary MX doesn't in itself mean that the primary MX is "down" - it may be working just fine. I surmise (though haven't studied this in detail) that by suitable settings of max SMTP calls per host, with settings for reserved hosts, it will still be possible for the secondary to successfully perform callout verification with the primary, at times when both of them are working but the primary rejected the external call due to smtp_accept_max* limits. In discussing doing something against the abuse, we have at times toyed with the idea of the secondary verifying that the primary is basically "up" and, if it is, responding to the caller with a "defer", rather than proceeding with the transaction. The intention being that the caller should retry the primary host later. We never really tried it out in production, though. -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
