Not strictly belonging to hMailServer (since it works with whatever mailserver) but the following trick will allow you to reduce the amount of junk hitting your server and also to reduce the load on it which, in case of heavy-load boxes isn't bad all all

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

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

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 notice that in my experience this isn't usually needed, but in case you'll need it... it can be done also, in case you have a single email server (and MX) you may still implement the whole
idea and it will still work (it worked and works for me); in such a case the DNS setup would be

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

Very clever ObiWan and indeed something discussed in IRC long ago with colleagues but no one had time to implement it so thanks for throwing it all together with the app/service, the excellent description and details as they are definitely clear enough to make sense to most on how it works and why.

You played with mx1 being dropped immediately vs 'held' a fixed amount of time or until timeout? Pros/cons to each approach of course but curious on actual results regarding spam (tarpit effect) vs effect on legit mail of each.

Also, you see much issue (as in happening often) with qmail not retrying with 4xx temp fail on 1st try? I swore ASSP does temp failure response to all connections when connection limit is reached, during shutdown or if no back end servers are available and don't recall it being an issue with lost email so makes me wonder if that is very common. (My ASSP is always maxed out so it's 4xx connections left & right but 99% spammers although doesn't mean legit email isn't trying in there too.) Obviously something to consider in either case but perhaps people have finally got around to upgrading those old beasts. lol

Thx
Bill

hMailServer build LIVE on my servers: 5.4-B2014050402#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

I did something similar to this but a lot easier to implement (I have posted about it here a few times)

I added a third MX record that points back to my primary MX's IP address and enabled greylisting. Spam bot goes for first then third (which is still the first server) and because the first server is still greylisted and it's not yet out of the threshold to resend it's continued to be greylisted. My actual backup MX is sat on my second MX record.

If at first you don't succeed, bomb disposal probably isn't for you! ヅ

Bill48105 wrote:Very clever ObiWan and indeed something discussed in IRC long ago with colleagues but no one had time to implement it so thanks for throwing it all together with the app/service, the excellent description and details as they are definitely clear enough to make sense to most on how it works and why.

You played with mx1 being dropped immediately vs 'held' a fixed amount of time or until timeout? Pros/cons to each approach of course but curious on actual results regarding spam (tarpit effect) vs effect on legit mail of each.

Also, you see much issue (as in happening often) with qmail not retrying with 4xx temp fail on 1st try? I swore ASSP does temp failure response to all connections when connection limit is reached, during shutdown or if no back end servers are available and don't recall it being an issue with lost email so makes me wonder if that is very common. (My ASSP is always maxed out so it's 4xx connections left & right but 99% spammers although doesn't mean legit email isn't trying in there too.) Obviously something to consider in either case but perhaps people have finally got around to upgrading those old beasts. lol

Thx
Bill

As for mx1, that depend from how you implement things; in my case I prefer going "classic" that is using a filtered port so that a host trying to connect to the port will have to wait for the connection, this btw means avoiding to saturate the "mx1" (assuming there's a box there ) but btw, if you feel it's ok, you may also play tarpit on mx1

As for qmail; I've seen some /sparse/ issues but really not so much (yeah, running ASSP on several boxes) and in general my setups solved those; ASSP is tricky since you've to play black magic when it comes to fine tune it, but once you've all your ducks in a row well... it really becomes a spamkiller

At any rate... my sandwich experiments started some time ago; I was asked to find a way to relieve the load on some servers which were heavily spam-bombed so, since I was aware of the "MX sandwich" trick, I decided to try it; problem was that there was no "fake mx" for the windows platform (which was all I had) so I decided to put together something; the first version of the fakemx was a barebone critter just listening on 25 and sending out a "tempfail" upon any connection, then, having some time in my hands I decided to improve it, so I added the "mailserver emulation", better logging and some more stuff which I thought may be useful and... well, you can see the result

^DooM^ wrote:I did something similar to this but a lot easier to implement (I have posted about it here a few times)

I added a third MX record that points back to my primary MX's IP address and enabled greylisting. Spam bot goes for first then third (which is still the first server) and because the first server is still greylisted and it's not yet out of the threshold to resend it's continued to be greylisted. My actual backup MX is sat on my second MX record.

Which means that in case your second MX goes offline, legit mail sender may end up blacklisted... not so cool imVHo

I dunno how your graylist implementation has been written, but in many cases,
hosts trying to resend before the gl time expired are "penalized" after some
attempts and they are then only allowed to reconnect after a quite long time
interval; that's what I meant by "blacklisted" (sorry if I was unclear); now let's
suppose your secondary MX goes offline for whatever reason, a legit sender
will try sending in an email to MX1, the server will send back a 4xx due to the
graylisting, the sender will then try MX3 and since it points to MX1 will get
another 4xx (and be tagged due to early try) ... now it all depends from how
the sender works; in some cases the mail will go back to a queue and then
the sending retry will take place from a *different* ip from the first one (IP
pools, you know), in such a case the message may end up with an error due
to too many retries and the sending server will send back to the original
message sender a failure notice

There is no penalty if you retry before the delayed time is up. If Secondary MX is offline then it will be delayed twice. You are also correct about IP Pooling being an issue which to be honest has always been a problem for greylisting regardless of if secondary MX's are offline or not. I have white listed the major players that do IP pooling and If my secondary MX is down I am aware of it within a few minutes and can rectify it. It has work extraordinarily well for me over the past few years with no reports of missing "expected" mails.

Every anti spam solutions has it's potential issues, that is ultimately up to the admin to weigh up before implementing

If at first you don't succeed, bomb disposal probably isn't for you! ヅ

^DooM^ wrote:There is no penalty if you retry before the delayed time is up. If Secondary MX is offline then it will be delayed twice.

hmm... ok, I see

^DooM^ wrote:You are also correct about IP Pooling being an issue which to be honest has always been a problem for greylisting regardless of if secondary MX's are offline or not. I have white listed the major players that do IP pooling

^DooM^ wrote:Every anti spam solutions has it's potential issues, that is ultimately up to the admin to weigh up before implementing

seconded; in my case (using extensively ASSP) the "senderbase organization" testing was one of the most useful additions since it allowed me to "whitelist" good senders even without knowing their IPs in advance (same when it comes to "blacklist" bad senders btw )

Last edited by ^DooM^ on 2010-07-23 11:28, edited 1 time in total.
Reason:Fixed URL

I added a "CheckIP" function which will take care of "wildcarding"
the IPs as needed, notice that since I was in doubt I decided to
use the ".*.*" approach so that a partial IP like 1.2 will be inserted
into the list as 1.2.*.* if that's not correct then you'll have to edit
and modify the "CheckIP()" function

mattg wrote:looks like it is going to download for me....Perhaps try again

Maybe a temp glitch; anyways, the zip is up there and contains the sources as well,
feel free to either use the binary or recompile the sources or even modify them to fit
your needs; in such a case, please, send me your modified source since I may then
incorporate your changes in the "regular" source