Setting System-Level Controls

---

System-level spam controls can be mandatory or advisory and proactive or reactive. They afford the mail administrator broad powers and a wide range of options, but mandatory system-level controls take control away from the user. Because no spam control method can guarantee that only spam will be blocked, mandatory system-level controls will likely result in the rejection of some valid messages. Not all users are willing to risk losing important messages—business offers, for example—in the effort to block junk mail.

Proactive controls must be implemented at the level of tcpserver or qmail-smtpd, so they're usually only implemented at the system level. It would be possible for qmail-smtpd to check a per-user configuration file before accepting mail to a user, but this is not currently implemented in qmail or available as a patch.

Most system-level controls are mandatory "out of the box." Converting them to advisory will require modification or additional tools or scripts.

System-level spam controls use the following methods to detect probable junk mail:

• Envelope sender is a known spammer.

• Remote host is a known spammer.

• Envelope sender's domain is invalid.

• Remote host is a dial-up client.

• Remote host's Internet Protocol (IP) address doesn't match the value returned by the Domain Name System (DNS).

• From header field domain is invalid.

• Excessive number of envelope recipients.

Of course, many of these can result from user error or misconfiguration, as well as attempts to send junk mail.

In addition to flagging or bouncing probable junk mail, a technique known as tarpitting or teergrubing (teergrube is German for tar pit) is sometimes employed. When a teergrubing SMTP daemon decides that it's talking to a junk mailer, it intentionally delays its responses. The goal is to slow down the spammers and force them to waste their resources on the foot-dragging site. Of course, it also forces the teergrubing site to waste some of their resources, and its effectiveness is debatable.

Using badmailfrom

The only spam control included in qmail proper is the badmailfrom control file used by qmail-smtpd. If badmailfrom exists, qmail-smtpd checks the value supplied by the remote host in a MAIL command. If the value is supplied, the envelope sender, or the domain part of the envelope sender, is listed in the file, then qmail-smtpd will reject the message with a permanent error.

Unfortunately, this is of limited utility. Once blocking messages from known spammers became widespread, the spammers reacted by using randomly generated usernames and domain names. The good guys countered by verifying the domain names, which forced the bad guys to use valid domains—somebody else's, like hotmail.com or aol.com. Spammers also tend to use envelope sender addresses that differ from the From header field, which hides the bogus addresses. badmailfrom does not match against From fields.

For example, a mail administrator notices that he's receiving junk mail from junk.example.net, so he adds that to badmailfrom and conducts a quick test:

 # echo "@junk.example.net" > /var/qmail/control/badmailfrom # telnet 0 25 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. 220 dolphin.example.com ESMTP helo dude 250 dolphin.example.com mail from:<[e-mail]> 250 ok rcpt to:<[e-mail]> 553 sorry, your envelope sender is in my badmailfrom list (#5.7.1) quit 221 dolphin.example.com Connection closed by foreign host. # 

The line starting with 553 sorry. . . shows qmail-smtpd refusing to accept the message.

Using rblsmtpd

Early in the war on spam, the warriors were faced with the problem of distributing databases of known junk mailers and sympathizers. Because the items in the databases were IP addresses, the DNS was a logical choice. Thus was born the notion of the Realtime Blackhole List (RBL). A network service—particularly an SMTP service—could look up the IP address of a remote host requesting a connection, and if one of the DNS "bad guy" databases had the address listed, the service could refuse the connection.

Dan Bernstein wrote rblsmtpd, a simple SMTP server wrapper that can be used with any SMTP server that can be run from tcpserver, including qmail-smtpd, of course. Originally distributed separately, rblsmtpd is now part of the ucspi-tcp package (see Appendix B, "Related Packages").

There are many DNS blacklists available:

• The Open Relay DataBase (http://www.ordb.org/). DNS server is relays.ordb.org.

• Open Relay Black List (http://www.orbl.org/). DNS server is or.orbl.org.

• Open Relay Blackhole Zones (http://www.orbz.org/). DNS servers are inputs.orbz.org and outputs.orbz.org. The outputs list is more aggressive and isn't recommended by ORBZ for system-level blocking.

• Commercial services provided by the Mail Abuse Prevention System (MAPS, "spam" spelled backwards). Further information is available from http://mail-abuse.org/.

Configuring rblsmtpd

To enable rblsmtpd, insert the rblsmtpd command in the tcpserver command in the /var/qmail/supervise/qmail-smtpd/run script. For example, to have rblsmtpd check connecting hosts against the ORDB and ORBZ lists, you would change this command:

 exec /usr/local/bin/softlimit -m 2000000 \     /usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c 5\          -u $QMAILDUID -g $NOFILESGID 0 smtp qmail-smtpd 2>&1 

to this:

 exec /usr/local/bin/softlimit -m 2000000 \     /usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c 5\          -u $QMAILDUID -g $NOFILESGID 0 smtp rblsmtpd \              -r relays.ordb.org \              -r inputs.orbz.org \                  qmail-smtpd 2>&1 

Next, tell supervise to terminate the qmail-smtpd service and automatically restart it with the modified run script:

 # svc -t /service/qmail-smtpd # 

Testing rblsmtpd

For testing purposes, the address 127.0.0.2 is listed in the ORDB and ORBZ lists. Because all IP addresses starting with 127 refer to the local host, this allows one to telnet to the local host via one of these test addresses to verify that rblsmtpd is working.

For example, connecting to 127.0.0.1, which is not listed in these databases, will result in a dialogue with qmail-smtpd:

 $ telnet 127.0.0.1 25 Trying 127.0.0.1. . . Connected to 127.0.0.1. Escape character is '^]'. 220 dolphin.example.com ESMTP quit 221 dolphin.example.com Connection closed by foreign host. $ 

The SMTP greeting, 220 dolphin.example.com ESMTP, shows that qmail-smtpd is running, which only happens if rblsmtpd doesn't find the "remote" host in an open-relay database.

The same test to 127.0.0.2 with rblsmtpd configured results in the following dialogue:

 $ telnet 127.0.0.2 25 Trying 127.0.0.2. . . Connected to 127.0.0.2. Escape character is '^]'. 220 rblsmtpd.local quit 221 rblsmtpd.local Connection closed by foreign host. $ 

Now the SMTP greeting is 220 rblsmtpd.local, indicating that rblsmtpd found 127.0.0.2 in an open-relay database and has intercepted the SMTP session.

Expanding the dialogue to include MAIL and RCPT commands will show which list the address was found in and the type of response that a blackholed host would receive:

 $ 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. $ 

The response starting with 451 Blocked by ORDB indicates that the remote host was listed in the ORDB list.

---