
To implement this trick you'll need to be able to add some records to the authoritative DNS servers for your domain and you'll also need a couple of available public IPs, one which may even be unassigned or in any case fully filtered (it suffices that port 25/tcp is filtered) and another one on which there's (currently) no listening SMTP server; you will also need a "fake MX" like the one (I wrote it) which can be downloaded here (complete with source code) and which runs w/o problems on almost any win32 platform
I wrote this program since, while there were a number of "bogus MX" programs for unix and other platforms there was almost nothing for windows, so I decided to write my own implementation; but let me start from the "MX sandwich" before talking about the program
The "MX sandwich" idea came from some observation made on spam sources behaviour with particular focus on "spambots" and in general spam spitting boxes; since those critters reason of life is spitting out as much junk as possible in the shortest interval of time, they use some tricks which also break the RFCs; let's start from a sample MX setup
$ORIGIN example.com
mx1 IN A 1.2.3.1
mx2 IN A 1.2.3.2
mx3 IN A 1.2.3.3
mx4 IN A 1.2.3.4
mx5 IN A 1.2.3.5
@ IN MX 10 mx1.example.com.
@ IN MX 20 mx2.example.com.
@ IN MX 30 mx3.example.com.
@ IN MX 40 mx4.example.com.
@ IN MX 50 mx5.example.com.
Now, referring to the above, there were a couple of observed behaviours from spambots or in any case "spam spitting" boxes
In many cases the "bots" go straight to the higher level MX (mx5) since in some cases, this isn't as "filtered" as the lower level ones and this in turn may allow the spambots junk to go through; in other cases, the bots go first to the lower level MX (mx1) and then jump straigh to the higher level one (mx5 or even mx4); this observation led to an idea which is the reason of life for the program I wrote
Let's refer to the above DNS settings and let's say you set up your regular, valid SMTP servers as mx2 and mx3; those servers
will accept incoming connections and serve them and btw may use whatever regular spam filtering; now... let's set up mx1 so that
the IP to which it points to will be "filtered" that is, your firewall will just drop any connection attempts going to port 25/tcp for mx1 so, hosts trying to connect to such a host will just timeout and the connection will end up with an error; next let's install on mx4 and mx5 a program (like my one) which will listen on 25/tcp, but, receiving a connection will always send out an SMTP temporary failure message like
421 4.2.1 Service temporarily unavailable, closing transmission channel.
at this point let's see what will happen if a REGULAR, valid external server will try to send you a message; the server will pick the lower MX (mx1) and try to connect; the connection will fail, so the server, following the RFCs will *immediately* try connecting to the next MX in preference order, that is mx2 and since we have a valid SMTP sitting there, the session will start and the mail will eventually get through; also, in case both mx2 and mx3 will for whatever reason be offline, a valid server will go on trying with mx4/mx5 but, getting tempfail messages it will just requeue the message and retry sending it at a later time But now let's see what will happen to a "junk spitting" box; it will either go straight to mx5 or mx4 ... and get a tempfail or it will try first mx1, get a connection failure and jump to mx5 or mx4 and get a tempfail message

It sounds incredible but just using this simple trick it's possible to reduce the amount of junk hitting your regular email servers (and the load on the servers) and all this without any adverse effects on the regular email flow;
You may think that the spammers will adapt but... the trick has been around for quite a lot of time now and it still works also, if you want to play tricks, you may swap around the fake MX; as long as the first MX points to a filtered address (this is needed to avoid problems with older mailservers like qmail which won't retry if they get a 4xx on first attempt) and the last to a fake MX, you may swap around the others, so spambots won't be able to tell "where" the good MX are sitting


idea and it will still work (it worked and works for me); in such a case the DNS setup would be
$ORIGIN example.com
mx1 IN A 1.2.3.1
mx2 IN A 1.2.3.2
mx3 IN A 1.2.3.3
@ IN MX 10 mx1.example.com.
@ IN MX 20 mx2.example.com.
@ IN MX 30 mx3.example.com.
where mx1 will be the filtered host, mx2 your regular SMTP server and mx3 the fake MX host; the remainder will work just as described above; as for the program, please have a look at the "fakemx.txt" file contained into the zip (see above link) and at the code which should be (I hope so) pretty easy to read
For further references about the "sandwich", please see
http://nolisting.org/
http://wiki.apache.org/spamassassin/OtherTricks
http://www.mail-archive.com/users@spama ... 51583.html