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.
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.
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 "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, 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.
The responses in the main log were:
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.