Re: [exim] DynaStop - I like it!

Marc Perkel wrote:
> I have 3 MX records. The highest MX always returns a defer for those who
> are trying to go in the back door. I'm now using DynaStop to return a
> defer on the lowest MX record for dynamic IPs. So the middle MX will
> accept these.
>
> What this does is it gets rid of spammers who don't retry. And the
> decrease has been huge. It has eliminated a lot of spam and has cut the
> load levels down on my servers significantly. Not getting any
> complaints. So I have to endorse it using it the way I'm using it.
>
>

You haven't actually provided evidence of *why* you believe it is working, and I
suspect, if only from how quickly you claimed success, that you haven't done the
analyis required to be able to determine the effectiveness.
You simply haven't had time to do so. Solid analysis needs days if not weeks of
traffic.

Take this example:

One 'farm' of 10 'bots are programmed to send 2 messages, each of 20 recipients,
wait 20 minutes, do it again, then repeat with a new payload at 4 hour
intervals, and to do the same to each mx than can be located, i.e. 3 such for
Perkel & Co.

Never mind for the moment how effectively - or not - you 'manage' the arrivals,
let's just calculated the totals and apply a SWAG, 'coz it is whatever it is.

- Presuming per-recipient filtering, and no rejections (yet) we have:

10 bots * 2 messages * 20 rcpts * 2 passes * 6 runs per day = 4,800 arrivals/day

and per each of 3 mx = 14,400 total

Now assume that the DynStop (or any other tool of choice) blocks 80% of these, a
safe assumption since it will by its nature block all 20 recipients and both
messages if it blocks a given host at all [1]. Other traffic is not on our plate
just now.

If rejecting .80 * 4,800 per mx = 3,840 rejections per mx
and 11,520 rejections in total.

If at this point you claim the 2 'diversionary' mx have saved your 'main' mx the
work of handling 7,680 rejections out of an extra 9,600 bogus message/recipient
deliveries, or IOW done 2/3 of the work, you have jumped to an unsupportable
conclusion.

The bots were not specified to double or triple-up on deliveries if they found
only 2 mx or one mx. Nor to divide the deliveries by 2 or by 3 if they found
more than one mx.

Each box was targetted equally. The more targets, the more bandwidth, the more
CPU cycles, the more electricity drawn from the grid, and the more heat and CO2
emitted.

*Unless* you can show that the arrivals for the 2d and 3d mx are greatly
different in nature, source, and payload than those hitting the primary.

And IF you can show that - then by definition - those were never targeting the
primary in the first place.

Lybarger's corollary to Sod's Law applies when you do that:

'All else being equal, you lose'

All you have done is put out more food for more of the same vultures, or
different food for a different species of vulture.

Different vultures - same vultures matters not.

You have more vultures either way.

So - yes - bless DynStop (or whatever else works) - but don't throw the
diversionary mx into the same equation.

They may have value - but this does not demonstrate it.

Bill


[1] Given zombies on Dynamic IP, 100% is more likely. But we are after assessing
the means used to measure success, not the success percentage itself.