Blocking MX query

Wed Sep 5 00:52:58 UTC 2012

On 9/4/12, Rich Kulawiec <rsk at gsp.org> wrote:
> You're precisely correct.  They've been doing this for many years,
> (a) because it's efficient (b) because it evades detection by techniques
> that monitor MX query volume (c) because few MX's change often (d) because
> it scales beautifully across large botnets.

One can begin to envision a spam avoidance scheme; where a mail server
is assigned a random IP  within an IPv6 prefix based on a EUI64/UUID.
Two static MX records are published;  each MX referencing short-lived
AAAA records with a TTL of 60 seconds or less.

One of those AAAA records points to  the current IP address of the
mail server, and one of those AAAA records point to the "next one".
A mail server binds to each address both "previous" and "next" and
accepts port 25 connections for mail delivery.

Every 60 seconds,  the "current address" AAA  record is  changed to
the IP listed in the "next address" AAA record;   a  new EUI64 is
generated, and the  "next address" AAAA record is populated with the
new randomly generated IPV6 address.

A mail server for the domain binds the new IP address and starts
listening;  and starts tarpitting any new port 25 connections from the
previous address in 90 seconds.

After 600 seconds, or when the IP is no longer in the most recent 5,
an6 existing SMTP connections to the old server IP (from unacceptably
slow senders/deliveries) are terminated, and the server removes the
old IP from its interface.

--
-JH