Fighting spam: Spam-free guest book
Many a spammer is well-known!
Since it's not just individual persons who are affected by spam, but instead it constitutes a global problem, quite a number of organizations have been founded to take on this problem. The first organization that has been rather successful here has been MAPS (acronym for Mail Abuse Prevention System). Numerous other organizations have arisen in their wake (and some of them have vanished) whose also made fighting spam their priority. The most well-known organization being active today is Spamhaus that has aggregated a massive amount of data on spammers.
This information originally served to protect mail servers against being accessed by particular IP addresses or entire network segments from which spam emanations piled up. However, since spam isn't just distributed via mail or bulletin boards any more, but increasingly also via other means of distribution, these organizations have developed as well and supplemented their databases so that one can determine whether or not a particular domain belongs to a spammer – and if yes, a message thus received can be discarded right away.
to the topPut a lid on it!
Unfortunately far too many guest books, blogs and other means of communication aren't protected adequately against spam, and once you have a spammer in the house, one has a hard time getting rid of him. It is therefore vital to have a look in advance who is intending to publicize what, and if you don't like that information, you can quickly show him the door. The only thing that you have to do is complement the code of your guest book so that it queries the offered blacklists. In case of a hit you can assume that the message is not legitimate and discard it without further consideration.
to the topMode of operation
In order to simplify using blacklists, the organizations offering these lists
are making use of a service designed to resolve domain names to IP addresses
and vice versa: The Domain Name Service.
To othis end Spamhaus & Co. operate their own DNS servers that return a
code when being queried. This code in turn specifies the problem in encoded
form, with a particular meaning assigned to each code. With this code you can
determine if the box in question is an active spam belcher, a hijacked computer
or whatever. You can then decide if you want to lock out all problems or just
certain problem cases.
To make use of a blacklist you need to make it accessible to the script controlling your guest book to begin with, however, under Perl this is done rather easily. You don't have to have that much knowledge about the internals of DNS, but it is entirely sufficient to know which answers from the server have which meaning.
Although DNSBL systems are normally used to secure a mail server against dubious connections, they can be integrated in any means of communication, e. g. guest books, blogs, and forums. The mode of operation is identical in every case.
Behind the scenes
The codes returned by a DNSBL server are, after all, IP addresses from a
specific network segment: IP addresses that are normally assigned to the
loopback device of the operating system, that is, the virtual interface that
addresses the computer itself. Since normally
127.0.0.1 is used here, the address range from
127.0.0.2 through
127.255.255.254 is available for conveying
information.
It is absolutely unnecessary to use all addresses in a DNSBL since there aren't
16.7 million distinct conditions, but there are normally about twenty. That
greatly reduces the effort required for the checks.
To perform a check, the caller constructs a domain name in which the IP address to be checked is encoded and then queries the DNSBL server responsible for these special domains. Depending on whether the domain is recorded on the blacklist the server either returns an IP address further describing the problem or answers with the NXDOMAIN error code. In the former case the process that triggered the check can be aborted or initiate additional checks whether the process can continue. In the latter case there is no information on said address available so it can be assumed that the process can be granted.
to the topIntegrating a blacklist
It is recommended to place the check of a blacklist at a spot as early as
feasible within the script. If it turns out that an IP address is on a DNSBL,
the attempted access to your guest book can be blocked even before any of your
spam countermeasures are contested. Only when this test turns out negative
further checks are required.
The following code snippet takes care of this check:
You also need a module providing a particular function that implements querying DNSBL servers:
This code takes care of checking a DNSBL. When you have enabled the use of
blacklists a query is initially sent to DNSBL servers, and if one scores a hit,
1 (TRUE) is returned, 0
(FALSE) otherwise. If the query fails, the result is
undef. If undef is
returned it is recommended to deny access without any further consequences. The
database is just rolled back to its previous state.
If the query was successful, the outcome solely depends on the result being
either positive or negative: If positive, the address is recorded as being
blocked in the table for IP addresses, maybe with
an increased retention period. The associated message then is simply
discarded.
If negative, further checks are required to determine whether or not the
message is valid.