[Dshield] question about tracking spam

Bruce Lilly blilly at erols.com
Tue Nov 26 19:19:11 GMT 2002


> From: "Cruz, Dan" <Dan_Cruz at eu.odedodea.edu>
> Date: Tue, 26 Nov 2002 10:17:55 +0100
[...]
> I could use some assistance. The following was brought to my attention
> because one of our IP addresses (xxx.xxx.186.79 in red below) was in the
> header information. The problem is, although the block is within our range,
> it has never been used (to the best of our knowledge), and has been our for
> a few years. We have no networks using the affected IP blocks on-line. In
> trying to figure out the received path I get totally lost. I am trying to
> figure out how our IP address got into the mix, thus resulting in an email
> to us (although NOT to abuse at eu.odedodea.edu, since it is nonexistent). 
> 
> In other words I am going around in circles here!!!  Any suggestions or
> comments?

First, I see the complainant was using Mozilla (or Netscape).  Tip: you can get the
headers without the bizarre indentation and without modification via the
menu item "View Message Source" (Mozilla) or "View Page Source" (Netscape).

Second, The From and Return-Path headers in the original spam may be forged.
One can either ignore them or cc the relevant abuse contacts on any complaints.
Based on strong evidence that parts of the message headers are forged, it may
be best to ignore them (on the other hand, some people and companies
take strong exception to forged use of their identity, and will separately
pursue the spammer).  It's a question of how badly you'd like to see
the spammer nailed vs. getting back responses telling you that the use
was forged or that there's no such user, etc.


> From: Nicole Bremner [mailto:ponine at telus.net]
> Sent: Sunday, November 17, 2002 3:39 AM
> To: norm.seethoff at fluke.com; abuse at fluke.com;
> xxxxxxxxxxx at eu.odedodea.edu; abuse at eu.odedodea.edu;
> HOSTMASTER at nic.mil; abuse at nic.mil
> Subject: [Fwd: Dateless? 88-2]
> 
> 
> Return-Path:
>                    <sandbaruu408 at comcast.net>
>           Received:
>                    from comcast.net ([63.110.133.196]) by
> priv-edtnes09-hme0.telusplanet.net (InterMail
>                    vM.5.01.05.17
> 201-253-122-126-117-20021021) with SMTP id
> 
> <20021117020931.XANX4998.priv-edtnes09-hme0.telusplanet.net at comcast.net>;
> Sat, 16
>                    Nov 2002 19:09:31 -0700

Received headers are inserted by mail transfer agents (MTA) on each
"hop" of mail delivery. The first one (reading from the top) is the
last one (in sequence) to be added. [See RFCs 2821 and 2822 for details]
telusplanet.net ought to be the recipient's ISP; if not, there's a problem.
Otherwise, telusplanet.net's SMTP server at priv-edtnes09-hme0.telusplanet.net
received the message from IP address 63.110.133.196 from an SMTP client
claiming to be "comcast.net" (easily forged).

63.110.133.196 resolves to:

# whois 63.110.133.196
Cybertrails UU-63-110-128-D2 (NET-63-110-128-0-1)
                                   63.110.128.0 - 63.110.143.255
UUNET Technologies, Inc. UUNET63 (NET-63-64-0-0-1)
                                   63.64.0.0 - 63.127.255.255

# ARIN Whois database, last updated 2002-11-25 19:05
# Enter ? for additional hints on searching ARIN's Whois database.

The WWW search page at http://ws.arin.net/cgi-bin/whois.pl provides
clickable links for further information; the top NET link leads to
the following:

   Search results for: ! NET-63-110-128-0-1


OrgName:    Cybertrails
OrgID:      CYBERT-24

NetRange:   63.110.128.0 - 63.110.143.255
CIDR:       63.110.128.0/20
NetName:    UU-63-110-128-D2
NetHandle:  NET-63-110-128-0-1
Parent:     NET-63-64-0-0-1
NetType:    Reassigned
Comment:
RegDate:    2002-04-15
Updated:    2002-04-15

TechHandle: BS961-ARIN
TechName:   Senff, Brad
TechPhone:  +1-623-492-9200
TechEmail:  brad at ibizcorp.com

OrgNOCHandle: NETWO14-ARIN
OrgNOCName:   Network Operations
OrgNOCPhone:  +1-623-434-6045
OrgNOCEmail:  noc at cybertrails.com

OrgTechHandle: NETWO13-ARIN
OrgTechName:   Network Operations
OrgTechPhone:  +1-623-434-6045
OrgTechEmail:  noc at cybertrails.com

# ARIN Whois database, last updated 2002-11-25 19:05
# Enter ? for additional hints on searching ARIN's Whois database.

Sometimes there's an abuse contact listed. Not this time, so there
are a couple of options:
1. lookup via whois.abuse/net, which requires a domain name:

# whois -h whois.abuse.net cybertrails.com
abuse at cybertrails.com (for cybertrails.com)
postmaster at cybertrails.com (for cybertrails.com)

So one could complain to abuse at cybertrails.com (and optionally
copy postmaster at cybertrails.com) [but see an important caveat below].

Had that failed, option 2 would be to use one or more of the ARIN-listed
contacts, subject to the same caveat.

There's also a WWW interface to the abuse.net lookup engine.

>           Received:
>                    from unknown (129.196.102.126) by
> symail.kustanai.co.kr with NNFMP; Sat, 16 Nov 2002
>                    20:13:39 +0400

There are several hints of varying degrees of reliability that the
above Received header (and therefore those that follow it) is/are
forged:

1. Received headers should be in sequence. Therefore since the
(sequentially) last was received from 63.110.133.196, the second-last one
(above) should have been received *by* 63.110.133.196 or equivalent.
However, it claims to have been received by some Korean domain
instead.  This is a *very* reliable indication of forgery.

2. There is a wide discrepancy in timestamps between the two
Received headers (more than 10 hours -- it usually suffices to look
at minutes and seconds though, as converting time zone offsets can
be confusing). Mail transfer rarely takes more than a few seconds.
This is quite a reliable indication of forgery -- given the huge
time difference in this specific instance, it's a very reliable indication.

3. It claims to have been received from 129.196.102.126, which purportedly
claimed to be a system named "unknown".  "unknown" is not a fully-qualified
domain name, as required by RFC 2821 (in the SMPT HELO command or ESMTP
EHLO command).  That alone indicates that 129.196.102.126 is
poorly administered or is a spammer or that this header is forged.

4. 129.196.102.126 resolves to a reputable company which is unlikely
to be poorly adminsistered or a spam factory.  To some extent that is
a judgement call which requires some external knowledge.

# whois 129.196.102.126

OrgName:    Fluke Corporation
OrgID:      FLUKEC

NetRange:   129.196.0.0 - 129.196.255.255
CIDR:       129.196.0.0/16
NetName:    JOHN-FLUKE
NetHandle:  NET-129-196-0-0-1
Parent:     NET-129-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS1.FLUKE.COM
NameServer: DNS2.FLUKE.COM
Comment:
RegDate:    1988-02-09
Updated:    2001-07-16

TechHandle: NS-ARIN
TechName:   Seethoff, Norm
TechPhone:  +1-425-446-5054
TechEmail:  norm.seethoff at fluke.com

# ARIN Whois database, last updated 2002-11-25 19:05
# Enter ? for additional hints on searching ARIN's Whois database.

5. The zone offset specified in the timestamp certainly does not
correspond to Korea.  This is a fairly good indication of forgery by
an imbecile.

6. The header syntax is invalid.  Specifically the Internet Assigned
Numbers Authority maintains a list of values which may follow the
"with" keyword as standardized in the relevant RFCs (2821 in this case).
[See http://www.iana.org/assignments/mail-parameters]  The only legal
values after "with" are (case-insensitive) "SMTP" and "ESMTP". Anything
else either indicates forgery by an ignoramus (as highly likely in this
instance) or use of non-compliant software produced by a company either
with disdain for standards or employing idiots as programmers, or both,
as would be the case if something like "Microsoft SMTPSVC" appeared
after "with".  With the possible exception of use of such non-compliant
sotware produced by companies with disdain for standards and/or employing
idiots as programmers, bad syntax in a Received header is a quite good
indication of forgery by somebody who is clueless about email standards.

With 6 highly reliable indications that this is a forged header, there's
no point in the recipient looking at the remaining Received headers to
identify the source; almost certainly the forger (and spammer) is at
cybertrails.com.

Before sending a complaint, however, it is prudent to do a bit more
investigation, as sometimes spammers run domains for the sole purpose
of spamming (so-called spam factories).  Let's see just who "cybertrails.com"
is:

# whois cybertrails.com

Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

    Domain Name: CYBERTRAILS.COM
    Registrar: TUCOWS, INC.
    Whois Server: whois.opensrs.net
    Referral URL: http://www.opensrs.org
    Name Server: CREEDENCE.CYBERTRAILS.COM
    Name Server: WHO.CYBERTRAILS.COM
    Updated Date: 23-oct-2002


 >>> Last update of whois database: Tue, 26 Nov 2002 04:56:30 EST <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.


Found InterNIC referral to whois.opensrs.net.

Registrant:
  Cybertrails
  1919 W. Lone Cactus DR.
  Phoenix, AZ 85027
  US

  Domain Name: CYBERTRAILS.COM

  Administrative Contact:
     Network Operations, Cybertrails  noc at cybertrails.com
     1919 W. Lone Cactus DR.
     Phoenix, AZ 85027
     US
     623-434-6045
     Fax: 623-434-6099

  Technical Contact:
     Network Operations, Cybertrails  noc at cybertrails.com
     1919 W. Lone Cactus DR.
     Phoenix, AZ 85027
     US
     623-434-6045
     Fax: 623-434-6099



  Registration Service Provider:
     cybertrails, noc at cybertrails.com
     1-888-462-9237
     http://www.cybertrails.com/


  Registrar of Record: TUCOWS, INC.
  Record last updated on 23-Oct-2002.
  Record expires on 22-Nov-2003.
  Record Created on 23-Feb-1996.

  Domain servers in listed order:
     WHO.CYBERTRAILS.COM   162.42.150.33
     CREEDENCE.CYBERTRAILS.COM   162.42.150.47


The Data in the Tucows Registrar WHOIS database is provided to you by Tucows
for information purposes only, and may be used to assist you in obtaining
information about or related to a domain name's registration record.

Tucows makes this information available "as is," and does not guarantee its
accuracy.

By submitting a WHOIS query, you agree that you will use this data only for
lawful purposes and that, under no circumstances will you use this data to:
a) allow, enable, or otherwise support the transmission by e-mail,
telephone, or facsimile of mass, unsolicited, commercial advertising or
solicitations to entities other than the data recipient's own existing
customers; or (b) enable high volume, automated, electronic processes that
send queries or data to the systems of any Registry Operator or
ICANN-Accredited registrar, except as reasonably necessary to register
domain names or modify existing registrations.

The compilation, repackaging, dissemination or other use of this Data is
expressly prohibited without the prior written consent of Tucows.

Tucows reserves the right to terminate your access to the Tucows WHOIS
database in its sole discretion, including without limitation, for excessive
querying of the WHOIS database or for failure to otherwise abide by this
policy.

Tucows reserves the right to modify these terms at any time.

By submitting this query, you agree to abide by these terms.

NOTE: THE WHOIS DATABASE IS A CONTACT DATABASE ONLY.  LACK OF A DOMAIN
RECORD DOES NOT SIGNIFY DOMAIN AVAILABILITY.


It's hard to say... on one hand it seems to be consistent with the
ARIN data, but on the other hand the listing of two DNS servers in the
same domain as each other and in the same IP address range is dubious
practice at best; those being in the registrant's domain as well is
rather absurd (if you want to find domain information on cybertrails.com,
according to the registry information, you have to get it from
cybertrails.com, which is a rather obvious chicken-and-egg problem
and contravenes established procedures for setting up domain name
servers (at least two servers in different domains and in different
IP ranges)).  One could check for valid addresses and telephone numbers.
check for complaints registered with the Phoenix Better Business Bureau,
etc.  One could also (with Java and Javascript disabled!) look at the
WWW site listed. If I were complaining, I'd bypass cybertrails.com and complain
directly to the holder of the enclosing IP range, viz. UUNET. Following
the 2nd NET link on the ARIN search results page gives:

   Search results for: ! NET-63-64-0-0-1


OrgName:    UUNET Technologies, Inc.
OrgID:      UU

NetRange:   63.64.0.0 - 63.127.255.255
CIDR:       63.64.0.0/10
NetName:    UUNET63
NetHandle:  NET-63-64-0-0-1
Parent:     NET-63-0-0-0-0
NetType:    Direct Allocation
NameServer: AUTH03.NS.UU.NET
NameServer: AUTH00.NS.UU.NET
Comment:    ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate:    1999-01-22
Updated:    2001-09-26

TechHandle: OA12-ARIN
TechName:   UUnet Technologies, Inc., Technologies
TechPhone:  +1-800-900-0241
TechEmail:  help4u at wcom.com

OrgAbuseHandle: ABUSE3-ARIN
OrgAbuseName:   abuse
OrgAbusePhone:  +1-800-900-0241
OrgAbuseEmail:  abuse-mail at wcom.com

OrgNOCHandle: OA12-ARIN
OrgNOCName:   UUnet Technologies, Inc., Technologies
OrgNOCPhone:  +1-800-900-0241
OrgNOCEmail:  help4u at wcom.com

OrgTechHandle: SWIPP-ARIN
OrgTechName:   swipper
OrgTechPhone:  +1-800-900-0241
OrgTechEmail:  swipper at uu.net

# ARIN Whois database, last updated 2002-11-25 19:05
# Enter ? for additional hints on searching ARIN's Whois database.


In this case, there is a direct abuse contact listed: "abuse-mail at wcom.com".

I happen to remember a different uu.net abuse address, so I'd double-check
with abuse.net:

# whois -h whois.abuse.net uu.net
abuse at uu.net (for uu.net)

I'd complain to abuse at uu.net (actually abuse-noverbose at uu.net) first,
then possibly to abuse at wcom.com depending on what came back from uu.net's
autoresponder.  If cybertrails.com is a legitimate second-tier ISP and not
a spam factory, I'd expect uunet to forward the complaint for resolution.

[...]

Sometimes there is message body content (e.g. URIs, email addresses,
telephone numbers, etc.) which can also be used to identiy the spammer,
and which can be investigated to provide a place to complain to. In
this case, if there was one, it has been obscured by cut/paste or the
Dshield list html filter.

>>          To Remove yourself from this opt-in mailing Click Here

*NEVER* click on or use any such links (indeed, when opening any
possible spam in Netscape or Mozilla, use the "work Offline" menu
item for additional security); at best that would add your email
address to more spammers' lists.

That (in a rather large nutshell) is how to track spam.  In your case,
since you're on the recieving end of a poorly investigated complaint,
you can
a. ignore it
b. try to educate the complainant (if you do so, you might or might not
    wish to copy your fellow recipients of the complaint, as some of
    them may also have been confounded by the forgery)
c. forward to the *relevant* abuse contact, if not already contacted
    by the complainant
d. as an IP address registered to your organization was forged, you
    could add your voice to the complaint (to the relevant abuse
    contact, of course)
or some combination of b-d above.

Another way for you as the recipient of a complaint to verify the
validity of the complaint is to examine the Received header(s)
purportedly inserted by you and by the next hop:

>           Received:
>                    from xxx.xxx.186.79 ([xxx.xxx.186.79]) by
> rly-xr01.nihuyatut.net with asmtp; Sat, 16 Nov
>                    2002 21:03:41 -0700

That purports to have been inserted by a site which received the message
from an IP address in your range. One thing to check is whether or not
there is a machine at the IP address in question.  If not it's either a
rogue machine that has already been disconnected or the header is a forgery.
If you have a firewall or collect router logs, you can check to
see if there was any traffic from the IP address to rly-xr01.nihuyatut.net
(assuming that that is a valid domain name) at the time corresponding
to the timestamp.  We've already established well beyond any reasonable
doubt that headers have been forged, so such an investigation would
almost certainly be fruitless in this case. [But it can still be
an educational experience (no pun intended); do you in fact have
a firewall? do you log traffic and keep secure logs? What would you do
if the header wasn't an obvious forgery?]  One could also check other
signs for forgery; in this case we have an illegal "asmtp" and one
could check to see if a -0700 zone offset is consistent with the location
of rly-xr01.nihuyatut.net (again assuming that that is valid). If you
do have a border firewall, is it configured appropriately in accordance
with your institution's policy (is there in fact a policy?) [e.g. if
policy requires outboud email to be routed via an SMTP server on site,
your firewall could (and should) be configured to block traffic to port
25 at any external IP address which originates from any port at any
internal IP address other then your SMTP servers]?  If you don't have
a border firewall, perhaps you should look into installing one.

>           Received:
>                    from smtp-server1.cflrr.com
> ([28.242.36.170]) by rly-xr01.nihuyatut.net with esmtp; Sat,
> 16
>                    Nov 2002 13:58:42 +1000

If the preceding Received header had been valid, this one should
have originated at the IP address implicated at your site. But
it clearly does not, and as previously mentioned, that is a very
reliable indication of forgery.  The same supposed received by
site in two Received headers is another gaff on the part of the forger.
And yet again there are wide timestamp discepancies.  Had the forger
been considerably less incompetent, this one would have claimed to
have been inserted by a machine in your jurisdiction. What would you
do if that had been the case? Do you know what Received headers inserted
by your SMTP servers look like?  Do you keep secure logs of email
transfers?  In short, how can you prepare to deal with real abuse
before it happens.

Other lessons to be learned: you mentioned that the abuse at eu.odedodea.edu
address is nonexistent.  Did you know that there is an RFC that strongly
recommends such standardized contact information (RFC 2142)?  Perhaps
you should consider establishing such an address (or alias which redirects
mail sent to that address to somebody responsible).  Does your ARIN record list
an abuse contact (as opposed to somebody who deals with domain registration)?
Is an abuse contact listed with abuse.net for eu.odedodea.edu and/or
odedodea.edu?  Is abuse contact information provided in your DNS records
(e.g. in comments)?  Do your DNS records have LOC data so that a spam
investigator can determine whether or not a time zone offset in a Received
header timestamp purportedly inserted at your site is consistent with your
location? In short, how can you make it easier for spam victims to realize
forgeries involving your site when they come across them, or in the case
of real abuse, how can you facilitate getting the complaints to the appropriate
person.




More information about the list mailing list