Re: Email Virus

From: devil (devil@attglobal.net)
Date: 07/08/02


From: devil <devil@attglobal.net>
Date: Mon, 08 Jul 2002 03:35:25 GMT

Rod Smith wrote:
> In article <slrnaihq0d.rch.mlake@melake.erols.com>,
> Marshall Lake <mlake@melake.erols.com> writes:
>
>>>Reading headers is easy enough.
>>>You read from the bottom up.
>>>Each Received is a postmaster receiving the message with
>>>the information of who the message was relayed from with
>>>who it is to be sent to.
>>>
>>>Only the postmaster on the first hop
>>>can use the Message ID to see who realy sent the message.
>>
>>Here are the headers from one such eamil I received. What is the
>>originating site? verizon.net ?
>>
>>
>>Return-Path: <res038yp@gte.net>
>>Delivered-To: mlake@melake.erols.com
>>Received: from out017.verizon.net (out017pub.verizon.net [206.46.170.94])
>> by melake.erols.com (Postfix) with ESMTP id 5FED71B8CD
>> for <mlake@melake.erols.com>; Sun, 7 Jul 2002 12:42:49 -0400 (EDT)
>>Received: from Izmnsyso ([216.193.162.173]) by out017.verizon.net
>> (InterMail vM.5.01.05.05 201-253-122-126-105-20020426) with SMTP
>> id <20020707164139.HXLS21993.out017.verizon.net@Izmnsyso>
>> for <mlake@melake.erols.com>; Sun, 7 Jul 2002 11:41:39 -0500
>
>
> This is the first Received header. It indicates that 216.193.162.173,
> which identified itself with a fake or incomplete hostname ("Izmnsyso")
> sent the message to a computer that's identified itself in the message
> header as out017.verizon.net but didn't include an IP address. You'd
> need to use tools like host, nslookup, or whois to figure out who "owns"
> 216.193.162.173. For instance:
>
> $ host 216.193.162.173
> 173.162.193.216.IN-ADDR.ARPA domain name pointer pqmax-2-25.dialup.enter.net
>
> This seems to suggest that somebody using a dial-up account with the
> enter.net ISP is the true sender.
>
> One caution: Received headers can be forged. Spammers sometimes insert
> a fake Received header before (that is, later in the file) than the
> first legitimate one. This is usually easily spotted by a gap with
> other headers between Received headers. The first (that is, last in the
> file) Received header might also point to a machine under the control
> of whatever bad guy you want to avoid. As a general rule, the most
> trustworthy Received header is the last one (that is, the top one in the
> file), which usually tells you the system from which your ISP or mail
> server received the message. Anything earlier than that could
> conceivably be at least partly forged.

True. But you almost invariably can tell: something doesn't fit. At
some point upstream, some header will tell the truth and a mismatch will
be apparent.

Anyway, it doesn't seem to be the case here. Source is almost certainly
enter.net.



Relevant Pages

  • Re: Setup problem with SenderID and OWA
    ... >mail with OWA. ... of the Exchange server, not the IP address of the machine running the ... >Sample SMTP Header from Exchange server.... ... surely isn't the one inserted by the receiving server. ...
    (microsoft.public.exchange.admin)
  • Re: Lynn at garlic.com
    ... please not that the only part of the e-mail I am receiving is from my ISP telling me that a virus has been deleted. ... it is probably somebody impersonating "lynn@xxxxxxxxxx" (that ... header information (many don't bother since ...
    (bit.listserv.ibm-main)
  • Re: Spoofing "TO" Address in email
    ... >>As a test, I sent myself an email without addressing the TO field at all, ... >>Doesn't the recipient's email address have to be in the header SOMEWHERE ... >>in order for the recipient to actually receive it? ... >>receiving an email as a BCC recipient if sent from Road Runner email ...
    (alt.computer.security)
  • Re: Spoofing "TO" Address in email
    ... value may not show up in any header. ... >receiving an email as a BCC recipient if sent from Road Runner email ... between the sending mail server ... "RCPT TO:" which is what actually controls delivery only gets passed ...
    (alt.computer.security)