Controlling SPAM under Mandrake Linux, Part 1
Revision/Modified: Dec 7, 2001
Author: Vincent Danen		
Dealing with SPAM is a complex topic as there are a number of different solutions, all with varying degrees of success, and all with different pros and cons. Unfortunately, there doesn't yet seem to be the perfect solution to dealing with SPAM, just a solution that works best for you.
We will try to describe a few different methods of dealing with SPAM, from server-side configurations to client-side configurations. We will attempt to provide solutions for both postfix and qmail for the simple reason that postfix is the default MTA for Mandrake Linux and that qmail is my preferred MTA for Mandrake Linux. For those still using sendmail, you should be able to adapt the policies for postfix to sendmail with a little extra work (or possibly not).
Prevention Methods
There are a few "classes" of prevention methods for dealing with SPAM. SPAM, which is the common name for junk mail, unsolicited bulk email (UBE) or unsolicited commercial email (UCE), is an evolving science for those who utilize it. Individuals inappropriately harvest, sell, and use email addresses for a variety of reasons: sending out messages about their latest product, the latest get rich scheme, the religion of the week, new porn sites, and so forth. To most end users, SPAM is a horrid experience that detracts from the usability of email, and makes people attempt to guard their email addresses as much as possible. Nothing wrong with guarding your address, but it does tend to make life difficult. These individuals (spammers) have wrecked something that is beneficial and useful for everyone. There are a few techniques that have had various levels of success in dealing with SPAM, however.
The methods of dealing with SPAM typically fall into two categories: pro-active and reactive. Pro-active means that junk mail is blocked before it is received, and reactive means getting rid of the junk mail after it is received, but before it is delivered to the end user to read. Additional controls can be in place that can be used to identify messages as SPAM (advisory controls) or blocking the delivery of mail (mandatory controls).
Unfortunately, while the mandatory control might be preferred, it is sometimes not as desirable due to the fact that some programs may incorrectly classify a message as junk mail. With a mandatory control in place, you may not get legitimate email. To this end, mandatory controls should be very carefully implemented if you intend to use them, or users should be given the choice as to whether or not they will be used for their account.
Securing the Server
There are a few means you can use to implement a safer server environment by rejecting mails that are known to come from spammers or from open relays used by spammers. For this reason the Realtime Blackhole List (RBL) was created. The theory behind it is to allow an SMTP server to look up, via DNS, a database of known spammers/open relays and reject mail or incoming connections if the sender's IP address is located in the list. A number of RBL services are available that can be used:
•	Open Relay Database, which is available via DNS at relays.ordb.org. 
•	Open Relay Blackhole Zones, which is available via DNS at inputs.orbz.org and outputs.orbz.org. ORBZ does not recommend using the outputs list for system-level blocking as it is much more aggressive. 
•	Mail Abuse Prevention System (aka MAPS), which is a commercial RBL service. 
If you use the qmail MTA, you can use the rblsmtpd program which is part of the ucspi-tcp package. You will need to change the default /var/qmail/supervise/qmail-smtpd/run file from:
#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
exec /usr/bin/softlimit -m 2000000 \
/usr/bin/tcpserver -v -p -x /etc/tcprules.d/qmail-smtp.cdb \
-u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd 2>&1
to:
#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
exec /usr/bin/softlimit -m 2000000 \
/usr/bin/tcpserver -v -p -x /etc/tcprules.d/qmail-smtp.cdb \
-u $QMAILDUID -g $NOFILESGID 0 smtp /usr/bin/rblsmtpd \
-r relays.ordb.org \
-r inputs.orbz.org \
/var/qmail/bin/qmail-smtpd 2>&1
This tells qmail to invoke rblsmtpd prior to qmail-smtpd to make sure that the server sending the message isn't in one of the RBL databases. By default, qmail does not do any RBL lookups.
If you're using postfix as your MTA, you need to modify /etc/postfix/main.cf. To enable postfix to use the RBL, you must have the following commands included:
maps_rbl_domains = relays.ordb.org, inputs.orbz.org
smtpd_recipient_restrictions = reject_unknown_client, permit_mynetworks. \
  reject_maps_rbl, check_relay_domains
smtpd_client_restrictions = reject_unknown_client, reject_maps_rbl
(Note that the smtpd_recipient_restrictions line is actually one long line, but formatted so as to make it easier reading for our smaller screen-size friends.)
The maps_rbl_domains keyword defines the RBL domains to use. By default, postfix does not do any RBL lookups. Likewise, recipient and client restrictions use their defaults in Mandrake Linux and are not explicitly specified. The default value of smtpd_recipient_restrictions is "permit_mynetworks, check_relay_domains", which tells postfix to permit if the client address matches $mynetworks and permit only mail to destinations that match $inet_interfaces, $mydestination, or $virtual_maps; from trusted clients matching $relay_domains or a subdomain thereof; from untrusted clients to destinations matching $relay_domains or a subdomain thereof.
The above example smtpd_recipient_restrictions will first check if the client hostname is unknown and if it is, reject it. We then use permit_mynetworks, like postfix does by default, then we check the RBL with reject_maps_rbl, then we use check_relay_domains as the last entry (check_relay_domains should always be the last entry).
Finally, we also specify smtpd_client_restrictions here because the default postfix action is to allow connections from any host. In order for RBL to work properly, we need to also use the reject_maps_rbl restriction here. For added security, we also use reject_unknown_client.
You can obtain more examples and restriction types by perusing the /usr/share/doc/postfix-*/sample/sample-smtpd.cf file.
To test to make sure you have RBL setup correctly, you can use telnet to connect to the SMTP server. ORDB and ORBZ both list 127.0.0.2 as a bad IP; since it is a local address, it is only meaningful in a test situation.
If you're running qmail, you may see something like this scenario:
$ telnet 127.0.0.2 25
Trying 127.0.0.2...
Connected to 127.0.0.2.
Escape character is '^]'.
220 rblsmtpd.local
mail from:<me>
250 rblsmtpd.local
rcpt to:<me>
451 Blocked by ORDB - for testing purposes only
quit
221 rblsmtpd.local
Connection closed by foreign host.
$
With postfix, you may see something like this scenario:
$ telnet 127.0.0.2 25
Trying 127.0.0.2...
Connected to 127.0.0.2.
Escape character is '^]'.
220 test.mydomain.org ESMTP Postfix (Release-20010228) (Linux-Mandrake)
mail from:<me>
250 Ok
rcpt to:<me>
554 Service unavailable; [127.0.0.2] blocked using relays.ordb.org, reason: \
  Blocked by ORDB - for testing purposes only
quit
221 Bye
Connection closed by foreign host.
$
Doing the same thing but telneting to 127.0.0.1 will result in no rejection caused by RBL lookups. (Note that the above text in bold is text that you type in.)
While using RBL is not the be-all and end-all solution, it will prevent some SPAM from making it's way into the system.
Read on for Part 2 which discusses some client-side solutions for dealing with SPAM.