1. We are blocking spam using the following method:
# address is in various spam blacklist - so rejected
deny message = rejected because \
$sender_host_address is in a black list at \
$dnslist_domain\n$dnslist_text
dnslists = rbl-plus.mail-abuse.ja.net : \
sbl.spamhaus.org : \
opm.blitzed.org : \
cbl.abuseat.org
So the figures are actually that entered the machine.
These blacklists are the same for primary and secondary. We also do
virus checking after the mail entered the machine. However we are not
using Spamassasin.
- Sujit
>-----Original Message-----
>From: Alan J. Flavell [mailto:a.flavell@physics.gla.ac.uk]
>Sent: 28 November 2003 17:40
>To: Sujit Choudhury
>Cc: exim-users@???
>Subject: 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!
>
>best regards
>
