Use an "MX sandwich" to reduce spam and load

This section contains scripts that hMailServer has contributed with. hMailServer 5 is needed to use these.
Post Reply
ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-22 17:53

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

@ 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 :) 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

$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

Bill48105
Developer
Developer
Posts: 6189
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Use an "MX sandwich" to reduce spam and load

Post by Bill48105 » 2010-07-22 19:38

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. ***

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-22 19:46

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! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-22 21:34

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 :D) 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

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-22 21:35

^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

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 02:00

blacklisted? I don't see how my setup blacklists anyone.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 09:07

^DooM^ wrote:blacklisted? I don't see how my setup blacklists anyone.
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

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 09:39

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! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 09:55

^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
as for the whitelisting you may try picking this list http://sqlgrey.bouton.name/clients_ip_whitelist not a complete one but a decent startup
^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 :D)
Last edited by ^DooM^ on 2010-07-23 11:28, edited 1 time in total.
Reason: Fixed URL

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 10:08

Oh that whitelist looks promising, thanks.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 12:52

^DooM^ wrote:Oh that whitelist looks promising, thanks.
There's a similar list here, although I'm not sure it's up-to-date

As for loading the list; since I had to load it into hMailServer GL whitelist
and didn't want to do that by hand, I quickly wrote a small vbscript, nothing
special, mind me but it fits the bill

Code: Select all

See Below for new code
just a note, the scripts does NOT empty the list before loading the
IPs so you'll need to do that manually (but it's quick and easy)

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 12:56

Nice, i just ran it through a text editor, converted it to a CSV and dumped it direct to the database. Handy for those that don't like to poke around in the DB though. Most appreciated
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 13:00

for those that want to import csv

Code: Select all

12.5.136.141,Southwest Airlines (unique sender, no retry)
12.5.136.142,Southwest Airlines (unique sender, no retry)
12.107.209.244,kernel.org mailing lists (high traffic, unique sender per mail)
12.107.209.250,sourceware.org mailing lists (high traffic, unique sender per mail)
63.82.37.110,SLmail
64.7.153.18,sentex.ca (common pool)
64.12.137.*,AOL (common pool) - http://postmaster.aol.com/servers/imo.html
64.12.138.*,AOL (common pool)
64.124.204.39,moveon.org (unique sender per attempt)
64.125.132.254,collab.net (unique sender per attempt)
64.233.170.*,gmail (common server pool)
65.82.241.160,Groupwise?
66.94.237.*,Yahoo Groups?
66.100.210.82,Groupwise?
66.135.209.*,Ebay (for time critical alerts)
66.135.197.*,Ebay (common pool)
66.162.216.166,Groupwise?
66.206.22.82,PLEXOR
66.206.22.83,PLEXOR
66.206.22.84,PLEXOR
66.206.22.85,PLEXOR
66.218.66.*,Yahoo Groups servers (common pool, no retry)
66.218.67.*,Yahoo Groups servers (common pool, no retry)
66.218.69.*,Yahoo Groups servers (common pool, no retry)
66.27.51.218,ljbtc.com (Groupwise)
66.89.73.101,Groupwise?
68.15.115.88,Groupwise?
152.163.225.*,AOL (common pool)
194.245.101.88,Joker.com (email forwarding server)
195.235.39.19,Tid InfoMail Exchanger v2.20
195.238.2.105,skynet.be (wierd retry pattern)
195.238.2.124,skynet.be (common pool)
195.238.3.12,skynet.be (common pool)
195.238.3.13,skynet.be (common pool)
204.60.8.162,Groupwise?
204.107.120.10,Ameritrade (no retry)
205.188.139.136,AOL (common pool)
205.188.139.137,AOL (common pool)
205.188.144.207,AOL (common pool)
205.188.144.208,AOL (common pool)
205.188.156.66,AOL (common pool)
205.188.157.*,AOL (common pool)
205.188.159.7,AOL (common pool)
205.206.231.*,SecurityFocus.com (unique sender per attempt)
205.211.164.50,sentex.ca (common pool)
207.115.63.*,Prodigy (broken software that retries continually with no delay)
207.171.168.*,Amazon.com (common pool)
207.171.180.*,Amazon.com (common pool)
207.171.187.*,Amazon.com (common pool)
207.171.188.*,Amazon.com (common pool)
207.171.190.*,Amazon.com (common pool)
211.29.132.*,optusnet.com.au (wierd retry pattern and more than 48hrs)
213.136.52.31,Mysql.com (unique sender)
216.136.226.0,Yahoo Mail?
216.157.204.5,Groupwise?
217.158.50.178,AXKit mailing list (unique sender per attempt)
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 15:18

Here's the updated script (just wondering if it may belong to
the "scripts" area of the forums)

Code: Select all

See Below for new code
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

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 15:19

.* and .*.* should both be fine. I'll move over to scripts.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 15:27

^DooM^ wrote:.* and .*.* should both be fine. I'll move over to scripts.
There's a bug, here's the fixed version (sorry !!)

Code: Select all

':::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
' adds whitelisted IPs to the hMailServer graylist; to
' obtain an IP list, visit the following
'
' http://sqlgrey.bouton.name/clients_ip_whitelist
' http://projects.puremagic.com/web-svn/wsvn/greylisting/trunk/schema/whitelist_ip.txt
'
' save either file (or both, as long as you remove the
' duplicate records and keep the comments) as "glwhite.txt"
' then run this script to load the IP list in hMailServer
'
' NOTE: the script DOES NOT remove entries from the GL whitelist
'       before loading the IPs, so you'll need to manually clear
'       your list before running it to avoid duplicate entries
':::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

  
  ' require var declaration
  Option Explicit

  ' global constants
  Const ForReading = 1, ForWriting = 2, ForAppending = 8

  ' globals
  Dim fso, arg
  Dim vaRec, iRec

'// bootstraps the code 
'__boot() {
  Set fso = CreateObject("Scripting.FileSystemObject")
  Set arg = WScript.Arguments
  WScript.Quit main(arg.Count, arg)
'}  

' main, everything starts here
Function main(argc, argv)

  ' did we get needed args ?
  If argc <> 2 Then
    printf("usage: cscript glwhite.vbs adminuser adminpass")
    main = 1
    Exit Function
  End If
  
  ' load the IP list from file
  If LoadList("glwhite.txt") < 1 Then
    printf("File glwhite.txt missing or empty, aborting.")
    main = 2
    Exit Function
  End If
  
  ' import the list into hMailServer GL whitelist
  If SetGLwhitelist(argv(0), argv(1)) < 1 Then
    printf("No GL whitelist entries added.")
    main = 3
    Exit Function
  End If
  
  ' all done
  main = 0
End Function  

' print a message to console
Sub printf(sStr)
  WScript.StdOut.WriteLine sStr  
End Sub

' loads entries into hMail GL whitelist
Function SetGLwhitelist(sUser, sPass)
  Dim oHMail, oGLWA, oItm
  Dim vaInf, nRec

  ' init
  SetGLwhitelist = 0
  Set oHMail = CreateObject("hMailServer.Application")
  Call oHMail.Authenticate(sUser, sPass)
  Set oGLWA = oHMail.Settings.AntiSpam.GreyListingWhiteAddresses
  
  ' loop through entries and add them
  nRec = 0
  For iRec = LBound(vaRec) To UBound(vaRec)
    If Len(vaRec(iRec)) > 0 Then
      vaInf = Split(vaRec(iRec), vbTab)
      printf "Adding " & vaInf(0) & " " & vaInf(1) & " ..."
      Set oItm = oGLWA.Add()
      oItm.IPAddress = vaInf(0)
      oItm.Description = vaInf(1)
      oItm.Save
      nRec = nRec + 1
    End If
  Next

  ' done
  SetGLwhitelist = nRec
End Function  
  
' load the list from file  
Function LoadList(sFileName)
  Dim fp, sBuff, nPos
  Dim sIP, sName, sComment
  Dim nGood

  ' load data from file  
  LoadList = 0
  Set fp = fso.OpenTextFile(sFileName, ForReading, False)
  If fp.AtEndOfStream Then
    fp.Close
    Exit Function
  End If
  sBuff = fp.ReadAll
  fp.Close

  ' split records and initializes
  vaRec = Split(sBuff, vbCrLf)
  nGood = 0
  sComment = "no description"

  ' loop through records
  For iRec = LBound(vaRec) To UBound(vaRec)
    ' cleanup the record   
    sBuff = Replace(vaRec(iRec), vbTab, " ")
    sBuff = Trim(sBuff)
    vaRec(iRec) = sBuff
    ' if it isn't empty...
    If Len(sBuff) > 0 Then
      ' and it isn't a comment line 
      If Mid(sBuff, 1, 1) <> "#" Then
        ' find the inline comment or first space
        nPos = InStr(1, sBuff, "#")
        If nPos < 1 Then
          nPos = InStr(1, sBuff, " ")
        End If
        If nPos > 0 Then
          ' get the IP, use comment as description
          sIP = Trim(Mid(sBuff, 1, nPos - 1))
          sName = Trim(Mid(sBuff, nPos + 1))
        Else
          ' get the IP, use last comment line as description
          sIP = Trim(sBuff)
          sName = sComment
        End If
        ' is it a wildcarded IP ?
        sIP = CheckIP(sIP)
        If Len(sIP) > 0 Then
          ' update the list
          vaRec(iRec) = sIP & vbTab & sName
          nGood = nGood + 1
        End If          
      Else
        ' comment line, load the comment
        sBuff = Replace(sBuff, "#", " ")
        sComment = Trim(sBuff)
        vaRec(iRec) = ""
     End If
   End If
  Next     
  
  ' all done
  LoadList = nGood
End Function

' Checks the ip and if needed "wildcards" it
Function CheckIP(sIP)
  Dim sTmp, vaOctet
  Dim nDots, iDot

  ' init  
  CheckIP = ""
  If InStr(sIP, ".") < 1 Then
    Exit Function
  End If
  
  ' split the ip octets and check
  ' if we've a full ip, if not we
  ' will need to "wildcard" the IP
  vaOctet = Split(sIP, ".")
  nDots = UBound(vaOctet)
  If nDots <> 3 Then
    ReDim Preserve vaOctet(3)
  End If    
  
  ' add "wildcards" as needed
  For iDot = 0 To 3
    If Len( Trim(vaOctet(iDot)) ) < 1 Then
      vaOctet(iDot) = "*"
    End If
  Next
  
  ' rebuild the IP
  sTmp = Join(vaOctet, ".")

  ' return the "fixed" IP    
  CheckIP = sTmp
End Function
fixed the checkIP didn't take in account IPs like "1.2." sorry again

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Use an "MX sandwich" to reduce spam and load

Post by ^DooM^ » 2010-07-23 15:43

I tided the thread up a bit :) Thanks again for your efforts.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-07-23 15:50

^DooM^ wrote:I tided the thread up a bit :) Thanks again for your efforts.
Nah, nothing to thank for, just some minutes to put together that stuff :) but all in all, I wrote it since I needed it, so, again... no need to thank me for something I wrote for myself :D

evandroamaro
New user
New user
Posts: 20
Joined: 2008-12-22 19:04

Re: Use an "MX sandwich" to reduce spam and load

Post by evandroamaro » 2010-09-07 12:27

Can't download the fakemx app. seems to be a problem at the server hosting it.

User avatar
mattg
Moderator
Moderator
Posts: 19979
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Use an "MX sandwich" to reduce spam and load

Post by mattg » 2010-09-07 15:15

looks like it is going to download for me....Perhaps try again
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2010-09-12 15:40

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

ObiWan
Senior user
Senior user
Posts: 278
Joined: 2010-07-21 14:30
Location: Halfway between Germany and Egypt

Re: Use an "MX sandwich" to reduce spam and load

Post by ObiWan » 2019-03-25 13:49

ObiWan wrote:
2010-07-22 17:53
you will also need a "fake MX" like the one (I wrote it) which can be downloaded here (complete with source code)
In case someone is still interested, the FakeMX URL changed, it can now be found here

Post Reply