prepared by
Paul Hoffman
Internet Mail Consortium
Internet Mail Consortium Report: UBE-RELAY
IMCR-013, Revised July 5, 1999
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 and July, 1999 to note any trends.
The results show that over 17% of mail servers that are named in mail addresses allowed relaying in July, 1999, a reduction from 36% from a year earlier. While the large drop is encouraging, these numbers show 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.
In the report below, the results of the three tests are shown as groups of numbers, such as { 234, 567, 890 }. The first number is for the first test, run near the end of January, 1998 and the second number is for the second test, run in July, 1998, and the third number is for the third test, run in July, 1999.
IMC's { 38, 50, 46 } mailing lists have a total of { 6427, 8292, 9238 } names. These names represent deliverable addresses at { 2839, 3475, 3896 } unique mail hosts, that is, unique names on the right-hand side of the "@" in the email addresses.
For each of the { 2839, 3475, 3896 } 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, 3433, 3844 } hosts and their respective IP addresses. A random sample of 500 of the remaining { 2813, 3433, 3844 } hosts was chosen for the relaying test.
The test was run on the evening of January 24, 1998, on July 20, 1998, and on July 3, 1999. 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 "abcde.com").
The steps in the test were:
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 or an error was given at the termination of the data, the program terminated and logged "DATA". { 2, 4, 3 } hosts which had given positive responses to the RCPT TO command give 4xx or 5xx responses to the DATA command.
The responses in the main log were:
| Response | Number | Percent |
| CONNECT | { 28, 32, 25 } | { 5.6, 6.4, 5.0 } |
| TO | { 182, 260, 355 } | { 36.4, 52.0, 71.0 } |
| DATA | { 2, 4, 3 } | { 0.4, 0.8, 0.6 } |
| OK | { 288, 203, 116 } | { 57.6, 40.6, 23.2 } |
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.
Of the { 288, 203, 116 } who fully accepted the message, { 259, 182, 88 } actually delivered the message to the recipient. { 24, 15, 19 } of the hosts sent messages to the address in the From: header saying, in many different ways, that the message could not be delivered. In the first two runs, a human postmaster (different in each case) 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.
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.