Autor: Giuliano Gavazzi Data: Para: Alun, exim-users Assunto: Re: [Exim] Using secondaries for anti-spam (was "Secondary MX -
defer if primary is up")
At 12:40 pm +0100 2004/05/17, Alun wrote: >All this discussion has got me thinking of "yet another bad idea (tm)". What
>if I were to run a secondary MX on an IP alias on one of my primary servers.
>All mail attempted to this IP would be deferred at RCPT time (I should
>mention that aber.ac.uk doesn't have a secondary mx at all at the moment).
>
although this was an old idea, because of your post I decided to see
if this "fact", spammers hitting secondaries, holds true. My result
so far is that if they do, they must not respect DNS TTL times as I
have had no hits in over 12 hours after I added a bogus secondary
with MX records that have 1 hour TTL. Perhaps they use the expiry
time (that is 8 weeks in my case) or some fixed value.
Note that my MINIMUM is also very small (it is used for negative
caching in bind 9 but was the default TTL in bind 8, how the two
coexist is unclear to me).
This gives me a different idea, I don't know if old or new:
quickly (say every 2xTTL) rotate the MX (or the corresponding A
record) across a pool of N available IP aliases, and have exim at the
same time listening on the current and previous one.
If spammerware caches DNS for longer than the TTL (if this is small)
you will have (for persistent spammerware) reduced the chance that
they hit the correct MX by something proportional to N/2. Of course
occasional spam source (hijacked servers, virus, etc) will not be
affected.
This approach is of course no more effective and probably adds
nothing to normal spam measures as persistent spamware is probably
already RBLed.
So forget it!
Another approach I have seen used is to have a cascade of MXes of
which the first few seem to timeout consistently, causing proper
servers to fall back until they hit the working one. Anyone from
apu.ac.uk here...? Presumably they have a list of whitelisted hosts,
or some other connection criterium, otherwise I see this as a pretty
unpolite policy..