The United States and Europe both agree that junk e-mail is a serious threat to the Internet and that new protocols and methods must be developed to combat it. As antispam laws work their way through the governments of the world, research organizations and individuals continue to work on antispam methods that are compatible with the existing SMTP standard. At the moment, relay block lists (RBLs) are one of the more effective ways to stop spam.
How RBLs work
Most modern UNIX-based SMTP servers (e.g., Sendmail, Postfix, and Qmail) can use RBLs. Those of you who currently use RBLs to block spam, or unsolicited commercial e-mail (UCE), should already know that current RBLs use DNS services. The DNS protocol makes RBL services simple to implement at the application level, which is necessary for wide-scale adoption.
Using an RBL, blocking an incoming SMTP connection is as simple as performing a reverse DNS lookup to an RBL server and getting the proper answer back. If an IP address is on an RBL, the SMTP server responds with a status message indicating a problem, and the SMTP connection is terminated.
But there are problems: RBLs aren't perfect. They can frequently contain inaccurate information or list mail servers that are secure but haven't been properly removed from the RBL.
The bane of e-mail system administrators is to have a relayable SMTP server or open proxy server on their networks because, eventually, it may be found to be insecure and listed on an RBL. Or, it may be discovered by a junk e-mailer, abused, and then listed on an RBL.
Unfortunately, getting your e-mail server listed on an RBL is a lot easier than getting it removed. Most RBLs require multiple steps to delist an e-mail server, which makes it difficult to remove a server that has been secured. And there's nothing more frustrating than having your e-mail server abused by a junk mailer and then finding out—after you've fixed the original problem—that your IP address is listed on one or more RBLs.
Because DNS-based UCE-blocking lists are so successful, they're popular with most ISPs, including EarthLink, AOL, and MSN, all of which make use of commercial, private, and noncommercial "volunteer" RBLs.
RBLs are effective but, as I've said, they're by no means perfect; incorrect listings can and do occur.
RMX: A new DNS resource record
The Anti Spam Research Group (ASRG), which works under the direction of the Internet Research Task Force, an offshoot of the Internet Engineering Task Force, is actively researching proposals to combat UCE. One proposal of particular interest uses DNS in a different way than before. The proposal describes a new DNS resource record (RR) called an RMX record.
An RMX record is a way to identify an IP address or range of IP addresses that are allowed to set the "envelope sender" address of an e-mail message to a particular domain. RMX records are checked on the domain part of the SMTP "MAIL FROM" command. If the connecting IP address isn't listed in the RMX record for the domain, the SMTP server could respond by replying with a diagnostic message and dropping the SMTP connection.
For example, the DNS RR "IN RMX 192.168.100.0/24" in the domain "testrmx.com" implies the SMTP command "MAIL FROM: <firstname.lastname@example.org>" is valid only from this class C. An SMTP server that validated RMX records for connecting hosts wouldn't allow other networks to set the envelope sender address, which would greatly reduce the ability of junk e-mailers to forge e-mail.
The information on the RMX RR is still in draft stage, but this proposal is superior to the two other proposals that the ASRG is considering. Although the RMX DNS record isn't yet a standard, you may want to begin adding the proper RMX records to your DNS zone files; just make sure that lines are commented out for now. BIND and other DNS servers aren't yet aware of RMX records.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.