Sunday, November 30, 2003

How to file a complaint

Normally I just filter and delete the spam but I've received a particularly distasteful one (Brazilian kiddie porn) which I'm going to file a complaint about. You can follow along as I whine to customer support about a message entitled "joat, welcome to Ped0Wor1d ayuGYoaf".

First, we need to take a look at the message header. Other than changing my account name (to block account scrapers), the header is as-is from the message.


Return-Path: 
Received: from pop.east.cox.net by localhost with POP3 (fetchmail-6.2.1)
    for joat@localhost (single-drop); Sun, 30 Nov 2003 08:43:06 -0500 (EST)
Received: from compuserve.com ([12.229.105.222]) by lakemtai06.cox.net
  (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id
for
; Sat, 29 Nov 2003 21:32:16 -0500
Date: Sun, 30 Nov 2003 03:31:53 +0000
From: mrg@simplewire.com
Subject: joat, welcome to Ped0Wor1d ayuGYoaf
To: joat
References:
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=2.1 required=3.0
tests=BIG_FONT,CTYPE_JUST_HTML,HTML_FONT_COLOR_BLUE,
HTML_FONT_COLOR_MAGENTA,HTML_FONT_COLOR_NAME,IN_REP_TO,
NO_REAL_NAME,REFERENCES,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL version=2.44
X-Spam-Level: **
X-Spambayes-Classification: ham; 0.07

Notice the two "Received:" lines.


Received: from pop.east.cox.net by localhost with POP3 (fetchmail-6.2.1)
    for joat@localhost (single-drop); Sun, 30 Nov 2003 08:43:06 -0500 (EST)
Received: from compuserve.com ([12.229.105.222]) by lakemtai06.cox.net
  (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id
for
; Sat, 29 Nov 2003 21:32:16 -0500

Unless one or more of them have been badly forged, "Received;" lines are normally in reverse chronological order. When backtracing spam, you work in the same order, verifying each line until you reach the line that doesn't "read" correctly. Since there are only two lines in this instance, it is very easy to trace this one back to its source.

The first "Received:" line is a normal entry, generated by my instance of fetchmail.

Right away, the second line has an error in it that sticks out: it's not from the domain that claims to be (CompuServe). Rather, Cox's mail server recorded an IP of 12.229.105.222 as making the connection. It's also significant that the "Return-Path:" address is also not CompuServe.

Finally, the lack of any other "Received:" line is also significant. Normally you would have a client-to-server entry followed by a server-to-Cox-server entry to show that the mail was generated by a mail client and uploaded to the sender's mail server before that server "talked" to Cox. (Too confusing?)

What this means is that a program connected directly to Cox's mail server to generate the mail. In other words, a non-MTA program connected to port 25 on Cox's mail server and "typed the message directly onto the server". This is a technique that system administrators use in troubleshooting mail delivery. Anyone know of spammer programs that use mail lists, do MX lookups, and connect directly to the applicable mail servers?

Anyways, we can still trust most of the second line. Except for "from compuserve.com", the line is generated by the Cox mail server. The IP address is significant in that a reverse lookup reveals that it's an ATT IP address:

$ nslookup 12.229.105.222
222.105.229.12.in-addr.arpa name = 12-229-105-222.client.attbi.com.

Note that if you don't have "nslookup" or "whois", SamSpade.org has a nice web-based version.

A WHOIS lookup returns the following:

$ whois 12.229.105.222
AT&T WorldNet Services ATT (NET-12-0-0-0-1)
12.0.0.0 - 12.255.255.255
Comcast Corporation COMCAST-12-229-96-0-WASHINGTON (NET-12-229-96-0-1)
12.229.96.0 - 12.229.127.255


This indicates that while AT&T owns the IP address, they "sublet" the chunk which our suspect IP belongs in to Comcast Corporaton. Note the "NET-12-229-96-0-1" in parenthesis. We can do another WHOIS lookup on this to get:

$ whois NET-12-229-96-0-1

CustName: Comcast Corporation
Address: 1500 Market Street
City: Philadelphia
StateProv: PA
PostalCode: 19102
Country: US
RegDate: 2003-10-10
Updated: 2003-10-10

NetRange: 12.229.96.0 - 12.229.127.255
CIDR: 12.229.96.0/19
NetName: COMCAST-12-229-96-0-WASHINGTON
NetHandle: NET-12-229-96-0-1
Parent: NET-12-0-0-0-1
NetType: Reassigned
Comment:
RegDate: 2003-10-10
Updated: 2003-10-10

TechHandle: DK71-ARIN
TechName: Kostick, Deirdre
TechPhone: +1-919-319-8249
TechEmail: help@ip.att.net

OrgAbuseHandle: ATTAB-ARIN
OrgAbuseName: ATT Abuse
OrgAbusePhone: +1-919-319-8130
OrgAbuseEmail: abuse@att.net

OrgTechHandle: ICC-ARIN
OrgTechName: IP Customer Care
OrgTechPhone: +1-888-613-6330
OrgTechEmail: qhoang@att.com

OrgTechHandle: IPSWI-ARIN
OrgTechName: IP SWIP
OrgTechPhone: +1-888-613-6330
OrgTechEmail: swipid@nipaweb.vip.att.net


This gives us the address to send our complaint to: "abuse@att.net".

The trick to filing a complaint of this type is to be polite and to present all of the facts (as we've done above). It's also a good idea to provide the original message, with headers, as an attachment to the complaint. You also want to give the ISP an "out" in this case as it may be a hacked box on the far end.

The wording of my complaint (which I've just sent):

To whom it may concern,

Please forward the following to your Abuse and Security departments.

Please find attached an unsolicited (and particularly distasteful) pornographic e-mail advertisement (porn spam) that showed up in my in box. Various things about the headers are notable:

1) The "Return-Path", the source IP, and the source hostname all conflict. That is: "mrg@simplewire.com", "compuserve.com", and "12.229.105.222" respectively.
2) There are no other "Received:" lines other than the one generated by my Fetchmail utility (which I will vouch for the accuracy of) and the one generated by my ISP's (Cox) mailserver. This is indicative of a program connecting directly to Cox's mail server.

The IP recorded by Cox's mail server belongs to one of your customers. Please determine whether the user at that IP is running a spamming program or if it has been compromised by a trojan or worm which allows spammers to use it in a similar manner.

Respectfully,


One side "thought" generated by all of this. When the new federal anti-spam law goes into effect, there's going to be some trouble. There's a strong possibility that this source IP is infected with something similar to the Jeem trojan, which allows for remote control spamming. Given that law enforcement is in a constant game of technological "catch-up" with hackers/spammers, I hope they learn how to read and interpret message headers before throwing some poor church-going Granny in the slammer for spamming the planet with "l33t pr0n".