The return of the open relays

1997-2003: THE OPEN RELAY ERA

Around 1997, a company named Cyber Promotions (a/k/a Cyberpromo) was the first to start spamming Internet users on a massive scale. Cyberpromo first did this from their own mail servers, relying on their ISP's unwillingness to disconnect them. Within a short time, however, system administrators across the world started blocking email from the IP address ranges used by Cyberpromo.

After pondering on how to continue having their ads delivered, Cyberpromo had a clever but evil idea: send email through mailservers belonging to other companies. At that time, most mailservers on the Internet were open relays: anybody could connect to them from anywhere and send email to anybody. Today this seems absurd, but at that time abuse was rare and equipment failures more common than they are today. System administrators left relays open to ensure that legitimate user traffic could always be sent even if the user's own local server was not functioning.

So, Cyberpromo started sending their advertisements through mailservers that did not belong to them without the owners' permission. They sent many thousands of messages through each server, often saturating the server's Internet connection with junk email and leaving no capacity for that company to send or receive its own email. The administrators of those mailservers and networks had to spend hours to clean up the resulting mess. Cyberpromo constantly changed the abused open relays, making it difficult to block their activity in advance. Some message transfer agent (MTA) software, the software used to run a mailserver, could not be secured against abuse as an open relay without installing an unofficial patch which server admins were reluctant to apply.

Other spammers followed Cyberpromo's example, and open relay hijacking became a favoured spamming method for a few years in the early 2000s. Several people and organizations in the email security field reacted by setting up DNS-based blocklists (DNSBLs) that listed the IP addresses of servers found to be open relays after observation of spam sent through them and subsequent testing. Among those early DNSBLs that listed only IP addresses involved in open relay abuse were the MAPS RSS, ORBL, ORBS, ORBZ, ORDB, and RSL blocklists. Other blocklists that included IP addresses involved in open relay abuse but also other types of abuse included AHBL, DSBL, Five-Ten-SG, NJABL, and SORBS.

At the same time, developers of MTAs changed their code and default configurations to ensure that default installations were closed relays and to make creating an open relay more difficult. A closed relay basically means a mailserver that allows inbound mail only to its own users, and outbound mail only from its own users or others who are authorized to use the mailserver. A mailserver enforces these restrictions for outbound mail either by checking that the connecting IP address is in a trusted list or by requiring some other type of authentication. If somebody tries to send email that doesn't meet the restrictions, the mailserver rejects the email during the initial SMTP dialogue.

As increasing numbers of hijacked open relays were placed on DNSBLs automatically shortly after a spam run started, system administrators were notified that their mail servers were insecure open relays because legitimate emails sent through those servers were also rejected by recipients. The system administrators would upgrade their mailserver software and configurations, stopping spammers from abusing the mailservers, and then request removal of their IP address to the blocklists. The number of active open relays—which grew in number through 2001—stabilized at between 200,000 and 250,000 in 2002, and then began to decline. Spammers moved on to exploit other types of server insecurities such as open proxies and then "bots" (virus infected computers) during 2003. By 2005 or 2006 open relays had ceased to be an important spam vector. The majority of dedicated open relay DNSBLs shut down. The anti-abuse community declared that the open relay problem was solved.

BUT NOW THEY'RE BACK!

In 2012 and 2013, the Spamhaus Project has created about 4,000 SBL records for open relay mail systems. Some spammers in China, Taiwan, Russia, Brazil, Colombia, and other countries use open relays routinely to send spam. Spamhaus does not do any server testing, but discussions with ISPs and system administrators, spam header analysis and knowledge on how specific spammers work bring open relay cases to light with a very low margin of error. ("Error" in these cases normally means that the server was not wide open but the spammer managed to authenticate successfully using a guessed or stolen password, as discussed in a previous news article.)

Despite our efforts, Spamhaus is not catching all open relays. At the very least, 10-20 new open relay systems are found and abused by spammers each day. The problem is not as large now as it was in the past, but it is still significant. Spam coming from real, legitimate mailservers often passes through filters and manages to land into mailboxes. Spam that abuses an open relay still costs the organization owning it time and trouble to clean up the mess. The perhaps premature death of dedicated open relay DNSBLs forces us to spend time and resources to find and manually list open relays in the SBL, and think about what we can do to reduce the number of open relays to a negligible level once more.

WHERE DO THE SECOND GENERATION OF OPEN RELAYS COME FROM?

Most of the new crop of open relays, unlike the old, did not appear because of software bugs or poor default configurations. Some of the new open relays are caused by server administrators who deliberately open up mailserver configurations for testing, during a server relocation, or for some other reason. These system administrators often do this out of blind optimism: they believe that "no spammers attack open relays any more". Unfortunately they're mistaken. Spammers constantly test all mail servers on the Internet for open relays. Most are found within days if not hours!

However, the lion's share of new open relays is caused by insecure configuration, not of the mailserver itself, but of a firewall or an email security appliance. These appliances are placed between the existing mailserver and the Internet. They accept inbound SMTP connections from the Internet, examine traffic, and then pass only the messages that did not trigger spam or malware filters on to the real mailserver. The actual mailserver, which is normally properly configured, is not accessible to external traffic. The mail system is now a combination of two devices that work in close cooperation, and it is the mail system as a whole that should be immune from open relay abuse. What is happening in most cases is that a problem in the configuration of the security appliance causes the whole mail system to be open to relaying.

Remember: a mail system should accept inbound email to its users, outbound email from its users, and should reject all other email that it receives. Otherwise, that mail system is an open relay. If inbound email passes through a security appliance first, and the appliance passes the email and delivers it to the mailserver over a local SMTP connection, the mailserver treats the security appliance IP address, not the actual connecting IP address, as the source IP address for that email. So if that incoming message is directed outside, the mailserver may consider it generated by a local user and let it go out. Voila: the security appliance and mailserver combination functions as an open relay. And—ironically—this open relay issue hits organizations that made an extra effort to secure their mailservers and network! In most cases these organizations find out about this problem only after a spammer abuses their open relay, and they often struggle to understand the nature of the problem.

SCENARIO 1: NAT ON A FIREWALL

Our observations of samples indicate two common scenarios that lead to open relay two-device systems. Following are an example of each scenario, illustrated with spam that was sent by a well known open relay hijacker from China, with domains and IP addresses altered to protect the identities of our spamtraps and spamtrap MX servers, and of the abused open relay.

In the first scenario, the mailserver sees all SMTP connections as coming from an internal IP address because a firewall does a NAT translation at the network boundary, replacing the original IP address with the firewall IP. Email headers of spam sent through such an open relay look like this:

------------------------------------------------------------------------------
Return-Path: <ayumimenziphotocon23@bigpond.com>
Received: from mail.example.net (mail.example.net [203.0.113.243])
	by xxxxxx (Postfix) with ESMTP id xxxxxx
	for <xxxxxx>; Wed, 13 Nov 2013 12:xx:xx +0200 (EET)
Received: from PC-20121219NMRW ([10.0.0.26] RDNS failed) by mail.example.net with Microsoft SMTPSVC(6.0.3790.4675);
	 Wed, 13 Nov 2013 13:xx:xx +0400
Date: Wed, 13 Nov 2013 17:xx:xx +0800
From: "Jeff" <ayumimenziphotocon23@bigpond.com>
To: "xxxxxx" <xxxxxx>
Reply-To: <hamsaksiwiw@inbox.com>
Subject: Photo Retouching Services - Photo Cut Out - Photo Editing
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: base64
Content-Disposition: inline
Message-ID: <xxxxxx@mail.example.net>
------------------------------------------------------------------------------

In this scenario the firewall itself does not speak SMTP, the SMTP connection just goes through it. What happened here is that a machine from some unknown remote IP address (it does not appear in the headers) presented itself in the SMTP HELO as PC-20121219NMRW and connected to the mailserver through the firewall. The firewall changed the source IP address to its own address 10.0.0.26 before passing the email to the mailserver. The mailserver recognized 10.0.0.26 as a local IP address, assumed that the email was from a local sender, and so it sent the email to the spammed email address. The lesson that we learn from this example is that a firewall should never translate the IP addresses of incoming SMTP connections. Another solution, that we recommend to apply only when the previous one is difficult to deploy, is to remove the firewall IP address from the list of local IP addresses in the mail server.

NOTE: NAT translations do not create similar problems over other protocols, such as HTTP or DNS. SMTP is a special case that requires particular caution.