Spam Filtering @ Monkeys.Com Standard distributions of the Postfix mail server provide a broad array of capabilities for filtering incoming e-mail. Most of these capabilities are listed below. Note that we ourselves do not use all of these filtering capabilities. (See below.) Right out of the box, Postfix can be configured to reject incoming e-mail messages that come from some SMTP client whose IP address has missing or invalid inverse DNS whose IP address is listed in a local IP address blocking list whose IP address is listed in some DNS based IP address blocking list (such as the MAPS RBL) whose inverse DNS indicates that it is within some domain listed in a local SMTP client domain blocking list that fails to start the SMTP session with HELO or EHLO that fails to supply any domain name in the initial HELO or EHLO command (may violate RFCs in a very minor way) that fails to supply a syntactically valid HELO/EHLO domain name that fails to supply a fully qualified (i.e. containing at least one period) HELO/EHLO domain name that fails to supply a DNS resolvable HELO/EHLO domain name that supplies a HELO/EHLO domain name that is listed in a local HELO/EHLO domain name blocking list that supplies a MAIL FROM or RCPT TO parameter that fails to conform to RFC 821 syntax requirements (e.g. missing outer <>) that supplies a MAIL FROM or RCPT TO parameter that fails to include an @domain part (?done implicitly by Postfix?) that supplies a MAIL FROM or RCPT TO parameter whose domain part is syntactically invalid (?done implicitly by Postfix?) that supplies a MAIL FROM parameter whose domain part is not fully qualified (i.e. containing at least one period) that supplies a MAIL FROM parameter whose domain part is not DNS resolvable (to either an A record or an MX record) that supplies a MAIL FROM parameter whose domain part is listed in a local MAIL FROM domain name blocking list that supplies a MAIL FROM parameter whose complete e-mail address part (i.e. everything except the outer <>'s) is listed in a local MAIL FROM e-mail address blocking list Here at Monkeys.Com, we use almost all of these Postfix filtering capabilities in our efforts to filter out spam, and we have also hacked into the Postfix source code to create one additional filtering capability that we also use and that has proven to be quite useful and also highly accurate in blocking incoming e-mail spam. As noted above, Postfix includes support for filtering against both local (file based) and non-local (DNS based) filtering lists. List-based filtering can be applied to (a) the IP address of the SMTP client and/or (b) the inverse DNS name of the SMTP client and/or (c) the domain name given by the SMTP client in its HELO/EHLO command and/or (d) the domain name part of the argument of each MAIL FROM command issued the SMTP client. We here use all of these list-based filtering capabilities. We make use of DNS based IP address blocking lists maintained elsewhere, our own local DNS based IP address blocking list(s), and also our own local (file based) IP address and domain name blocking lists. (See our list of blocking lists for more details.) As mentioned earlier, we avoid using a few of the types of filtering that Postfix provides (and that are listed above) because experience has shown that they are counterproductive, i.e. causing too many rejections of legitimate non-spam incoming e-mails. Specifically, we do not reject incoming e-mail if the inverse DNS name associated with the IP address of the current SMTP client is either undefined or syntactically invalid or if it fails to have a corresponding forward DNS resolution, either one that maps to the exact same client IP address, or otherwise. We would like to be able to apply this sort of filtering, but it is clear that there are still vast numbers of mail servers out there for which inverse DNS has not been properly configured (or configured at all, in many cases). Also, we find that with the combination of other filters we have in place, we are still able to reject the vast majority of all incoming spam even without being too fussy about the inverse DNS of SMTP mail clients that connect to our mail server. (Maintaining our own local domain name and IP address blocking lists well enough to achieve this requires a lot of work however.) We do reject incoming e-mail from SMTP clients that fail to issue HELO or EHLO commands at the beginning of their SMTP sessions (although this case never seems to actually arise in practice) and we reject mail if the parameter that the client supplies for the HELO/EHLO parameter is either missing or syntactically invalid as a domain name (two more cases that don't actually ever seem to arise in practice) or if the HELO/EHLO parameter is not a fully qualified domain name. (This last case does arise from time to time, although rarely, and usually only when direct from dial-up spammers are connecting to our mail server with some broken piece of spamware or else when some badly mis-configured foreign/overseas open relay mail server is being hijacked to send spam to us here.) Note that we do not reject incoming e-mail from clients that supply a HELO/EHLO parameter that cannot be resolved using a forward DNS lookup (either to the client's own IP address or to any IP address) because, as we have already noted, there are just too many legitimate sites on the Internet that have badly mis-configured DNS, and we have found that filtering based on proper HELO/EHLO parameter resolution produces too many false positives (i.e. rejections of legitimate incoming e-mails). For completeness here we should also mention that we do rejecting incoming e-mails if the @domain part of the MAIL FROM parameter issued by the SMTP client is either missing, or syntactically invalid, or if it fails to resolve to at least one DNS MX record or to at least one DNS A record. In effect, this is just a basic and minimal test to see if in theory we should be able to send mail back to whoever is sending mail to us. (In practice, the @domain part of the MAIL FROM parameter may resolve properly to some MX or A record, but the MX server name may perhaps not resolve to anything, or else it or the A record may point to an IP address that has no actual server machine connected to it, or to an IP address that does have a mail server running on it, but one where incoming SMTP has been disabled or switched off. Even if none of these cases applies, the sender may perhaps be filtering and rejecting incoming mail from us! There is no completely accurate way of checking to see that we can really send mail back to an e-mail address specified in a MAIL FROM except to actually try to send mail to that address. So our limited checking of the domain name parts of MAIL FROM parameters is just that... minimal checking. Still, this checking blocks a lot of spam, so we are happy to use it. And anyway, we apply quite a lot of additional list-based checks to the MAIL FROM parameter, and these, together with all of our other filtering, seems to catch the vast majority of all of the incoming spam that gets past our minimal MAIL FROM domain part DNS resolution test.)