Page 69 - Mercury Manual.book

The MercuryS SMTP Server Module
64
Spam control via Realtime Blacklists (RBLs)
On the surface, this blacklist approach sounds like a good way of reducing unwanted mail,
and indeed it can be - but you absolutely must understand two key issues associated with this
type of technique:
1: Blacklist databases will not prevent all spam You should not believe that simply by turning
these functions on, you will prevent spam from reaching your site. These functions may re-
duce the amount of spam you receive, but nothing except co-ordinated global legislation can
eliminate it. We suggest strongly that you visit the CAUCE (Coalition Against UCE) web
pages at http://www.cauce.org for an overview of the positive steps you can take to combat
spam.
2: Blacklists can get it wrong From time to time, using a blacklist definition will inconven-
ience bona fide senders, and will result in legitimate mail not being delivered to your site.
None of the blacklist services currently in existence is an official body - all are ad-hoc and
subject to standard human failings. From time to time, legitimate sites will be affected by
these databases, and legitimate users may sometimes find that actions for which they have no
responsibility at all have resulted in their mail being blocked.
We recommend in the strongest possible terms that you think long and hard before enabling
these controls: they are certainly useful, but they are also dangerous.
Whitelists The same technique used by blacklist query servers could also be used to create
"whitelists" - servers listing machines that are always acceptable. At the time of writing, no
public whitelists exist on the Internet that we know of, but if you control your own local do-
main name server, there is nothing to prevent you from entering addresses in the proper form
within that database then creating a Mercury definition to query it. This approach could be
useful if you need to correspond with a site that has somehow become blacklisted, without
turning off blacklist controls for other sites.
How this process works
The process used to query a blacklist database is simplicity itself. Depending on its configu-
ration, Mercury takes either the physical IP address of the connecting mail client, or the do-
main name portion of the sender's e-mail address; it then reverses and appends this
information to a static domain name you supply and attempts to do a simple domain name
resolution on the resulting string. If the domain name can be resolved, then the address is re-
garded as being blacklisted. The IP address is reversed to conform to the normal standards
for Internet name resolution.
Example: The machine 190.47.32.33 connects to Mercury, which has been config-
ured to use the MAPS RBL blacklist at blackholes.mail-abuse.org. Mercury con-
structs the domain name 33.32.47.190.blackholes.mail-abuse.org and
attempts to resolve it as a domain name.
You can create as many query definitions as you wish: Mercury will action the query defini-
tions in the order they appear in the list in the Spam control page, stopping as soon as a def-
inition results in a positive response from the service. If the responding service is marked as
a whitelist, Mercury will take no further action against the message, allowing it to be proc-
essed normally - otherwise it will apply the action you have defined in the definition. Once a
site has responded, no further definitions in the list are checked. It should be clear that the
order of the definitions in the list can have an important bearing on the way your mail is proc-
essed - you can use the Up and Down buttons underneath the list of definitions to rearrange
the definitions within the list.