Allowing Relaying in SMTP: A Survey

prepared by
Paul Hoffman
Internet Mail Consortium

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


Many people in the fight against unsolicited bulk email (UBE) believe that not allowing UBE senders to use SMTP gateways unrelated to their business would reduce the amount of UBE. Further, many companies who have had UBE sent through their SMTP servers have suffered losses in time and money dealing with responses sent to them.

It should be noted that relaying messages through an SMTP server is completely normal for people affiliated with that SMTP server. However, it has become common for malicious UBE senders to use an SMTP relay that they are not associated with, thereby offloading the costs to someone else.

It is often (although not always) in the best interest of the maintainers of an SMTP server to only allow known users to send mail out to the Internet through the SMTP server. Most commercial and freeware SMTP servers allow such control, and this feature is becoming more of a requirement for purchasers.

To date, there have only been anecdotal reports on how many publicly-known SMTP servers allowed anyone to relay through them. Because the reported percentages varied widely, and the test methodologies went unstated, IMC recently tested a large random sample of SMTP servers to see how many of them allowed relaying from users not within their realm.

The results show that over 55% of mail servers that are named in mail addresses allow relaying. This number is much higher than many estimates, and shows that a great deal of work must be done before the number of relays is so low as to make it difficult for a UBE sender to find an available host other than one with which they have a business relationship.

Collecting Test Data

IMC's 38 mailing lists have a total of 6427 names. These names represent deliverable addresses at 2839 unique mail hosts, that is, unique names on the right-hand side of the "@" in the email addresses.

For each of the 2839 mail hosts, the program found the lowest-numbered MX record for the host, then found the A record for that MX record. If no MX record was found, the A record was used. In some cases, no MX or A record could be found, and the host name was discarded. This left a list of 2813 hosts and their respective IP addresses. A random sample of 500 of the remaining 2813 hosts was chosen for the relaying test.

Performing the Test

The test was run on the evening of January 24, 1998. The test program noted responses to each SMTP command in separate logs, as well as keeping a log of how far the program got in sending the relayed test message.

In the following steps, "ABCDE.COM" was the name of an existing domain associated with IMC (but that is not actually "").

The steps in the test were:

  1. The test program attached to port 25 of the IP address in the host's A record. If it could not connect, the program terminated and logged "CONNECT". 28 servers failed to connect.

  2. The program gave a EHLO command with the host name given as "mail.ABCDE.COM", which is the domain name of the test machine. If the EHLO was rejected, the program then sent out a HELO command. If the EHLO or HELO was rejected, the program terminated and logged "EHLO". None of the tested servers would not accept the SMTP greeting.

  3. The program gave a "MAIL FROM:phoffman@ABCDE.COM" command. If the MAIL FROM command was rejected, the program terminated and logged "MAIL". None of the tested servers would not accept the MAIL FROM command.

  4. The program gave a "RCPT TO:ron@ABCDE.COM" command. If the RCPT TO command was rejected, the program terminated and logged "TO". This is the place where most SMTP servers that do not relay are expected to return an error code because it is the first place where the SMTP server can be sure that the message was not meant for local delivery to the system. 182 servers gave a 4xx or 5xx response code to this command.

  5. The program gave the "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]
    If the DATA command was rejected, the program terminated and logged "DATA". 2 hosts which had given positive responses to the RCPT TO command give 4xx or 5xx responses to the DATA command. One rejected the message because it wasn't local, the other rejected the message because it had no date field.

  6. The program gave the "QUIT" command and logged "OK". All 288 remaining hosts reported a 2xx response code for this command.

Analyzing the Results

The responses in the main log were:

Response     Number     Percent    

There could be many reasons for the 5.6 failure rate to connect. The most likely is that the hosts named in the addresses of the mailing lists are no longer around (some of the mailing lists have not had messages sent to them for many months). Also, if the program had tried higher-numbered MX records for the hosts that failed to connect, the percentage of failures would most likely be lower.

Of the 288 who fully accepted the message, 259 actually delivered the message to the recipient. 24 of the hosts sent messages to the address in the From: header saying, in many different ways, that the message could not be delivered. 1 human postmaster also followed the automated message with a message to the addresses in the From: and To: fields saying that relaying would not be tolerated.

Most people who are familiar with SMTP, particularly those working on the document to define exactly what is meant in SMTP, agree that the proper time to reject a message for relaying violations is after receiving the RCPT TO command. This is where the majority of servers that would not relay did, in fact, give the result code that would reject relaying.

In order to track whether more organizations are beginning to disallow relaying, IMC will perform the same test again in the future. This report will be updated with the the results from future runs of the test.

This IMC Report is IMCR-006 and is named UBE-RELAY. The Internet Mail Consortium is an industry trade association for companies participating in the Internet mail market.