Rejecting Forged Email with Enhanced DNS

David Soble

This article will introduce proposed enhancements to the existing DNS and SMTP protocols that could help prevent email abuse, particularly the problem of forged email. Implementing and widely deploying these enhanced protocols would make it extremely difficult for spammers to successfully deliver mail using forged sender addresses containing domains for which they do not control the DNS records. This would force spammers to send mail from their own domains, making it substantially harder and more expensive for them to hide their true identities and much easier to identify and filter their mail. I am not claiming that my suggestions will completely rid the world of spam, however, used in conjunction with existing filtering technologies, they could dramatically decrease the amount of spam that is received and processed.

Like many systems administrators, I have battled viruses and spam for several years. Viruses represent one of the main network-borne threats for computer users, and spam now contends strongly as one of the top issues for admins. My company has been able to effectively thwart the spread of viruses by aggressively blocking attachments with specific extensions at the email server, and by also running up-to-date antivirus software on the email server and workstations. However, spam is typically harder to automatically identify than viruses, because it comprises the actual content of a message, as opposed to residing in a separately attached file. Also, viruses can be individually identified using known patterns, sometimes called signatures, while spam is more resistant to such clear-cut identification.

The goal of this article is to present a new method for identifying forged email -- whether it be spam, viruses, or other unwanted email -- and reject that mail outright, without analyzing the contents of the message itself. Implementation of this proposal could render most types of unwanted mail undeliverable and force spammers to use valid email addresses and SMTP hosts when sending messages. This solution is accomplished by augmenting DNS with a new resource record called a mail sender, perhaps an "MS Record", which domain owners would define in their DNS zones before sending email. MX records currently must be defined for a domain to receive mail, and MS records could be considered their sending counterparts.

The recent and escalating trend is for spam to originate from a rogue SMTP client or server connected, often temporarily, to the Internet, or to be sent through an open relay. The vast majority of spam is sent using bogus sender addresses. Similarly, several recent viruses, especially those targeting Windows machines, implement their own local SMTP engine on the infected box and send email using bogus sender addresses in an effort to infect other hosts and obscure the origin of the virus. Here is an example of an email header from spam purported to be from a Compuserve address that I received in my Yahoo mailbox (note that Yahoo was able to filter this into my Bulk Mail folder):

X-Apparently-To: [email protected] via 216.136.131.37; \
  Mon, 11 Aug 2003 15:32:18 -0700
X-YahooFilteredBulk: 202.85.159.201
Return-Path: <[email protected]>
Received: from 202.85.159.201 (EHLO ns6.newsbook.net) \
  (202.85.159.201) by mta195.mail.scd.yahoo.com with SMTP; \
  Mon, 11 Aug 2003 15:32:18 -0700
Received: (from apache@localhost) by ns6.newsbook.net \
  (8.11.6/8.11.6) id h7BMJ7I13786; Tue, 12 Aug 2003 06:19:07 +0800
Date: Tue, 12 Aug 2003 06:19:07 +0800
Message-Id: <[email protected]>
To: [email protected],
From: "[email protected]" <[email protected]>
Content-Type: text/html
Subject: what have you been up too ?e53
Content-Length: 441

Here is some information that can be determined from this header:

1. compuserve.net has 3 MX records defined in DNS, and although these records resolve to 13 different IP addresses, they are all on the 149.174.40/24 subnet, which appears to be located in the United States.

2. By querying the APNIC Whois database, we can determine that the IP address of 202.85.159.201 is registered to a company called Newsbook Limited in Hong Kong.

3. ns6.newsbook.net is a registered DNS server for the newsbook.net domain, however, it is not listed as an MX record.

4. 216.136.131.37 is registered to Yahoo and is part of the netblock: NET-216-136-128-0-2.

5. ns6.newsbook.net stamped this message with ID. [email protected] at Tue, 12 Aug 2003 06:19:07 +0800. GMT+8 is the time zone used in Hong Kong.

Using this information, it appears that this spam originated from 202.85.159.201 in Hong Kong with the sender address of [email protected], and was sent to my Yahoo mailbox. However, by reviewing public information, there does not appear to be any relationship between newsbook.net and compuserve.net. In fact, Newsbook's Web site (http://www.newsbook.net/index.htm) states that Newsbook Limited is one of the largest and fastest ISPs in Hong Kong. It seems highly probable that Compuserve does not operate the SMTP server in Hong Kong and that any email sent using compuserve.net sender addresses from that Hong Kong based IP is bogus. It is apparent that the message was sent using a forged sender address. Furthermore, inspection of the To and Subject fields suggest that this message was designed to mask its origin and purpose.

Defining Forged Email

For the purposes of this article, I define forged email as a message that has either a fake sender address (i.e., a non-existent email address), or a real sender address, but the message was not actually sent by the owner of that address. An example of a fake address might look something like the following (note that these are actual FROM addresses used in spam I've received):

A. [email protected] B. [email protected]
C. [email protected]

Example A could be a valid address since hotmail.com exists as a valid domain, but it's unlikely that someone uses that mailbox for general correspondence. Examples B and C are more blatantly fake because the domains don't even exist.

Any real address can be used as the sender in a forged email, and this technique is exploited extensively by spammers and virus writers. One example is spam that is sent with the FROM address forged to be identical to the recipient address. Another instance of exploitation occurs when virus-infected email is sent from a user's mailbox to everyone in that user's addressbook. Often, the FROM addresses of those infected messages are also selected from that user's address book to obscure the real sender.

The point is, when a message is sent using a forged address, the intended recipient's SMTP servers should be able to reject the message outright, without delivering it to any recipient. Perhaps equally important, is the ability to prevent mail servers from accepting such a message for processing once the sender address is determined to be bogus. This would allow servers to swiftly reject bogus emails without the overhead of parsing the message headers or bodies, or checking for keywords or attachments. A bogus sender address would cause the recipient SMTP server to simply drop the connection from the sending server and move on, much like a firewall drops unauthorized packets. The concept of tarpitting could also be used to keep these connections in a wait state to slow the sending attempts of forgers.

Before an SMTP server can reject mail as described above, however, it must be able to determine between forged mail and authentic or permissible mail. It is helpful to define separate categories of mail that could be received. Note the following types of sender addresses:

A. Sender domain doesn't exist.
B. Sender domain exists, but no MX record(s) listed in DNS.
C. Sender domain exists and MX record(s) listed in DNS.

Case A: Sender Domain Doesn't Exist

In Case A, the domain of the sending address does not exist; this can be directly determined by executing a whois lookup on the domain, or indirectly by making certain DNS queries. Public domains require registation with a domain registrar, an official body that requires at least two defined name server (NS) records for every domain. Example addresses B and C (mentioned previously) fall into this category. Because the FROM address is transmitted very early in the SMTP conversation, the recipient server can pause the SMTP conversation while it verifies whether the sending domain exists. If the domain does not exist, the receiving SMTP server can abruptly end the SMTP conversation because the sending address cannot be valid.

Case B: Sender Domain Exists, but No MX Record(s) Are Listed in DNS

Case B means the sending domain exists, but the sender cannot receive Internet email; a DNS MX record must be defined for each domain that can receive email. Generally, mail falling into this case can also be rejected once the recipient SMTP server determines the lack of defined MX records for the sending domain.

There may be cases where you would not want to reject this type of mail. Internal email alerts, for example, might be configured to send from machines that use globally invalid domains because they only email accounts internal to their own infrastructure. For instance, I might want a server to email me if disk usage on that server becomes too high and I might configure the sending address to be globally invalid (e.g., [email protected]) because these emails will only be sent internally.

In this example, companyxyz.com is a valid domain with a valid MX record(s), however, www-companyxyz.com is not a valid domain (i.e., not registered globally). To deal with the emails in Case B that you do want to receive, you could configure the recipient SMTP server to always allow emails from the www-companyxyz.com domain. This would probably be a rare case, but I use it as an example to illustrate that SMTP servers should have controls to override domain validation and accept mail from pre-configured lists of the administrator's choosing.

Generally, for efficiency and simplicity's sake, email servers could be configured to first perform an MX query on the sending domain. For emails falling into either Case A or B, no MX record will be returned and thus the email conversation can be immediately terminated.

Case C: Sender Domain Exists and MX Record(s) Are Listed in DNS

Case C may be the most common, and Example address A ([email protected]) falls into this category. The sending domain, hotmail.com, is a common one and definitely has MX record(s) defined in the DNS hotmail.com zone. So, how can we determine whether [email protected] is a valid or forged address? Email originating from a valid hotmail.com account will always be sent from a valid hotmail.com SMTP server. Therefore, if we can define what constitutes a valid hotmail.com SMTP server, we can safely reject hotmail.com emails from IPs that are not in our list of valid hotmail.com SMTP servers.

Currently, there is no standard mechanism that allows us to list all of the valid IPs authorized to send email for a particular domain. MX records, or mail exchanger resource records, are defined in DNS; however, functionally they are only used to determine where to send email for mailboxes in a domain. For many small organizations, the servers listed as MX records for receiving email may also be used to send email to the Internet. There is no requirement that this setup be used, and many larger organizations use separate groups of sending and receiving servers to maximize efficiency or for other purposes.

For example, by querying DNS we can determine that yahoo.com has 11 MX records defined in DNS, signifying IPs that they control that can accept Internet mail. But, there is no similar procedure for discovering the IPs that yahoo.com uses to send Internet mail. Yahoo may use the same set of MX-listed IPs to send email, or they may use an entirely different set. The only way to know is to analyze email logs showing which IPs were used by Yahoo to deliver legitimate mail. Presumably, the list of sending servers is rather static, much like the list of receiving servers, and therefore this list could and should be defined in DNS.

This setup provides a way to authenticate whether an incoming email was really sent from the domain it claims in the FROM address. Because of this current deficiency with Internet mail, SMTP servers often blindly accept mail from (e.g., yahoo.com) sender addresses regardless of which IP is actually sending the message. For all opponents of forged email, the current situation should not be tolerated and must be improved.

Since most domain owners presumably do not want others impersonating their domain by sending forged mail, it is in domain owners' best interest to publish their sending mail servers' IPs so that mail recipients can validate whether messages really came from the domain owner. For instance, yahoo.com could create a mail sender (MS) resource record in DNS for each sending server. Recipient SMTP servers would then perform an MS lookup on the sending address domain for an incoming email and check whether the sending machine's IP is listed as an MS record for the given domain. If not, the recipient SMTP server could conclude that the message was sent from an unauthorized host and the SMTP conversation could be ended.

If the sending SMTP server is listed as an MS record, the message can be considered valid, at least in that it was sent from the domain it claims. The fact that Yahoo users could still send spam certainly exists, however, that problem can only be addressed internally by the domain in question. It is beyond the scope of this article to address the problem of a forged sending address when the forged address is in the same domain as the real sending server. The exact implementation of MS records would need to be constructed to be resistant to abuse. For example, a domain defining unrealistically large numbers of MS records could be deemed invalid. Furthermore, a reverse MS record could be designed to help verify the authenticity of a sending SMTP server.

Soon after I started thinking about this issue, I realized that others had also been thinking about it and coming up with similar solutions. Andrew Church proposed the use of the MS record in his Internet Draft of February 2002 titled, "Authoritative Mail Sender DNS Resource Record". Similarly, Hadmut Danisch proposed the introduction of an RMX DNS record in his June 2003 Internet Draft titled, "A DNS RR for simple SMTP sender authentication." Also proposed in June 2003 as an Internet Draft is "Designated Mailers Protocol", submitted by Gordon Fecyk. This proposed method uses DNS TXT records to signify whether a host is authorized to send mail on behalf of a domain. These proposals are all very similar and essentially accomplish the same goal, which is to provide a way to tell whether a connecting SMTP host is authorized to send mail for a particular domain.

There are some signs that we are close to formal acceptance of such an anti-spam solution. For instance, the Internet Research Task Force (IRTF) has formed the Anti-Spam Research Group (ASRG) to focus on the problem of unwanted email messages. Also, a proposal conceived in June 2003 called SPF, or Sender Permitted From, is based on the Fecyk and Danisch proposals mentioned previously. This proposal is actively working to get SPF support implemented in four major MTAs (sendmail, postfix, qmail, and exim). One notable feature of SPF is that it does not require any new DNS records to be defined, but instead uses the existing TXT record to store information. Thus, MTAs need to be modified to make and decode those TXT queries.

As far as I can tell, none of the major DNS servers are working towards integrating new resource records for the specific purpose of reducing forged email. The SPF site states that large ISPs have expressed interest in adopting SPF, at least to the extent of publishing SPF records, and the SPF folks are currently working on a draft RFC and code to support their proposal. They sound very ambitious and thorough and perhaps SPF has the best chance of enjoying widespread acceptance.

Conclusion

The existing SMTP protocol does almost nothing to verify the authenticity of the sending SMTP client before accepting mail, and spammers take full advantage of this fact. We cannot control the tools and techniques that spammers use, however, we can severely limit their effectiveness by enhancing these standardized protocols and making it as difficult as possible to send email with bogus sender addresses.

The ability to effectively reject spam is the responsibility of the receiving SMTP server, which is completely reliant on the existing SMTP standards to remain interoperable with other SMTP-speaking computers. The addition of a new mail-sending DNS resource record could be phased into future versions of DNS and lookups made by future versions of SMTP software to provide a framework for globally rejecting forged email.

References

Authoritative Mail Sender DNS Resource Record: http://www.globecom.net/ietf/draft/draft-church-dns-mail-sender-00.html

A DNS RR for simple SMTP sender authentication: http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt

SMTP+SPF: Senders Permitted From: http://spf.pobox.com/

Designated Mailers Protocol: http://www.globecom.net/ietf/draft/draft-fecyk-dsprotocol-03.html

DNS RFCs:

RFC 1034 -- Domain Names: Concepts and Facilities

RFC 1035 -- Domain Names: Implementation and Specification

SMTP RFCs:

RFC 2821 -- Simple Mail Transfer Protocol

RFC 2822 -- Internet Message Format

Tarpitting with various applications: http://sourceforge.net/projects/tarproxy/ http://www.palomine.net/qmail/tarpit.html http://www.impsec.org/linux/security/scanner-tarpit-5.html

David Soble has been a Unix and Windows administrator for about 7 years and works in Boston, Massachusetts, he will soon be transferring to Munich, Germany. He received a B.A. at UMASS Amherst in Philosophy and holds MCSE and SCSA certifications. He enjoys working with Unix, for its flexibility and power, and also likes fiddling with routers, firewalls, and other networking gear.