[CLUE-Tech] SMTP Envelope Question

[Jed S. Baer]

Kirk Rafferty, et. al.  wrote:

> First, (and you probably know this already) Received: headers can
> be easily inserted into a spam.  That's why you have to work your way
> backwards from the Received: header that shows delivery to your machine.
> Once you hit a Received: header that doesn't follow the trail, it's
> a fake.

Actually, what I've read to this point had me believing that Received:
headers were the only _really_ reliable part of the mail envelope, being
generated by the MTA, rather than the MUA. Not that I've ever actually
studied SMTP, just absorbed the useful bits from the various spam-fighter
howto dox running around on the web.

> So, assuming that the Received: header you've provided is a real header,
> the next rule is never trust the domain in a Received: header.  It can
> be easily faked, because it's the domain that the mailserver is
> reporting itself as.

Now that folks have mentioned it, I do recall reading something about
that. I guess in the past, since I didn't have anything to attach it to,
it didn't lodge itself in long-term memory (lost on reboot ;-).

>  What's much harder (impossible?) to fake is the IP
> address. Again, assuming that the header you provided is real, it looks
> like the spam originated (or at least relayed through) 156.148.56.6. 
> Don't be thrown by the CERN ownership.  They're just as susceptable to
> bad administrators as anyone else.  Or it could be a leased address.

Yeah, the first thing that came to my mind was that somebody goofed and
config'd an open relay.

> The "(8.9.3/8.9.3)" part is the Sendmail version that the receiving
> machine is reporting.

And now that I know what it is, I see it all over the place. I guess I
hadn't noticed it before, since the other parts of the headers made sense.
And this time I was looking for more info.

Since Frank asked for the whole chain, here it is (up to my ISP, which
operates mailarmory.com -- everything from there up is reliable).

Received: from pcp526831pcs.nash01.tn.comcast.net
(pcp526831pcs.nash01.tn.comcast.net [68.52.151.225])
	by ma101.mailarmory.com (Postfix) with SMTP id 40AAF788EC
	for <THAG at FRII.COM>; Sun, 10 Nov 2002 13:59:02 -0700 (MST)
Received: from cox.net (3875 [75.82.230.180])
    by  turpin.freeserve.co.uk (8.12.1/8.12.1) with ESMTP id 3256
    for <THAG at FRII.COM>; Sun, 10 Nov 2002 15:58:04 -0500
Received: from redshift.com ([156.148.56.6])
    by betades.freeserve.co.uk (8.9.3/8.9.3) with SMTP id 30243
    for <THAG at FRII.COM>; Sun, 10 Nov 2002 15:58:04 -0500

So then, working back, the chain is broken in the 2nd line, because the
"by" (turpin.freeserve.co.uk) isn't the same as the "from" (comcast.net)
in the 1st. The relation between 2nd and 3rd suffers from the same
discontinuity.

Making matters even worse:
$ whois 75.82.230.180 at whois.arin.net
[whois.arin.net]

OrgName:    Internet Assigned Numbers Authority 
OrgID:      IANA

NetRange:   70.0.0.0 - 79.255.255.255 
CIDR:       70.0.0.0/7, 72.0.0.0/5 
NetName:    RESERVED-7
NetHandle:  NET-70-0-0-0-1
Parent:     
NetType:    IANA Reserved
Comment:    
RegDate:    
Updated:    2002-09-13

OrgTechHandle: IANA-ARIN
OrgTechName:   Internet Corporation for Assigned Names and Number 
OrgTechPhone:  +1-310-823-9358
OrgTechEmail:  res-ip at iana.org

Thanks all, for the helpful info so far.

Can I conclude from this that comcast is most likely operating an open
relay?

jed
-- 
We're frogs who are getting boiled in a pot full of single-character
morphemes, and we don't notice. - Larry Wall; Perl6, Apocalypse 5