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.
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|
|L1||Neutral - probably spam||127.0.0.14|
|H1||Neutral - probably legit||127.0.0.16|
|H2||Possible legit sender||127.0.0.17|
|H4||Very good Reputation||127.0.0.19|
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.
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.