Marc Perkel wrote:
> Working on load reduction tricks and increased spam rejection. It's sort
> of a greylisting trick for TLDs that tend to be mostly all spam. The
> idea being that the initial defer will get rid of a lot of spam that
> never retries after one defer where real email will retry and succeed. I
> have twt servers but this trick could be done on one server with 2 IP
> addresses. The idea is to apply the following to only the lowest MX
> record but accept the message on the higher MX. I thonk 90%+ of the spam
> never retries and therefore doesn't go through Spamassassin and reduces
> system load.
>
> defer log_message = DEFER - High Spam TLDs are accepted on the second
> MX server - junkemailfilter.com
> hosts = *.kr : *.cn : *.br : *.it : *.ru : *.pl : *.cl : *.ne : *.mx
>
> I have yet another trick where I have a third highest MX record and that
> IP returns DEFER on everything. That's for those spammers who try the
> highest MX first and then never retry. That saves me having to process
> about 120,000 spams a day.
>
> So - any reason the first trick won't work? Thoughts?
>
>
>
Dunno if it works, doubt it saves you anything w/r 'load
reduction' if it does.
Once you have a the connection, why not just apply protocol
checking, then drop the zombies on theirear, else 'park' them
for a few minutes and let them go away hungry.
Precise application of bog-standard Exim built-ins seem to block
90%+ ... and need not delay legitimate traffic, which we
typically pass in seconds, queue time included.
Not much mal-traffic here ever hits SA or ClamAV. Long gone.
OTOH, ipfw may sometimes have a hundred or so block rules in it,
many of them whole /24's (allocated-portable blocks, mostly)
That's 'load reduction' .... ;-)
Bill
