1. Tech

Your suggestion is on its way!

An email with a link to:


was emailed to:

Thanks for sharing About.com with others!

Spam - 5

Dateline 10/06/97

456 The SpamSeries

"...on the Internet, it's so easy to complain."

  Sanford Wallace
  Cyber Promotions


Last week we used the tools traceroute, dig and whois to get some information about the spammer.

One of the basic concepts of the Internet is that there is no headquarters. This is due to its history as a military network. The ARPANET, the Internet's predecessor, should allow communication under almost all circumstances. Had there been a single headquarters, vital for the functioning of the whole network any attack on that central nerve that put it out of service would have brought the whole net down and communication would have been impossible.

   For the network to still allow data transfer if parts of it are already down it is essential that the path the data packets take is not determined, only determinable (just like every action we decide to take). Thus, if the direct path from A to B is blocked, but A has a working connection to C and B has a connection to C, data can go from A to C and then from C to B.

   Similarly, it is not sure which servers a message from you (A?) to her (B?) will pass in order to reach its goal. You can connect to the server the final recipient gets her mail from directly. You can, however, decide to use your ISP's mail server (you usually will do that since direct connections can be rather slow). The administrator of this server can decide to use another server as a relay for the domain you want to send mail to. This server in turn can be configured to use another relay, and so on.

Spammers and relays

The SMTP protocol allows for this relaying since it was deemed useful. Unfortunately, this feature can be abused. Spammers can relay through another server to cover their identity.

   As we have seen when we looked at the headers of unsolicited email, every mail server needs to insert the Received line with a time-stamp into the header. In this line also appears from where the server accepted the message, that is the domain name the client stated as an argument to the HELO command. Most SMTP servers will include the IP address into the Received: header line, some will even do a reverse DNS lookup and present the real domain name together with the IP address. This is essential to trace back the source of spam, as we have seen.

   If the server does not include this additional information into the header this is rather unfortunate. We then have hardly a way to find the spammer's ISP other than looking for contact information in the body of the message and doing further investigation. All the spammer has to do is to state a funny (or not-so-funny) domain name and that's it.

   In any case we will remember the domain name of the relaying server and add it to our list of people to contact with our complaint. If the server did put the original sender's IP address in we can tell them how to probably secure their server against being abused as a relay for spam. If all we have is the domain name of the relaying server that's really all we know. The spammer might be a customer of that very ISP or he may just have used it as a relay. We will ask them to please either close their relay or include proper Received: information.

   And then there were (are?) the Cyberpromo relays that would filter the mail through the IEMMC's master removal list (just to make sure not one of the addresses is forgotten) and deliberately not include all the Received: header information. What makes more sense: complaining to Cyberpromo about spam or complaining to the feather forecast about the weather?

Relayed headers

Now what do such headers look like? Voilà:

Received: from gomer.wiscnet.net (dial.wiscnet.net [])
         by betty.globecomm.net (8.8.7/8.8.0) with SMTP id BAA19150;
         Sun, 21 Sep 1997 01:09:59 -0400 (EDT)
Received: from pugsly-s-comput (max1-800-25.earthlink.net [])
         by gomer.wiscnet.net (8.6.9W/) with SMTP id XAA110348;
         Sat, 20 Sep 1997 23:48:11 -0500
Received: from here.com (her-us48c1.here.com [])
         by mail.wiscnet.net (8.9.9/8.8.8/Mx-mnd) with ESMTP id BAA22322;
         Sat, 20 Sep 1997 23:24:40 -0400 (EST)
Received: from email5.com (ema-us49d4.email5.com [])
         by here.com (0.0.0/0.0.0/mx-mnd) with SMTP id GAA11111;
         for ; Sat, 20 Sep 1997 23:24:40 -0400 (EST)

   This spammer was really bored, considering the kind of forgery they did; not bad. Obviously, the first two (remember, we begin from bottom) Received: lines are inserted by the spammer themselves. For the very first line this is clear with an IP address of, a mail server version number of 0.0.0/0.0.0 and a wrong message ID (GAA11111 would have to be sent between 6am and 7am, the time of the message is 23:24:40, however).

   The second header line, however, could (and should I guess) fool us. The IP address isn't much better, but it is better. The program version still looks fancy, but who knows? The message ID is wrong as well if it should resemble sendmail, but it doesn't follow the usual StealthMailer GAA convention. They even put the relay they would use (wiscnet.net) into that header line. The really interesting thing, though, is that the time the message should have been received is the very same as for the first server. Pretty quick.

   The first un-forged Received: line is that of the relay. It identifies itself as gomer.wiscnet.net and has a right message id (XAA) for the given time. As the information about who the client they relayed for really was clearly shows the spammer used a dial-up from earthlink.net and wiscnet.net as a relay. This relay, by the way, is closed now.

   Had the spammer found a relay that did not put all that nice information in the headers the Received: line inserted by the relay would probably have looked like:

Received: from pugsly-s-comput
         by gomer.wiscnet.net (8.6.9W/) with SMTP id XAA110348;
         Sat, 20 Sep 1997 23:48:11 -0500

, which is not too much.

SMTP, Java and me

If you like to stare at "Starting Java..." for several minutes, enjoy slow programs or in general do not like your computer and want to see how SMTP works, now you can. This applet will try to show you how an email looks like that you send directly via the SMTP protocol. It will not send any mail.

   I know, the applet is ugly. But believe me, the code is even uglier. This is just such an extremely procedural process...

Explore Email
By Category
    emailEmailcomputeTechb950eef60f66da3eb50171f32f539d6fb5000d9361090e8fhttp://email.about.comod526F6F741215liveHeinz Tschabitscheremailguide398000v3zNIP11970-01-0110/od/index.htm0526F6F741approved/od
  1. About.com
  2. Tech
  3. Email

©2016 About.com. All rights reserved.