Autor: Alan J. Flavell Data: A: Sujit Choudhury CC: exim-users Assumpte: Re: [Exim] Too many mail coming through secondary mail server
On Fri, 28 Nov 2003, Sujit Choudhury wrote:
[..] > The two configuration are identical except
> For the primary: rfc1413_query_timeout=7s
> For the secondary: rfc1413_query_timeout=4s
>
> However lot of mail (approximately 10%) still comes to the secondary,
> even from outside.
Two questions to you:
What leads you to suppose that the identd timeout is significant to
this observation?
Are the mails that go via the secondary predominantly spam?
The reason I ask, is that we also have our identd timeout set to 7s,
but I have no reason to suppose that causes any substantial proportion
of senders to use our backup MX.
I haven't done an intensive study, but from observations there seem to
be two scenarios:
1. temporary errors such as DNS timeouts, or temporary failure of
callouts for those domains where we've decided to enable callouts; the
sending MTA contacts us, we get a timeout during our checks and send
a defer to the sending MTA, and it then uses the secondary MX
2. senders who go to our secondary MX without there being any evidence
of them trying the primary first, although - as far as we can see -
the primary was fully functional at the time; lots of spam is offered
to us in that way!
In both cases the pattern of behaviour is usually clear in the logs,
when we look for it.
One might suppose that under scenario 2 there would be two possible
explanations:
a) ratware that simply takes the first MX it can get, regardless of
its priority value
b) spammers deliberately choosing the secondary MX in the hope that
it's less effectively guarded against spam
But I have no way to decide between these two explanations.
> Can anybody suggest what can be done to reduce the number of mail to
> secondary mail server?
Why is that helpful, in and of itself? If you don't want mail taken
by a secondary server, then don't have a secondary server - easy as
that.
What we had considered at one time was to have the secondary server
try a callout to the primary, and issue a defer to any requests if the
primary appeared to be alive. But in fact we didn't really try that
out in practice.
You could have the secondary look-up a broad-spectrum DNSrbl
blacklist, and issue a defer on that basis. That way, when the
primary is down, the secondary will collect most of the bona fide
mail, whereas most of the spam will be deferred. If a few bona fide
mails get false positives, they just have to wait till the primary is
back in action, but no real harm done. And you'll have the benefit of
missing the spam from those spammers who can't be bothered to retry!
