Penalties

Top  Previous  Next

AgGw000017

 

If you are using MXRate to tarpit connections based on the senders reputation or country of origin, a tarpit penalty will applied before Alligate responds to the connection request.

 

Initial delay time when tarpitting a connection: xx seconds: This tarpit penalty will be applied before sending the initial 220 "ready" banner back to the sender. This is the most effective place to tarpit the sender. A setting of 30-35 seconds is very effective.

 

Additional tarpit penalties can be applied if the message meets any or all of the following criteria. All penalties are cumulative and the message will be tarpitted before being checked for greylisting. These penalties are applied independently of any other tarpit penalties.

 

HELO is not a fully qualified domain name add: xx seconds: The HELO command is required by RFC to be a fully qualified domain name (FQDN). This is an excellent test to add additional tarpit seconds for if it fails.

 

HELO has no sub level domain (i.e. domain.com instead of mail.domain.com), add xx seconds: Senders are not required to have a sub level domain, however mose legitimate senders do. A low tarpit penalty is appropriate here.

 

Sending host has no REVDNS record (If REVDNS lookup is enabled), add xx seconds: REVDNS is not required, however legitimate servers usually have one. This is not a foolproof test, however it is worthy of a moderate tarpit penalty level.

 

REVDNS lookup times out (If REVDNS lookup is enabled), add xx seconds: This is usually due to the sender not having a REVDNS record or when their authoritative DNS server is many hops away. If the REVDNS lookup times out the odds are pretty high that this is a spammer. There is a caveat here however. If you are running a high volume Alligate server, you may get many more timeouts that low volume servers. This is generally because your DNS server may not be able to handle all the requests efficiently. If your server processes less than 100,000 connections a day, you can feel safe in giving this a higher tarpit penalty. If you are doing 1,000,000 connections a day, you should give this a very low penalty, if any.

 

Sender has ADDRSPACE violations (Improper TO or FROM address formatting), add xx seconds: This is a very good test to use for adding tarpit seconds. It would be highly unusual for a legitimate sender to have improper address formatting.

 

Sender sends lowercase commands (i.e. helo instead of HELO), add xx seconds: This is a very good test to use for adding tarpit seconds. It would be highly unusual for a legitimate sender to use lower case commands. The standard way all known legitimate mail server send commands is all uppercase characters.

 

MXRate spam probability is greater than or equal to xx add xx seconds: This option will tarpit penalty seconds if the MXRate probability score is higher than specified. Virtually all senders that have an MXRate probability score of 50 or higher have some history of sending spam.

 

Sender is from an MXRate suspicious country add xx seconds: If the sender is from a suspicious country but were not tarpitted initially, or were tarpitted but survived, this is another opportunity to tarpit them again. Since all second level tarpit penalties are cumulative, they may eventually give up and go away.

 

Sender address is <> (Null Sender) add xx seconds: This will add tarpit penalty seconds if the sender does not supply a MAIL FROM address.

 

Sender MAIL FROM has no MX record add xx seconds: This will add tarpit penalty seconds if the domain name of the MAIL FROM sender has no MX record. The A record is not checked. RFCs specify that an MX record is not absolutely required, and that if a domain is missing an MX record, the A record should be used. This test is provided on the assumption that properly configured email servers should have an MX record for hosted domains.

 

Sender is not an MXRate Good Sender add xx seconds: If the results of the MXRate lookup for the message indicates the sender is not a known good sender, xx tarpit seconds will be assessed.

 

Maximum tarpit penalty for any tarpitting phase should be limited to xx seconds (0=no limit): Some users may be uncomfortable assessing too many tarpit penalty seconds to any particular connection. On high volume servers with a high percentage of spam email, tarpitting can cause a drain on system resources if connections are tarpitted too long. This option allows you to set the maximum number of seconds any single connection will be tarpitted. We recommend that if you change this option, you do not set it any lower than 35.

 

Block message if total additional tarpit penalties exceed xx seconds (0=no limit): Sometimes messages are so "spammy" that their tarpit penalties become very large. This option allows you to simply terminate the connection if a predetermined tarpit penalty seconds level is reached. We do not recommend that you use this option unless you have a particular reason to do so. It is better to block the connection using the message scanning functions instead.