Re: [exim] mailq on MX secondary filling up with '550 unknow…

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.