Author: kingsmtp

Prepared by:

Paul Hoffman
Internet Mail Consortium

Internet Mail Consortium Report: UBE-RELAY
IMCR-006, February 1, 1998

Summary

Many people working to combat unsolicited bulk email (UBE) believe that restricting the ability of UBE senders to use unrelated SMTP gateways would help reduce the amount of UBE. Companies that have had UBE sent through their SMTP servers have experienced losses in terms of time and money due to the responses they receive.

It’s important to note that relaying messages through an SMTP server is standard practice for users affiliated with that server. However, malicious UBE senders often exploit SMTP relays that they have no connection with, passing the cost of transmission onto others.

It is generally in the best interest of SMTP server administrators to restrict relaying to known users. Many commercial and freeware SMTP servers allow this control, and it is becoming an increasingly essential feature for those purchasing or using SMTP services.

Until now, only anecdotal reports have surfaced regarding the percentage of publicly-known SMTP servers that allow unauthorized relaying. The percentages reported vary widely, and test methodologies were often unspecified. To address this, IMC recently conducted a large-scale test to determine how many SMTP servers allow unauthorized relaying.

Results showed that over 55% of SMTP servers allowed relaying from users not affiliated with the server. This figure is higher than many previous estimates, demonstrating that more work is needed to reduce the number of open relays to the point where UBE senders struggle to find available servers they are not authorized to use.

Collecting Test Data

IMC’s 38 mailing lists consist of 6,427 names, representing deliverable addresses hosted at 2,839 unique mail servers (i.e., unique domains appearing to the right of the “@” symbol in email addresses). For each of these 2,839 mail servers, the lowest-numbered MX (Mail Exchanger) record was identified, followed by the corresponding A record. If no MX record existed, the A record alone was used. In cases where neither an MX nor A record could be found, the mail host was discarded. This left 2,813 valid hosts and their corresponding IP addresses.

A random sample of 500 of these 2,813 hosts was selected for the relay test.

Performing the Test

The test was conducted on the evening of January 24, 1998. Each SMTP command’s response was logged, and the program also recorded how far it progressed in sending a relayed test message. The domain “ABCDE.COM” was used as an existing domain associated with IMC, though it does not correspond to the actual “abcde.com” domain.

The steps of the test were as follows:

1. Connection to Port 25:
   The test program attempted to connect to the IP address associated with each host on port 25. If the connection failed, the program terminated and logged “CONNECT.” A total of 28 servers failed to connect.
2. SMTP Greeting (EHLO/HELO Command):
   After connecting, the program issued an EHLO command using “mail.ABCDE.COM” as the domain of the test machine. If EHLO was rejected, the program tried a HELO command. If both commands were rejected, the program logged “EHLO” and terminated. None of the tested servers rejected the SMTP greeting.
3. MAIL FROM Command:
   The program issued the command “MAIL FROM:phoffman@ABCDE.COM.” If this command was rejected, the program logged “MAIL” and terminated. All tested servers accepted this command.
4. RCPT TO Command:
   The next step was to issue the “RCPT TO:ron@ABCDE.COM” command. Most SMTP servers that block relaying are expected to return an error at this point since the message is not intended for local delivery. A total of 182 servers responded with a 4xx or 5xx error code, indicating that they blocked the relay attempt.
5. DATA Command:
   If the RCPT TO command was accepted, the program issued a “DATA” command and sent the following message:

   To: ron@ABCDE.COM
   From: phoffman@ABCDE.COM
   Subject: Relay test

   Sent from
   [name of the host sent to]
   [timestamp]

If the DATA command was rejected, the program logged “DATA” and terminated. Two servers that had accepted the RCPT TO command returned 4xx or 5xx responses to the DATA command. One rejected the message because it wasn’t local, while the other rejected it due to the absence of a date field in the message.

6. QUIT Command:
   The program issued the “QUIT” command and logged “OK.” All 288 remaining hosts responded with a 2xx success code.

Analyzing the Results

The responses recorded in the test logs are as follows:

Response	Number	Percent
CONNECT	28	5.6%
TO	182	36.4%
DATA	2	0.4%
OK	288	57.6%

Several reasons could explain the 5.6% failure rate to connect. One likely factor is that some hosts on the mailing lists were no longer operational, as some lists had not received messages in several months. Additionally, if higher-numbered MX records had been tried for the hosts that failed to connect, the failure rate could have been lower.

Of the 288 hosts that fully accepted the message, 259 successfully delivered it to the recipient. Twenty-four hosts returned messages to the “From” address, indicating that the message could not be delivered. Additionally, one human postmaster followed up with a manual message stating that relaying would not be tolerated.

Experts in the SMTP protocol generally agree that the proper time to reject a message due to relaying violations is after the RCPT TO command. Indeed, most servers that blocked relaying did so at this stage.

IMC plans to run the test again in the future to track whether more organizations begin to restrict unauthorized relaying. The results from future tests will be incorporated into this report.

This article is based on “Allowing Relaying in SMTP: A Survey” by Paul Hoffman, published by the Internet Mail Consortium (IMCR-006, February 1, 1998).

Link to Web Archive: https://web.archive.org/web/19991106005353/https://www.imc.org/imcr-006.html