byUsers

Reading and Understanding Email Headers

• Introduction
• E-mail Headers
  • Mandatory E-mail Headers
  • Optional E-Mail Headers
  • E-Mail Trace Headers
• Usenet Headers
  • Mandatory Usenet Headers
  • Optional Usenet Headers
  • Usenet Trace Headers
  • De Facto Standard Usenet Headers
• Other Headers
  • MIME and Attachment Headers
  • Mailing List Headers
  • X.400 Headers
  • Receipt Headers
• Notes
  • Bcc Header Notes
  • Threading Notes
• User Defined Headers
  • User Defined E-Mail Headers
  • User Defined Usenet Headers
• Tracing E-mails and Usenet Posts
  • Tracing E-Mail Headers
  • Why It’s a Really Bad Idea to Try to "Bounce" POP3 Mail
  • Tracing Usenet Headers

Introduction

All E-mail and Usenet messages are supposed to conform to the standards laid out in RFC 2822 (which "obsoleted" RFC822 in April 2001) and RFC1036 (not a "formal" standard, but regarded as such by the Internet community until its replacement, a combination of RFC1036,"Son of RFC1036" [started in June 1994], and the kitchen sink is complete). Many older clients are not aware of the changes in RFC2822, so in general RFC822 may still be considered valid, at least for a while.

Essentially, all E-mail and Usenet messages comprise five kinds of information:

• Formal Headers (those defined in the above RFCs)
• Trace Headers (also defined in the above RFCs)
• De Facto Standard Headers (defined elsewhere, such as in RFC2980)
• User-Defined Headers (no formal standing, but often widely understood and implemented), known as "X-Headers" since they are always of the form "X-<headername>" to distinguish them from "real" headers. Their existence and use is pointedly ignored in RFC2822.
• The Message Body

The Message Body is largely irrelevant to this FAQ, since its content is more properly defined by the various RFCs relating to MIME (RFCs 2045-2049) and other encoding "standards" such as UUE, YENC etc.

Headers are defined in some detail in RFC2076.

E-Mail

The mandatory "Formal" E-mail headers(i.e. the minimum to ensure a "compliant" message) are:

Date:

The date the message was originated/written.

From:

The person "responsible" for the message.

Optional "Formal" E-mail headers are:

Subject:

Title, heading, subject matter of the message.

Message-ID:

Identity of the message. Should be formed in such a way as to guaranteeuniqueness.

In-Reply-To:

The Message-ID of the message to which this message is a reply.

References:

List of messages to which this message relates. Should be added to with each subsequent reply by appending the "In-Reply-To:" header contents.

To:

The main intended recipient(s).

Cc:

Secondary "FYI" (Carbon Copy) recipients.

Bcc:

(Blind Carbon Copy) Recipients not to be disclosed to other recipients.

Sender:

The person (or "agent", in the case of software) submitting the message, if different from the "From:" details.

Reply-To:

The preferred address to which replies should be sent.

Comments:

Comments on a message. Not commonly seen, except in spam and messages from Pegasus users.

Keywords:

Search keys for Database retrieval. Not commonly seen.

Resent-Date:

Resent-From:

Resent-Sender:

Resent-To:

Resent-Cc:

Resent-Bcc:

Resent-Message-ID:

The "Resent" headers allow the forwarding of a message without adjusting the original headers. Not commonly seen.

E-mail "Trace" headers are:

Return-Path:

Contains the contents of the SMTP "MAIL FROM:" Envelope Header when the message leaves the SMTP environment into, for example, a POP3 environment.

Received:

Trace of MTAs (Mail Transfer Agents) through which the message has passed. More on this below…

Usenet

The mandatory "Formal" headers in Usenet are:

Date:

The date the message was written (not when it was posted)

From:

The person "responsible" for the message.

Newsgroups

The newsgroups to which the message is being posted. Ideally this header ought not to appear in an E-mail message, but where a message is sent to both environments, or a Usenet message is replied to by e-mail, it can appear.

Subject:

Title, heading, subject matter of the message.

Message-ID:

Identity of the message. Should be formed in such a way as to guarantee uniqueness. This is even more important for Usenet than for E-mail.

Optional "Formal" Usenet headers are:

Sender:

The person (or "agent", in the case of software) submitting themessage, if different from the "From:" details.

Followup-To:

The name of one or more Newgroups (never mail addresses) to which responses should be directed. Often used in cross-posted messages to restrict subsequent discussion to a single location. May be set to "poster" to indicate that replies should be made only by E-mail.

Reply-To:

Address to which E-mail replies to a Usenet posting should be made.

Lines:

A count of the number of lines in the message body.

References:

List of messages to which this message relates. Should be added to with each subsequent reply by appending the Message-ID of the message to which the reply is being made.

Organization:

The "organisation" to which the poster belongs.

Approved:

Added by the moderator of a moderated newsgroup to indicate that the message has been approved for distribution.

Distribution:

Intended to limit distribution to, for example, a specific geographic area. Not commonly seen.

Keywords:

Search keys for Database retrieval. Not commonly seen.

Summary:

Brief summary of a message/article. Not commonly seen.

Control:

Indicates a message used to control Usenet/Newsgroup propagation in some way, such as creating a new group or changing its status. Not usually be seen by "normal" Usenetizens.

Expires:

Suggests an expiration date for the message.

Supersedes:

Suggests that the current message should replace the one whose Message-ID is referred to by this header. The referenced message should be deleted from the server.

Usenet "Trace" headers are:

Path:

A list of the MTAs (Message Transfer Agents) through which the message has passed. Analogous to the "Received:" header in E-mail. More on this below…

Xref:

A list of the locally-stored Newsgroups that have received the message (as specified in the "Newsgroups" header), with the message number within the local storage of those groups. Helps in cross-post management to prevent reading the same message more than once. This header should never be transmitted to another newsswerver, since it is strictly local in context.

De facto "Standard" headers are:

NNTP-Posting-Host:

The verified IP Address or Domain Name of the host that posted the message.

NNTP-Posting-Date:

Date the message was posted (cf "Date:" above for when it was originated).

Other Headers

In addition to the headers above, there are others relating to Message Encapsulation (MIME) and Attachment Presentation that may be present in E-mail or Usenet messages:

MIME-Version:

Which MIME Version has been used to encapsulate the message or its attachments.

Content-Type:

The nature of the message body or section (e.g. text/html, text/plain, multipart/mixed etc.)

Content-Transfer-Encoding:

Coding method used in the MIME Version indicated (Base64, 7-bit, quoted-printable etc.).

Content-Disposition:

Suggests whether a MIME-part should be viewed "inline" or as an attachment.

Content-Description:

Textual (human-readable) description of the contents of the message body.

Some non-standard headers, commonly used by mailing lists, are:

Errors-To:

Attempts to ensure error messages and bounces are not distributed to theMailing List. Should not normally happen anyway, unless dealing with brain-deadmail readers, such as those from Microsoft.

Precedence:

May be set to "bulk" or "list" for Mailing List messages,to indicate to the receiving mail reader that it should not sendout Delivery Receipts, Vacation Messages etc. in response to the message.Similarly for "auto_reply". Guess which company’s products ignorethese meanings.

It’s also anybody’s guess what "normal", "first-class"and "special-delivery" are supposed to mean in this header.

It is frequently set to "junk" or "generic_junk" inautomated replies from some Abuse Desks. Make of that what you will.

To "map" common X.400 message headers to Internet message headers we often see:

Importance:

"Low", "Medium" or "High" priority. "Medium" is same as "pretend this header isn’t here", and it is a waste of bytes ever to include it.

Sensitivity:

"Personal", "Confidential" or "Private".

Other common, but non-standard (often created by Microsoft with its usual disregard for the "S"-word) E-mail headers, all relating to the abhorrent practice of requesting receipts for E-mail messages, are:

Disposition-Notification-Options:

Disposition-Notification-To:

Return-Receipt-Requested:

Return-Receipt-To:

Read-Receipt-To:

Registered-Mail-Reply-Requested-By:

Notes

The Bcc: Header

It is unusual to see this header on a message, but not impossible.

• It may be present, but blank, indicating that Bcc recipients were specified,but you’re not allowed to know who they are.
• It may be present, with your mail address in, so you know that you werean intended recipient.
• It may be present, and filled out with the addresses of all the Bcc recipients.This is WRONG! What’s the point of making them "blind"recipients if their addresses are broadcast for all to see?

Threading and Headers

Correct "threading" of messages (in mail readers that are capableof doing so, such as FortéAgent and Becky)relies on the References and In-Reply-To headers, which rely in turn on correctlyformed and unique Message-IDs. If the References and In-Reply-To headers arebroken in some way, good mail readers may (optionally) try to use the Subjectand Date headers to thread. Mail programs that frequently break Subject (TheBat!et al) or References (Foxmail et al) make life enormouslydifficult for compliant mail readers, and should be avoided. Outlook and OutlookDistress cannot thread.

Because mail readers thread using References, replying to a message to createa new thread is not only lazy, but will insert the new message into the middleof a thread regardless of intent. Messages intended to start new threads shouldalways be created as new blank messages.

User-Defined Headers

These headers have no formal definition; there are thousands of them in use;and more are made up every day. Some common ones are given below, but rememberthat their meaning and usage is not guaranteed, since they have no formal status:

E-mail

X-Mailer:

Used to supply the name of the mail program used to create the message.Partly advertising, this header is a useful way of determining the name ofa program that is being "badly behaved".

X-Hops: (Also X-Loop:)

Used by MTAs to record the number of "hops" the message has taken,that being the number of passes through any MTA. Messages whose hop-countrises above 10 or so are assumed to be "lost" or looping in someway, so are returned undeliverable. Easier than counting "Received:"headers.

X-EnvelopeTo: (Also X-ForwardedFor:,X-ReceivedFor:, X-DeliveredTo:, X-RCPT-TO:and others)

The address of the recipient of the message, as extracted from the SMTPdelivery envelope.

X-EnvelopeFrom:

As above, for the SMTP Sender.

Usenet

X-Newsreader: (Also X-Posting-Agent:)

Used to supply the name of the news program used to create the message.Partly advertising, this header is a useful way of determining the name ofa program that is being "badly behaved".

X-Abuse-Info: (Also X-Complaints-To:,X-Notice:, X-Report:, X-Report-Abuse-To:)

Mail address to which abuse reports and complaints should be directed.

X-Trace:

Contains trace information of date/time posted, IP Address etc. for easier tracking of abuse by ISPs. Often obscure and incomprehensible to allow a degreeof anonymity to posters.

X-Received-Date:

The date the message was received by the Newsswerver.

X-Face:

Contains a UUEncoded 48×48 bitmap picture of the sender. Really! Alsofound (less commonly) in E-mail.

X-MimeOLE:

X-Priority:

X-MSMail-Priority:

Utterly Meaningless headers inserted into Usenet messages by Outlook Distress solely to annoy people, it seems.

X-No-Archive:

Request to Google Groups(formerly Déja News) not to hold the message in their public archives.Generally seems to be honoured.

X-No-Markup:

Designed to prevent Remarq (now defunct) turning words in archived messages into Hyperlinks.

X-No-Productlinks:

Designed to prevent Déja News turning words in archived messages into Hyperlinks.

Tracing E-Mails and Usenet Posts

The first and most important step is to trust nothing.

Every part of an E-mail may be forged apart from the topmost "
Received:"header, every part of a Usenet post may be forged apart from the left most portion of the "Path:" header.

That warning aside, it is usually possible to find a responsible party to which to report E-mail abuse, even if that party is responsible only by permitting their systems to be abused by someone else; and the same is true for Usenetabuse.

E-Mail

The "Received:" headers are the key to tracing an E-Mail. They are what services such as Spamcop and the Windows Downloadable version of SamSpade use.

Here’s some spam received to an old blueyonder mailbox:

Received: from yaohoo.com ([213.68.189.234]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75);Fri, 7 Jun 2002 14:38:33 +0100
Received: from [61.239.75.176] by sydint1.microthink.com.au with esmtp; 06 Jun 0102 11:37:38 +0400
Received: from unknown (HELO mta21.bigpong.com) (107.219.217.240)
by web.mail.halfeye.com with asmtp; Thu, 06 Jun 0102 15:30:18 +0500
Received: from [122.218.247.21] by a231242.upc-a.zhello.nl with local; 06 Jun 0102 20:22:58 +0900
Received: from 192.234.177.231 ([192.234.177.231]) by m10.grp.snv.yahui.com with SMTP; Fri, 07 Jun 0102 05:15:38 +0800
Reply-To: <twosassytwin3s0515f35@ yaohoo.com>
Message-ID: <011d66a31d4c$6257c5b7$7ac32cd0@xlwylj>
From: <twosassytwin3s0515f35@ yaohoo.com>
To: private_x
Subject: Here Ya Go! 36-2
Date: Fri, 07 Jun 0102 10:08:11 +0300
MiME-Version: 1.0
Content-Type: multipart/mixed;
boundary="—-=_NextPart_000_00D2 _70C77E6C.C8150C52"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
Return-Path: twosassytwin3s0515f35@ yaohoo.com
 
——=_NextPart_000_00D2 _70C77E6C.C8150C52
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: base64
 
TXkgU2lzdGVyIGFuZCBJIE9ubGluZ SAtICAgDQogSXQnc3lvdXIgZnJpZW5k
cyBhZ2Fpbi4uLiA8YnI+PGEgaHJlZ j0iaHR0cDovL3h4eGNvcmUubmV0L3Uv
bGl2ZWNhbXMvIj5DbGljayBJZiBZb 3UgV2FubmEgU2VlIE15IFBpY3MgT3Ig
SWYgWW91IFdhbm5hIENoYXQ8L2E+I G9yIGh0dHA6Ly94eHhjb3JlLm5ldC91
L2xpdmVjYW1zLw==

Let’s deconstruct it. Firstly, the message body itself, with all headers relatingto it.

MiME-Version: 1.0
Content-Type: multipart/mixed;
boundary="—-=_NextPart_000_00D2 _70C77E6C.C8150C52"
 
——=_NextPart_000_00D2 _70C77E6C.C8150C52
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: base64
 
 
TXkgU2lzdGVyIGFuZCBJIE9ubGluZ SAtICAgDQogSXQnc3lvdXIgZnJpZW5k
cyBhZ2Fpbi4uLiA8YnI+PGEgaHJlZ j0iaHR0cDovL3h4eGNvcmUubmV0L3Uv
bGl2ZWNhbXMvIj5DbGljayBJZiBZb 3UgV2FubmEgU2VlIE15IFBpY3MgT3Ig
SWYgWW91IFdhbm5hIENoYXQ8L2E+I G9yIGh0dHA6Ly94eHhjb3JlLm5ldC91
L2xpdmVjYW1zLw==

OK, it’s not important what the message actually says. It’s MIME-Encapsulatedusing Version 1.0 MIME, it’s BASE64-encoded HTML, It’s in the ISO-8859-1 characterset, and it claims to be "multipart/mixed", but since there’s no contentapart from the HTML, that’s not true. All this is not significant to the spamitself.

Will any more headers shed any light?

X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal

Well, it says it was created using Microsoft Outlook XP, which might explainthe dodgy "Content-Type" header, and those irrelevant Priority andImportance headers are characteristic of Microsoft software, but it’s stillnot useful information.

Message-ID: <011d66a31d4c$6257c5b7$7ac32cd0@xlwylj>
To: private_x
Subject: Here Ya Go! 36-2

Well, the Message-ID says nothing about the sender of the mail, the "Subject"tells me nothing either, and the "To:" header is clearly irrelevant.Let’s keep looking:

From: <twosassytwin3s0515f35@ yaohoo.com>
Reply-To: <twosassytwin3s0515f35@ yaohoo.com>
Return-Path: twosassytwin3s0515f35@ yaohoo.com

Well, here’s something. These three headers all match. Does this mean we’vefound our spammer?

whois -h whois.opensrs.net yaohoo.com ...
Registrant:
Yao Hoo Herski
67/j-6vouj Pzscek
Gdynsk, Poland 82285
PL
 
Domain Name: YAOHOO.COM
 
Administrative Contact:
Hostmaster, Hostmaster tubul@prontomail.com
67/j-6vouj Pzscek
Gdynsk, Poland 82285
PL
588-348
 
Technical Contact:
Hostmaster, Hostmaster tubul@prontomail.com
67/j-6vouj Pzscek
Gdynsk, Poland 82285
PL
588-348
 
Registration Service Provider:
Tubul Law, tubul_law@hotmail.com
800-684-0833
 
Registrar of Record: TUCOWS, INC.
Record last updated on 15-Mar-2002.
Record expires on 24-Apr-2003.
Record Created on 25-Apr-1998.
 
Domain servers in listed order:
NS.ZF.NET205.216.134.37
DNS.ZF.NET216.102.246.43

Tempting to get straight onto <tubul@prontomail.com>, isn’t it? Not sofast!

What other headers do we have?

Date: Fri, 07 Jun 0102 10:08:11 +0300

A time-zone of +0300 indicates that the message comes from East of here. That would be consistent with the information above, wouldn’t it? Nope. Poland uses CEST, which is GMT+1. See World Clock To be 3 hours ahead would put us in
Moscow instead. And what’s all this with "0102"?Nope, this header is as fake as the rest.

That just leaves us with the "Received:" headers to rely on, which is what I’ve been saying all along, right?

"Received:" headers should be read from the bottom upwards, since they are added to the top of the message by each MTA that the message passed through. They should be analysed from the top down, in case there are any fakes in there. So, let’s go:

Received: from yaohoo.com ([213.68.189.234]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75);
Fri, 7 Jun 2002 14:38:33 +0100

This says that blueyonder’s mail server (blueyonder.co.uk) received the message at 14:38:33 BST (GMT + 0100) on Friday June 7^th from a mail server claiming to be called yaohoo.com residing at the IP Address213.68.189.234. Well, let’s use some tools at http://www.samspade.org:

dns yaohoo.com
Canonical name: yaohoo.com
Addresses:
216.102.246.27

whois -h magic 216.102.246.27
 
Trying whois -h whois.arin.net 216.102.246.27
 
Pac Bell Internet Services (NETBLK-PBI-NET-6)
268 Bush St. #5000
San Francisco, CA 94104
US
 
Netname: PBI-NET-6
Netblock: 216.100.0.0 - 216.103.255.255
Maintainer: PACB
 
Coordinator:
Pacific Bell Internet (PIA2-ORG-ARIN) ip-admin@pbi.net
888-212-5411
 
Domain System inverse mapping provided by:
 
NS1.PBI.NET 206.13.28.11
NS2.PBI.NET 206.13.29.11
 
ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
please send all abuse issue e-mails to abuse@pbi.net
 
Record last updated on 26-Sep-2001.
Database last updated on 23-Aug-2002 16:56:03 EDT.

whois -h whois.ripe.net -V62.31.224.2 213.68.189.234
 
% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit http://www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html
 
inetnum:213.68.189.232 - 213.68.189.239
netname:IT-LAN
descr: Innovation Technology GmbH
descr: Berblinger Str. 2
descr: D-71254 Ditzingen
country:DE
admin-c:DM5867-RIPE
tech-c: DM5867-RIPE
status: ASSIGNED PA
mnt-by: UUNETDE-I
changed:hostmaster@de.uu.net 20000526
source: RIPE
 
route: 213.68.0.0/14
descr: UUNETDE-AGG-213.68
origin: AS702
member-of: RS-UUNETEUDE
mnt-by: UUNET-MNT
changed:mz@de.uu.net 20011123
source: RIPE
 
person: Dieter Mitsch
address:Innovation Technology GmbH
address:Berblinger Str. 2
address:D-71254 Ditzingen
phone: +49 7156 4257137
fax-no: +49 7156 4257100
nic-hdl:DM5867-RIPE
mnt-by: UUNET-P
changed:gah@de.uu.net 20000525
changed:hostmaster@de.uu.net 20000719
source: RIPE

Tricky. 213.68.189.234 has no rDNS, so we can’t put a nameto it. yaohoo.com is at address 216.102.246.27,which isn’t the same IP at all. Yaohoo is in the US, whereas the mail came viaGermany. Could be a forged source.

Let’s look at the next header:

Received: from [61.239.75.176] by sydint1.microthink.com.au with esmtp; 06 Jun 0102 11:37:38 +0400

Well now, what have we here? After claiming that the mail was from yaohoo.com,we suddenly find that it was received from 61.239.75.176 by a server called sydint1.microthink.com.au. Since the next MTAin the chain, blueyonder’s own server, was told that the mail was being sent by
yaohoo.com with an IP of 213.68.189.234,we’d expect sydint1.microthink.com.au to be owned by yaohoo.comand to have an IP of 213.68.189.234, wouldn’t we?

whois -h whois.aunic.net microthink.com.au
 
Error - microthink.com.au doesn’t exist

Oh dear. If microthink.com.au doesn’t exist, that means we’ve been lied to. This "Received" header and all headers below it are untrusted. The chain has been broken, and we must ignore all "Received:"headers apart from the first.

Received: from yaohoo.com ([213.68.189.234]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75);
Fri, 7 Jun 2002 14:38:33 +0100

This says that the mail came from 213.68.189.234. It doesn’t matter what it called itself, "yaohoo.com" or "Lynda.Carter",we have established that it is part of the de.uu.net blockof IPs, and it’s either the source of the spam, or responsible for it becauseof its failure to record "Received" headers properly, making it opento being abused. We don’t actually care which.

whois -h whois.abuse.net de.uu.net ...
abuse@de.uu.net (for de.uu.net)

So that’s where our Abuse Report should go.

NOTE: When reporting an abusive E-mail, you should forwardthe E-Mail, intact, with all its headers, and the result of an nslookupfor the IP that you suspect to be the source. Do not send the output of a whois command. Abuse desk staff are perfectlycapable of doing that themselves. The reason for including the nslookup is simply to show that you’ve done your homework. Let the Abuse desk take it from there.

SpamCop would have found this much quicker for us. It’s worth getting an account.Let’s see how it deals with some spam.

From:mike3356@midinfo.co.jp
Date:Tue Jul 30 01:49:32 GMT 2002
To:x
Cc:x, x, x, x, x, x, x, x, x, x
Subject:You Asked For It!!!
Content-Type: text/html; charset=us-ascii
X-Received: 31 Jul 2002 20:53:57 GMT
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <mike3356@midinfo.co.jp>
Received: (cpmta 20571 invoked from network); 31 Jul 2002 20:53:57 +0000
Received: from 208.162.154.194 (HELO hospmail.ukpik) by smtp.c000.lhr.cp.net (209.228.22.156) with SMTP; 31 Jul 2002 20:53:57 +0000
Received: from 212.104.138.242 (WILLBECKDC [212.104.138.242]) by hospmail.ukpik with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PW20YTTR; Mon, 29 Jul 2002 22:00:44 -0800
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
 
Converting X-Received to Received:
 
Parsing header:
 
Received: 31 Jul 2002 20:53:57 GMT
no from
no ip found in received line
Ignored
not listed in proxies.relays.monkeys.com
 
Received: (cpmta 20571 invoked from network); 31 Jul 2002 20:53:57 +0000
no ip found in received line
Ignored
not listed in proxies.relays.monkeys.com
 
Received: from 208.162.154.194 (HELO hospmail.ukpik) by smtp.c000.lhr.cp.net (209.228.22.156) with SMTP; 31 Jul 2002 20:53:57 +0000
Masking IP-based ‘by’ clause.
Received: from 208.162.154.194 (HELO hospmail.ukpik) by smtp.c000.lhr.cp.net with SMTP; 31 Jul 2002 20:53:57 +0000
not listed in proxies.relays.monkeys.com
Possible spammer: 208.162.154.194
host hospmail.ukpik (checking ip) ip not found ; hospmail.ukpik discarded as fake.
no MXs for hospmail.ukpik
Taking name from IP…
host 208.162.154.194 (getting name) no name
208.162.154.194 is not an MX for hospmail.ukpik
Received line accepted
 
Received: from 212.104.138.242 (WILLBECKDC [212.104.138.242]) by hospmail.ukpik with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PW20YTTR; Mon, 29 Jul 2002 22:00:44 -0800
host 208.162.154.194 (getting name) no name
208.162.154.194 not listed in proxies.relays.monkeys.com
Possible spammer: 212.104.138.242
Taking name from IP…
host 212.104.138.242 (getting name) no name
Chain test:hospmail.ukpik =? 208.162.154.194
host hospmail.ukpik (checking ip) ip not found ; hospmail.ukpik discarded as fake.
no MXs for hospmail.ukpik
host 208.162.154.194 (getting name) no name
Chain test failed
Chain test:hospmail.ukpik =? 208.162.154.194
host hospmail.ukpik (checking ip) ip not found ; hospmail.ukpik discarded as fake.
no MXs for hospmail.ukpik
host 208.162.154.194 (getting name) no name
Chain test failed
host 208.162.154.194 (getting name) no name
Routing details for 208.162.154.194
Cached whois for 208.162.154.194 : lewis@ukpik.com
Using last resort contacts lewis@ukpik.com
Whois found lewis@ukpik.com
Chain error hospmail.ukpik not equal to last sender received line discarded
 
Tracking message source:208.162.154.194:
host 208.162.154.194 (getting name) no name
Routing details for 208.162.154.194
Cached whois for 208.162.154.194 : lewis@ukpik.com
Using last resort contacts lewis@ukpik.com
Whois found lewis@ukpik.com

Nice and easy.

Why It’s a Really Bad Idea to Try to "Bounce"POP3 Mail

Looking at the first example trace above, it should be clear that the apparentsource of the E-mail, twosassytwin3s0515f35@yaohoo.com, maywell be a false address or, if it exists, may belong to an "innocent bystander"– someone with no connection whatsoever with the spam. On the other hand, itmay not be innocent. That address may be as tainted as the actual sender ofthe spam, whom we know to be somewhere on de.uu.net. The pointis, we don’t know.

Similarly, in the example that SpamCop traced for us, mike3356@midinfo.co.jpmight be guilty of all the crimes under the sun, but we can’t be sure.

Now, there are various third-party applications available (that I shall neitherlink to nor name) that offer to "bounce" spam, to try to fool thesender that it was never delivered. I trust you can you see one of the problemsstraight away. Quite simply, neither you nor the application have the firstidea of who actually sent the mail.

These are the four potential problems that make pretending to bounce POP3 maila Bad Idea^TM.

1. The apparent sender’s E-mail address may not exist. In this case your bouncewill simply bounce. What a waste of everyone’s bandwidth…
2. The apparent sender’s E-mail address may exist, but may belong to an innocentthird-party. Sometimes this is accidental. Sometimes it’s deliberate - whatis known as a "Joe Job" (named after the first poor sod on whomthis nasty stunt was pulled). Imagine having your own mailbox clogged withbounce after bounce after bounce - genuine bounces that are nothing whatsoeverto do with you. Not nice. If you’re lucky you can get them blocked by yourISP, but you have to be quick. Within minutes your mailbox could be full tooverflowing with all these bounces. Legitimate mail gets turned away. It’san extremely effective "Denial of Service" attack. Manually bouncedmails just add to the problem.
3. The apparent sender’s E-mail address may exist, and may indeed belong tothe spammer. Can you be sure that your "bounce" cannot be detectedas a forgery (which is, after all, what it is)? If it can, and you upset aspammer by pretending not to exist, you could become his next Joe Job target.Imagine having your own mailbox clogged with bounce after bounce after bounce…
4. By sending a forged bounce, you may be seen by your ISP, or the ISP of yourbounce’s target, as an abuser yourself. It’s not terribly likely,perhaps, but you have manually sent an unsolicited E-mail to someone. Thisis the essential definition of spam. The risk is not one that ought to betaken.

Once your E-mail address is on a spammer’s list; one of their "10 MillionE-Mail Addresses" CDs; the only thing you can do to prevent receiving spamis to drop that address so that it genuinely bounces. If you can’tdo that, the next best option is to report the spammers. Report them properly.Get them thrown off their ISPs. If they move to new ISPs, get them thrown offthere too. Put them out of business. But NEVER EVER REPLY,whether directly; by pretending to send them a bounce; or, worst of all, byhaving your mail software respond automatically to Delivery Receipt Requests.Don’t, whatever you do, buy anything from a spammer, no matter how temptingthe offer might be. Just lie low, and hit them where it hurts. Spammers wholose their accounts lose money. If spamming costs more than the revenue it generates,it might just stop.

Well, we can dream, eh?

Usenet

Tracking down Usenet abusers is often very straighforward, as in most casesthe sender is either too dumb to realise they’re being traced, or doesn’t care.Here’s an example spam:

Path:news-lhr.blueyonder.co.uk!news-hub.cableinet.net! blueyonder!newspeer1-gui.server.ntli.net! ntli.net!news.stealth.net! news.stealth.net!nobel.pacific.net.sg! not-for-mail
From:kbgzwe@yahoo.com
Newsgroups:alt.pub.kacees
Subject:PassMCSEcertification-withresultasproof-InstantDownload5857
Date:Tue,13Aug200209:17:00+0000(UTC)
Organization:Subscriber of Pacific Internet
Lines:32
Message-ID:<ajaiqc$k1n$1445@ nobel.pacific.net.sg>
NNTP-Posting-Host:adsl198.dyn203. pacific.net.sg
X-Trace:nobel.pacific.net. sg102923022020535210.24.203.198(13 Aug 2002 09:17:00GMT)
X-Complaints-To:usenet@nobel.pacific.net.sg
NNTP-Posting-Date:Tue,13Aug200209:17:00+0000(UTC)
X-Received-Date:Tue,13Aug200210:22:29BST(news-lhr.blueyonder.co.uk)
Xref:news-lhr.blueyonder.co.uk alt.pub.kacees:3217537
 
<snipmessagebody>

The "X-Trace" line says that the post was made from IP 210.24.203.198via the Newsswerver nobel.pacific.net.sg.

The "Path:" header must be read right-to-left, and analysed left-to-right,in an analogous way to the "Received:" header of an E-mail. Firstly,we split the path at the "!" characters:

news-lhr.blueyonder.co.uk
news-hub.cableinet.net
blueyonder
newspeer1-gui.server.ntli.net
ntli.net
news.stealth.net
news.stealth.net
nobel.pacific.net.sg
not-for-mail

Reading down, the message was retrieved from news-lhr.blueyonder.co.uk.It arrived there via, in order, the servers and peers listed (the last, "not-for-mail",is an historical entry from the days when Usenet and Mail were both transferred between UNIX systems by UUCP, and the "Path:" header was being usedby some lazy people to route their E-mails. Putting "not-for-mail"apparently cured them of their laziness…)

There’s nothing in that path that appears inconsistent with routing a Usenet message from Singapore to the UK, so we will have to take it on trust that it’s wholesome and truthful.

So, the ISP responsible for accepting the posting is pacific.net.sg("nobel" is the server name), and it is reasonable to assume that the source IP of the message was 210.24.203.198.

dnsnobel.pacific.net.sg
Canonicalname:nobel. pacific.net.sg
Addresses:
192.169.41.193
 
nslookup192.169.41.193
Canonicalname:nobel. pacific.net.sg
Addresses:
192.169.41.193
 
nslookup210.24.203.198
Canonicalname:adsl198.dyn203. pacific.net.sg
Addresses:
210.24.203.198
 
dnsadsl198.dyn203.pacific.net.sg
Canonicalname:adsl198.dyn203. pacific.net.sg
Addresses:
210.24.203.198

Those DNS and rDNS lookups are self-consistent, so abuse reports go to:

whois-hwhois.abuse.netadsl198. dyn203.pacific.net.sg...
abuse@pacific.net.sg(forpacific.net.sg)

whois-hwhois.abuse.netnobel. pacific.net.sg...
abuse@pacific.net.sg(forpacific.net.sg)

NOTE: When reporting an abusive Usenet post, you should forward the post, intact, with all its headers, and the result of an nslookup for the IP that you suspect to be the source. Do notsend the output of a whois command. Abuse desk staff are perfectly capable of doing that themselves. The reason for including the nslookup is simply to show that you’ve done your homework. Let the Abuse desk take it from there.

Remember, we cannot "blame" a person for this post, any more than we could "blame" yaohoo.com for the E-mail spam above. All we can do is report the incident to <abuse@pacific.net.sg> and let them handle it. It is quite probable that the ADSL link in question is an open proxy or relay, and that the PC located there had its resources stolen to make that post. Again, it’s not up to us to prove it or solve it, it’s down to pacific.net.sg to fix.

Top