Direct-to-MX mailing

"Direct-to-MX mailing" refers to a method of e-mail transmission commonly employed by spammers to send their spam with as few relay steps as possible, so as to lessen the chances that such spam runs will be detected and stopped.

Direct-to-MX vs. normal mail transmission

It may help to understand the notion of direct-to-MX mailing if we compare it to the normal transmission process for e-mail. When a normal user sends an e-mail message from a standard mail client (e.g., Microsoft Outlook, Mozilla Thunderbird, or Apple Mail) at his or her home or office, the message is usually passed from the user's computer to an outgoing mail host within the user's domain. This host, sometimes known as an "outgoing MTA" (MTA = mail transfer agent), has the job of figuring out exactly where the message should be sent in order for it to reach the recipient e-mail address provided by the user. This requires the outgoing MTA to make a query to DNS to locate the mail exchanger (MX) hosts that serve the recipient's domain (see also the Wiki page for MX records). This setup makes things much simpler for everyone involved:

• Internet services can upgrade and maintain their incoming mail facilities without requiring their customers to change their addresses. That is, the internet service can deploy new MX hosts, remove old ones, change their names and IP addresses, or even adopt new third-party mail service providers, without disrupting mail service for their users.
• People who want to send e-mail need only know the recipient's address, and do not have to bother with the transmission details themselves. If the work is done properly, then changes to the recipient's mail setup will be completely invisible and not distruptive to sender or recipient.

The problem with this process, at least for the spammer, is that the outgoing MTA can be configured to detect and block large runs of duplicate messages. Furthermore, if the outgoing MTA is a closed relay (meaning that it can only be used by authorized parties, or from authorized IP addresses) then the MTA operator can very easily trace the abuse to a specific individual (and then can suspend accounts or even impose "cleanup charges"). This means that sending spam through such hosts is a very risky proposition.

On the other hand, if the spammer is able to use his own software to identify the MX hosts serving each of the e-mail addresses on his spam list, then he no longer really needs an outside MTA. He can simply send each message directly from his own computer (or one under his control) to the MX host, bypassing any intermediate MTAs. Absent other defenses by internet providers, this greatly improves the effectiveness of the spam run, and also allows a degree of camouflage (since the spam likely won't be detected until it has reached its destinations).

Today, nearly all garden-variety spam is sent direct-to-MX (notable exceptions including "mainsleaze" spam and low-tech scams like chain letters). Because it dispenses with the need to use an MTA, direct-to-MX mailing also allows spammers to send their mailings from any available IP address over which they have control. Sometimes, many such addresses are used, via botnets of infected home or office computers.

Does "direct-to-MX" always mean "spam?"

By itself, "Direct-to-MX" is really a morally-neutral term; the technique can also be used for honest (non-spam) purposes. It is possible, for instance, that an honest user might decide to use this technique, and this does not automatically mean that such a user's mail is abusive. However, it is difficult to imagine a good general reason (other than spam or abuse) for an end-user to go to the trouble of contacting MX hosts directly, when the relaying hosts can do so much more efficiently and with much less suspicion.

• In fact, direct-to-MX is really no longer considered an acceptable practice, or even a tolerable one. Many MX hosts are now programmed to detect attempts at direct-to-MX mailing, and may either reject such mailings or else tag them as spam. Also, many internet services publish information about which hosts within their domains are allowed to send mail (via a mechanism known as Sender Policy Framework), and hosts that don't appear on these lists are likely to have their mail rejected by an MX that subscribes to SPF. So, even well-intentioned users of direct-to-MX mailing must face the possibility that their mail won’t go through, or else it may be reported as spam and their address blacklisted (see "Countermeasures" below).

In the final analysis, it is necessary for the potential spam reporter to weigh the nature of the message (i.e., its content and its "solicited-ness"), along with the measures used to send it, in deciding whether to report it.

Countermeasures against direct-to-MX spamming

On the "recipient side" of the problem, the main defense against direct-to-MX spamming is to identify the IP addresses of the hosts that are perpetrating it, and block or detain messages from these hosts. Internet services can use blocking lists (like SpamCop's own SCBL) to determine whether the hosts that offer them mail are known spam sources. Other types of blocklists can identify what type of host is represented by an IP address, so they can reject or block mailings from machines that don't look like bona-fide mail hosts. The most useful blocking lists (like SCBL) maintain up-to-the-minute information as to which IP addresses are being used to offer spam mail; this permits spam to be accurately rejected or detained even where a spammer may be using a large number of hosts to distribute his mail.

An effective "sender-side" countermeasure against direct-to-MX mailing is to prevent random hosts from sending such mail in the first place; an internet provider can use port blocking (specifically, blocking of outbound traffic on IP port #25 for SMTP service) to stop end-user's computers from being used as direct-to-MX conduits. If done properly, this blocking will not disrupt the normal e-mail activity of the typical home or office user (since these users do not require outside connections on port 25), and may well not even be detectable by the user. Of course, port blocking will not be a final or comprehensive solution to the problem of direct-to-MX mailing unless all providers decide to use it. Also, port-blocking may cause problems for some "roaming users" unless other measures are used to accommodate them (such as virtual private networks or authenticated SMTP).

---

CategoryPagesUnderConstruction
CategorySpamCopGlossaryWikiD

---