We block mail mainly based on the source hostname, the source IP address or the envelope sender address.
We also do a small amount of content blocking, mostly some crude header checks.
Source IP address blocking is done both from the access list we maintain ourselves, and from some DNS based blocking lists. A few sources are blocked at the packet filter level.
The DNS based lists we currently use are ordb to block open relays, the combined sbl and xbl lists for blocking open proxies, professional spammers and other frequent sources of spam, and the SpamCop blocking list for rapid reaction to new spam sources.
We monitor these lists, and from time to time we whitelist sites where we consider the blocking to be overly broad, or where there is a strong enough local interest in mail from a site for us to be willing to risk the spam.
In our experience, the number of cases where we have chosen to whitelist has been quite small, although non-zero.
Access list blocking of IP addresses is used as a response to spam or other abusive mail received, and to abuse that is recognizable from logs. The latter are often
When we choose to block, we may block a range of addresses if there is reason to suspect that the abuser could have access to other addresses in that range. If the source of abuse has a hostname that suggests the use of dynamic IPs, or suggests an end user on a cable or DSL network, we may choose to block the whole "/24" range (256 addresses). In most of these cases, a blocked sender has the alternative of sending through their ISP server. If there is no reverse DNS for the particular IP address, then we treat it as if the hostname suggested a dynamic IP.
IP packet filtering is only used for particularly flagrant cases of abuse, such as
Where feasible, we block by hostname instead of by IP, or in some cases in addition to blocking by IP.
In the case of direct marketing spam we may do both. We block by IP, because the direct marketers often have other hostnames they can switch to. And we block by hostname or domainname, because they sometimes move operations to a different network.
In the case of abuse from direct to MX mail from end user networks (often DSL or cable) we prefer to block by hostname. This is only possible where the ISP has a clear naming convention that would distinguish between these end user systems and the main SMTP servers of the ISP. We prefer not to block the main servers of reputable ISPs.
Our preference for hostname blocking, in this case, is in the hope that reputable small organizations will be able to avoid inclusion in the block by setting up proper reverse DNS for their range of IP addresses.
We follow the standard policy of blocking mail from non-existent sender domains, and of temp-failing mail from sender domains with temporary DNS problems.
We will block sender domains if they retry at too high a rate when they are having temporary DNS failures on their domain. An organization can best avoid this by keeping their DNS in order, and by not retrying messages at too high a rate.
We block on a sender domain when that is a clear indicator of a spam source. We also block a few sender addresses that are clear indicators of virus generated email.
We use the rfc-ignorant DNS list to block sites which refuse to accept DSNs (delivery status notifications).
If we receive abuse from the mail server of a major ISP, we prefer to block on the sender address where that is possible. Note, however, that we will block a major ISP if that becomes necessary to protect ourselves from an ongoing problem.
At present, our content based blocking at present is entirely based on header checks.
We reject probable virus/worm mail. The header checks are crude and may have false positives. We review what we are checking from time to time. The amount of mail rejected in this way is quite small, and in most cases there is good evidence to suggest that the rejections was appropriate.
We reject bad "Message-ID:" headers. We do not insist that a Message-ID be present. But if one is present, we expect it to meet the requirements of RFC 822, RFC 2822. This accounts for the majority of our rejections based on header checks, although still less than 1% of messages handled. The two most common problems we see are
We reject mail with no proper "From:" header. If the envelope sender is a proper address, we bypass this check, since the envelope sender can substitute as a suitable address. The amount of mail rejected by this test is small (considerably less than one message per day). This test is intended to discourage spammers from using "<>" as an envelope sender and failing to provide a proper "From:" header. From the logs of our rejections, it appears that there is some email software that sends non-delivery notifications with "<>" on the "From:" header. On our reading of the standards, this is not permitted and a proper "From:" header should be present. The standards, as we read them, only allow "<>" in the envelope sender and Return-Path.