Legend: new window outside link tools page glossary link
I get a few of this sort of message every month, and you may get them as well. Devoid of any content, they seem pretty mysterious:
Here’s the full and complete packet for this particular message, complete with mail header:
Received: from liturgical.com (126.96.36.199)
by sv2pub.verizon.net (MailPass SMTP server v1.2.0 - 112105154401JY+PrW)
with SMTP id <2-27839-129-27839-50-1-1150715921> for vms045pub.verizon.net;
Mon, 19 Jun 2006 06:18:46 -0500
Date: Mon, 19 Jun 2006 06:18:46 -0500 (CDT)
Date-warning: Date header was inserted by vms045.mailsrvcs.net
We see that the message has no body, no subject line, no to-address field, and only one header line. This is just about the least amount of data you could send to a mail host and still expect it to be successfully delivered to a mail recipient. What’s going on?
What we’re seeing here is in all likelihood a probe message used in the course of a “dictionary attack” (or “MX probe,” or “directory harvest attack”) by a spammer who’s trying to develop a spam mailing list. This message doesn’t offer me hot dates or ask me to buy fake watches; in fact, there’s really nothing for me (as the recipient) to see or do at all. However, the fact that this little non-message has successfully made the trip to my inbox makes it a harbinger of further spam, a sort of stealthy advance scout for the massed forces of unsolicited commercial e-mail.
Whatever you call it dictionary attack, MX probe, or DHA this stuff is a major headache for mail system operators, as well as for their users. Postini estimates that such activity occurs nearly a million times per day, and that the number of failed mail delivery attempts (due to “bad guessing” by probers) can amount to nearly 500 million per day. You might be able to imagine what sort of effect this volume of unwanted data traffic has on the mail hosts of individual ISPs.
I’ll describe MX probing a bit later, but first let’s look at the header of this particular example to trace its origins (hell, you can’t look anywhere but the header in this case).
There’s only one Received line here, indicating that the message was probably sent direct-to-MX (bypassing the normal mail-host transfer chain). It came from a host that identified itself with the HELO name liturgical.com (not a fully-qualified host name, so therefore probably bogus) at the IP address 188.8.131.52 (which appears to be part of a dynamic DSL pool for Croatian Telecom, and which reverse-resolves to the name 83-131-111-97.adsl.net.t-com.hr). It would be a good guess to say that some Croat's PC has been infected with malware that has turned it into an MX probing machine. Apparently, most MX probing is done from such zombie machines by remote control, so as to make it difficult for mail admins to anticipate or stop the attacks.
As we do with most spam, we can safely assume here that the from-address firstname.lastname@example.org is bogus and not worth tracking down.
So, about all we can conclude from this is that the message was sent using direct-to-MX from a DSL pool in or near Zagreb, Croatia, possibly from a zombie.
Suppose you’re a spammer with a bushel of e-mail addresses in, say, the unsuspecting.foo domain. You might have “scraped” some of them from websites and news postings; you may have bought some from another spammer; and, you may even have made many others of them up out of thin air by stringing together common names, words, and numbers. You don’t know how many of them are actually deliverable, and it would be a waste to use even stolen bandwidth to send messages to dead addresses. What to do?
Of course, you can’t just call up the admins at unsuspecting.foo and get them to prune the list for you, but you can do something even better: you can try delivering messages to each of your thousands of addresses. This isn’t nearly as hard as it sounds if you have the right automated tool (i.e., a script or other program that can run repeated SMTP message transfers). This tool will simply connect to one of the unsuspecting.foo mail exchangers (MXs) and will try to transfer an empty message to each address in your list, which can be done pretty efficiently on a fast connection.
Here’s what you might see if you were to spy on such a session with a packet sniffer (note that what the probing host says is in blue, the MX host’s responses are in orange; you can also find more info on SMTP transfers in my page on the topic):
[prober] : [connects to MX host "mx.unsuspsecting.foo"]
[MX host] : 220 mx.unsuspecting.foo ready Thu, 22 Jun 2006 18:10:01 -0500
[prober] : HELO mx-prober.net
[MX host] : 250 mx.unsuspecting.foo
[prober] : MAIL FROM: email@example.com
[MX host] : 250 Sender <firstname.lastname@example.org> OK
[prober] : RCPT TO: email@example.com
[MX host] : 550 5.1.1 unknown or illegal alias: firstname.lastname@example.org
In this case, after signing on and identifying himself (or more likely mis-identifying himself), the prober asks (using the RCPT TO command) to send a message to the address email@example.com. The MX checks and finds out that there’s no such address in its list of users (“unknown or illegal alias”) and ends the attempt with the error code 550. This is useful information for the prober; he now knows that he can knock this address off his list.
He might also get a rejection message containing some other 500-series code; for example, a 552 error code indicates that the address is valid, but is currently undeliverable because the user’s mail queue is full. The prober can decide whether he wants to keep the address (which may someday become deliverable again) or else delete it.
Next, while the session remains open, the prober will try the address firstname.lastname@example.org:
[prober] : RCPT TO: email@example.com
[MX host] : 250 2.1.5 firstname.lastname@example.org OK.
[prober] : DATA
[MX host] : 354 Enter mail, end with a single ".".
[prober] : .
[MX host] : 250 2.5.0 Ok.
[prober] : RCPT TO: email@example.com
[ ... the cycle continues ... ]
Here, the MX finds that live-addy is deliverable, and so notifies the prober using the status code 250. The prober offers to send the message data with the DATA command, and the MX invites the prober (via the 354 status code) to transfer his message. The prober immediately sends the end-of-message mark (a dot on a line by itself), so that there are effectively no message data at all. The MX host doesn’t care about this, and simply returns the 250 response code, indicating that the message was accepted for delivery. The prober then continues with the next address in his list (and so on, and so on, until he is finished or else gets kicked off the mail host).
Probe messages don’t contain much info for us to investigate. Note that the only positive, verifiable information that the prober has provided to the MX for the successful message transfer (to live-addy) is the following:
The MX will take this information and will (as best it can) stitch together a header line, which may be the only one that the recipient will see. Because the message body is blank, there will be none of the customary “To,” “From,” “Subject,” and “Date” fields that we see in a normal message, and of course no message text (in this case, my ISP’s MX host has filled in the blanks by using the MAIL-FROM address as the from-address, and by concocting its own date field based on the time that it received the message from the prober). So, that’s why you see only the puzzling lack of information shown at the top of this page.
MX probing works better with some MX hosts than with others. If the MX has a big workload or serves many individual domains, the probing may not be as effective at identifying non-existent addresses. Note that just because the MX accepts a message for delivery does not mean that it will be deliverable (or that it will be delivered). In many cases, high-volume MX hosts may not be able to check user records and thus may not be able to reject a delivery outright. In such cases, they usually forward the message to another mail host (a mail delivery agent or MDA), which will determine whether the message is deliverable. If it is not, then the MDA will send a bounce message back to the return-path address of the original mailing. The prober, of course, is not using a valid return-path address and so will never see the bounces. This just means that he’ll be carrying addresses on his list that are in fact not deliverable.
Clearly, MX probing is sleazy business. It can turn up a lot of fresh, valid addresses for the spammer, even where the users of such addresses have taken the most extreme measures to keep them out of circulation. Some people consider MX probing to be theft of information (i.e., the information that a particular combination of letters and numbers represents a “live” e-mail address). Excessive probing can also constitute a denial-of-service attack on the MX host, tying up its resources and preventing it from transacting business with legitimate users.
What can you, as an individual mail user, do about MX probing? Not much, really. You won’t know that it has happened until you actually receive a probe message, and by then it’s too late to deal with the problem directly.
What can you do about MX probing if you operate a mail system? Again, not very much. SMTP and its related protocols don’t offer much by themselves that can be of use. Although there are now many proposals on the table for updating or augmenting these protocols to make them more secure against probing and spamming, you can be assured that with all of the big players and competing interests involved in these discussions, most of the cows will have returned to their domiciles before anything will get done. In the meantime, however, there are measures you can take to keep the probing down to a dull roar:
Legend: new window outside link tools page glossary link
|(c) 2003-2006, Richard C. Conner (
08140 hits since March 28 2009
|Updated: Mon, 24 Jul 2006|