SPF Technology handles the registration and distribution of the list of allowed IP addresses, which can send out e-mails on behalf of a particular domain. Today, however, spam source filtering is usually handled in the opposite way – lists of IP addresses that are sources of spam and that should be blocked are registered and distributed. Most SMTP servers have such blacklists – either they can be defined by the server administrator, who is forced to manually manage and add to them, or SMTP servers communicate with blacklist servers, which are taken care of either by volunteers, or the provision of a list of spammers’ IP addresses can be based on commercial principle.
The main question is how to distribute such lists of blocked IP addresses, which are often quite extensive. Either the SMTP server can download the entire list, use it and periodically update this list (this mostly applies for commercial blacklists), or the SMTP server could inquire about the specific IP addresses in any blacklist when it is necessary (when receiving a SMTP connection).
We will deal with the last mentioned variant. DNSBL (DNS-based Blackhole List) technology is the most widespread for it. As the name suggests, the presence of an IP address in the blacklist is verified using DNS. There are many servers that offer this service for free and publicly. Just send a specially formulated DNS query and you can find out if they register the given IP address. As an example, let’s take the IP address 1.2.3.4 and use the DNSBL server zen.spamhaus.org. The DNS name we will ask for is compiled by taking the IP address in the reverse order and adding the DNSBL server name after it. And for the name obtained in this way, we make a DNS query for the A record.
4.3.2.1.zen.spamhaus.org
If the IP is recorded, we get one or more A records. We could be pleased with the existence of these A records or we can further analyze their values and find out why this IP address is blacklisted. Special local IP addresses 127.0.0.X are used as values. However, their meaning is not standardized and each DNSBL operator defines them differently.
Here is an example of a request for IP address 88.101.70.219, which is blocked because it is from the ADSL range:
;; QUESTION SECTION: ;219.70.101.88.zen.spamhaus.org. IN A ;; ANSWER SECTION: 219.70.101.88.zen.spamhaus.org. 900 IN A 127.0.0.11
On www.spamhaus.org you can find that their database, named PBL (Policy Block List), contains a list of IP addresses of end-users, who should not be able to send e-mails anywhere without authorization, and thiscorresponds precisely to “return value“ 127.0.0.11.
DNSBL can theoretically be operated using any DNS software and by creating zones in it, containing names, which correspond to the forbidden IP addresses. However, this is not a good solution, because large ranges of IP addresses are often banned, and this can lead to very large and poorly maintianed files. Therefore, special software is used for this, which registers IP addresses better, but externally acts as a DNS server. Of course, DNSBL benefits from the many benefits that DNS brings – it is easy to spread the load, delegate parts of IP address maps to other groups of DNS servers, etc. However, the most significant advantage is that queries to DNSBL servers are, like any other DNS queries, cached. So if our mail server keeps asking for one sender, it should read the result from some local cache and not unnecessarily burden the DNSBL server. On the other hand, this means that if we achieve the removal of our IP address from the blacklist, we will have to wait for the TTL of those A records to expire. E.g. spamhaus.org maintains a TTL value of 30 minutes.
The biggest problem with DNSBL systems is the question of the reliability of the registered lists IP addresses. If someone is truly spamming, they will undoubtedly appear on one or more DNSBL servers soon. Of course, an IP address that is not actually a source of spam may also appear there by mistake. Some DNSBL servers operate on a voluntary basis, where spam IP addresses can even be reported anonymously. Other DNSBLs perform detailed manual investigations before entering the IP address into the list.
Another method of obtaining the identity of spammers and attackers are the so-called Honeypots[12], which are generally computers or systems that look real and are purposely unprotected or otherwise prone to misuse. In fact, they are baits that good users will never use, but attackers do and thus fall into the trap. In our case, it could be a mail server for a domain that has never had and does not have any of its e-mail addresses. If an e-mail still arrives on it, it either means that someone was wrong or that it is a spammer who tries all possible recipients. There are usually more such honeypots, and only after a message from one source arrives at several such nodes is the sender declared a source of spam.
Often, some DNSBLs record entire ranges of IP addresses as a precautionary measure, sometimes without any spam – for example, ranges used to dynamically assign IP to ADSL clients, which are expected to never send e-mails directly, but to use the official SMTP gateway of their ISP. However, a fundamental problem occurs when someone wants to connect their own SMTP server, for example via ADSL, and then finds out that it is blocked everywhere. If someone is blocked, each DNSBL server has procedures for unblocking, but most of the time IPs are not deleted automatically and their deletion must be requested.