mailspike

Usage

Using the Reputation Services via public DNS queries is restricted to low volume sites, which shall comply with the following rules:

  • email traffic does not exceed 100,000 messages per day;

  • total volume of DNS queries does not exceed 100,000 queries per day;

Note: If you run a large volume site, please contact us to set up local synchronization using rsync.

DNS Zones

rep.mailspike.net: this zone lists all IP addresses for which currently there is a reliable reputation level assigned. A query for an A record should return one result that will dictate the likelihood of an IP address being used to send spam:

Category / Level Description DNS A Record
L5 Worst possible reputation 127.0.0.10
L4 Very bad reputation 127.0.0.11
L3 Bad reputation 127.0.0.12
L2 Suspicious behavior 127.0.0.13
L1 Neutral - probably spam 127.0.0.14
H0 Neutral 127.0.0.15
H1 Neutral - probably legit 127.0.0.16
H2 Possible legit sender 127.0.0.17
H3 Good Reputation 127.0.0.18
H4 Very good Reputation 127.0.0.19
H5 Excellent Reputation 127.0.0.20

z.mailspike.net: this zone lists all IP addresses seen participating in a distributed spam wave. A query for an A record should always return 127.0.0.2 if the IP address is currently listed. Recommended action: block at MTA level.

bl.mailspike.net: this zone combines both the z.mailspike.net and IP addresses from rep.mailspike.net that are listed between L3 and L5. This combined zone can be used for a single DNS query to determine if messages coming from this IP address should be blocked. The DNS A record is always mapped either to 127.0.0.2 (z.mailspike.net) or the corresponding A record from rep.mailspike.net. Recommended action: block at MTA level.

wl.mailspike.net: this zone lists all IP addresses with good reputation levels between H2 and H5. The listed IP addresses may occasional send spam but since they originate mostly legit traffic, they should not be blocked. This list can be used as a feature when determining if a message should be considered spam or not, but it should never be used exclusively for whitelisting purposes.

SpamAssassin

Apache Foundation' SpamAssassin has the capability of assigning different scores to different rules. Combining this with the mailspike allows greater control on how much weight certain reputation levels should have, instead of having a black or white approach. Sample configuration:

                    ## Spam sources
                    header __RCVD_IN_MSPIKE          eval:check_rbl('mspike-lastexternal', 'bl.mailspike.net.')
                    tflags __RCVD_IN_MSPIKE          net 
                
                    ##### Reputation compensations
                    # Definitions
                    header __RCVD_IN_MSPIKE_Z     eval:check_rbl_sub('mspike-lastexternal', '^127\.0\.0\.2$')
                    describe __RCVD_IN_MSPIKE_Z   Spam wave participant
                    tflags __RCVD_IN_MSPIKE_Z     net 
                    header RCVD_IN_MSPIKE_L5     eval:check_rbl_sub('mspike-lastexternal', '^127\.0\.0\.10$')
                    describe RCVD_IN_MSPIKE_L5   Very bad reputation (-5)
                    tflags RCVD_IN_MSPIKE_L5     net 
                    header RCVD_IN_MSPIKE_L4     eval:check_rbl_sub('mspike-lastexternal', '^127\.0\.0\.11$')
                    describe RCVD_IN_MSPIKE_L4   Bad reputation (-4)
                    tflags RCVD_IN_MSPIKE_L4     net 
                    header RCVD_IN_MSPIKE_L3     eval:check_rbl_sub('mspike-lastexternal', '^127\.0\.0\.12$')
                    describe RCVD_IN_MSPIKE_L3   Low reputation (-3)
                    tflags RCVD_IN_MSPIKE_L3     net
                
                    # *_L and *_Z may overlap each other, so account for that
                    meta __RCVD_IN_MSPIKE_LOW RCVD_IN_MSPIKE_L5 || RCVD_IN_MSPIKE_L4 || RCVD_IN_MSPIKE_L3
                    meta RCVD_IN_MSPIKE_ZBI __RCVD_IN_MSPIKE_Z && !__RCVD_IN_MSPIKE_LOW
                
                    # Scores
                    score RCVD_IN_MSPIKE_ZBI     4.1
                    score RCVD_IN_MSPIKE_L5      4.1
                    score RCVD_IN_MSPIKE_L4      3.5
                    score RCVD_IN_MSPIKE_L3      2.9
                

It there is no need for such granularity, it is also possible to simplify the rules by using instead something like this:

                    header RCVD_IN_MSPIKE_BL eval:check_rbl('mspike-lastexternal', 'bl.mailspike.net.')
                    tflags RCVD_IN_MSPIKE_BL net
                    score RCVD_IN_MSPIKE_BL 3.5
                

Note: Scores in the above examples may (and should) be tweaked to best fit your environment.