iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://web.archive.org/web/20070118121843/https://www.imc.org/ube-relay.html
Allowing Relaying in SMTP: A Series of Surveys
The Wayback Machine - https://web.archive.org/web/20070118121843/http://www.imc.org:80/ube-relay.html
Allowing Relaying in SMTP: A Series of Surveys

prepared by
Paul Hoffman
Internet Mail Consortium

Internet Mail Consortium Report: UBE-RELAY
IMCR-016, Revised August, 2002

Summary

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 been mostly 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 tested a large random sample of SMTP servers in January, 1998 to see how many of them allowed relaying from users not within their realm. IMC repeated the test in July, 1998, July, 1999, January 2001, and August 2002 to show the trends in open relays.

The results show that fewer than 1% of mail servers that are named in mail addresses allowed relaying in August 2002, a very sharp reduction from over 6% from a year and a half earlier. In the same 18 months, the amount of spam a typical Internet users receives has gone up significantly. This shows that the amount of spam is not related to the number of open relays available.

Collecting Test Data

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

For each of the 4421 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 4340 hosts and their respective IP addresses. A random sample of 500 of the remaining 4340 hosts was chosen for the relaying test.

Performing the Test

The test was run on the afternoon of August 20, 2002. 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, "EXAMPLE.COM" was the name of an existing domain associated with IMC (but that is not actually "example.com").

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". 5.4% (27) servers failed to connect.
     
  2. The program gave a EHLO command with the host name given as "mail.EXAMPLE.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:" command. If the MAIL FROM command was rejected, the program terminated and logged "MAIL". One of the tested servers would not accept the MAIL FROM command.
     
  4. The program gave a "RCPT TO:" 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. 90.8% (454) servers gave a 4xx or 5xx response code to this command.
     
  5. The program gave the "DATA" command and sent the following message. 

    To: ron5@EXAMPLE.COM
From: phoffman@EXAMPLE.COM
Subject: Relay survey

Sent from
[name of the host sent to]

This is a repeat of a relaying survey; see
 for more information.
    If the DATA command was rejected or an error was given at the termination of the data, the program terminated and logged "DATA". Only 2 hosts which had given positive responses to the RCPT TO command give 4xx or 5xx responses to the DATA command.
     
  6. The program gave the "QUIT" command and logged "OK". No host gave an error to QUIT. All 3.2% (16) remaining hosts reported a 2xx response code for this command.
     
  7. Some of the hosts sent messages to the address in the "From:" address saying, in many different ways, that the message could not be delivered. 1.4% (7) messages were sent to the "From:" address.
     
  8. An open relay would actually send the message to the address in the "To:" header. Only 2 such messages were received.

Collected results

  January 1998 July 1998 July 1999 January 2001 August 2002
Number of mailing lists 38 50 46 73 62
Total email addresses 6427 8292 9238 13626 10535
Unique mail hosts 2839 3475 3896 5458 4421
Deliverable mail hosts 2813 3433 3844 5330 4340
Failed to connect 5.6% (28) 6.4% (32) 5.0% (25) 7.2% (36) 5.4% (27)
Rejected after RCPT TO: 36.4% (182) 52.0% (260) 71.0% (355) 81.4% (407) 90.8% (454)
Rejected after DATA <1% (2) <1% (4) <1% (3) <1% (1) <1% (2)
Rejected after QUIT <1% (0) <1% (1) <1% (0) <1% (1) <1% (0)
Gave 2xx response to QUIT 57.6% (288) 40.6% (203) 23.2% (116) 11.0% (55) 3.2% (16)
Actually delivered message 51.8% (259) 36.4% (182) 17.6% (88) 6.4% (32) <1% (2)
Sent messages to From: address        4.8% (24) 3.0% (15) 3.8% (19) 3.0% (15) 1.4% (7)

There could be many reasons for the approximately 5% 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.

Most people who are familiar with SMTP, particularly those who worked on the document defining 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. During the last run of this test, over 90% rejected relaying after RCPT TO:, as compared to only 36% doing so when the test was first run.

This IMC Report is IMCR-016 and is named UBE-RELAY. It is an update of IMCR-015, which in turn was an update of IMCR-013, which in turn was an update of IMCR-009, which was in turn an update of IMCR-006. New versions of IMC reports are given new report numbers but the name of the report remains the same. You can get the newest version of this report from the IMC Web site at <http://www.imc.org/ube-relay.html>. A list of available IMC reports can be found at <http://www.imc.org/reports.html>.

The Internet Mail Consortium is an industry trade association for companies participating in the Internet mail market. To give feedback or to get more information on IMC reports, send mail to <mailto:reports@imc.org>. For information on the Internet Mail Consortium, please visit our web site at <http://www.imc.org/>, or call us at +1 (831) 426-9827.