Re: Tracing IPs

From: WinGuy (no_spam_at_nomail.bot)
Date: 06/29/04


Date: Tue, 29 Jun 2004 01:04:17 GMT


"George Del Monte" <green.eggs@ham.net> wrote in message
news:u6kzRPUXEHA.3676@TK2MSFTNGP09.phx.gbl...
> The reason I asked was because, even though I have Norton AV with
up-to-date
> virus definitions which quarantines most viruses (some seem to get by for
> legit reasons) I keep getting viruses. It just aggravates me that some
> scumbag keeps trying futilely sending me viruses. I KNOW it's not from a
> "friend's" computer that's infected, because through persistent detective
> work, I discovered that two cyberbuddies' computers were infected and
helped
> them clean the infections. I have been on a rampage lately, sending
> messages, including message headers, to the ABUSE people at various ISPs.
I,
> of course, do not absolutely know if I'm chasing the guilty parties.
> Occasionally, I receive a message from an IP that I cannot get a Host Name
> (I've been using "IP Search Toolbar"). If the scumbag is domestic, then
I'd
> (wishfully) like to have his or her ISP shut them down. That has been my
> motivation. Until sender verification technology is a done deal, I'll just
> have to do the best I can.

Ok, then you're talking about how easy is it to spoof an originating IP
address of an email. That narrows the request reason down a bit. Basically,
any machine sending an email may claim in its initial connection
transaction, specifically its HELO or EHLO transaction, to be absolutely any
domain name or IP address. I think RFC says that transaction should be a
fully qualified domain name but also says that if that transaction does not
resolve back to the actual IP address of the machine that is doing the
connecting then the email must not be refused for that reason alone. Of
course site policy can over ride that because a site is not required to
accept an email and may refuse to do so for any reason, but RFC is intended
to be followed or great confusion might result and mail would not get
delivered.

So there basically is no way to assure that the machine doing the connecting
to deliver an email is who it claims to be. Especially where one machine
hosts multiple domain names, perhaps very legitimately, but only one of
those domain names will resolve to that machine's assigned IP address. So
comparing the IP address of the connecting machine against the resolved IP
address of who it claims to be in its HELO/EHLO transaction is not a
dependable way to assure that an email is being sent spoofed, because in
fact there may be no spoofing at all occurring. So RFC says not to refuse
mail on that basis.

Which leaves the FROM address. This is what gets spoofed the most. Easiest
way is for a spammer or virus to "bounce" a message as undeliverable to some
email server as being "from" some sender that the target email server knows
nothing about and so that email server itself bounces the bounce "to" the
spoofed "from". There is no built in way, currently, to guarantee that the
"from" is where the email really came from. That's why there are moves right
now to modify how email is "verified" in some way when it is sent so that
upon reception that verification can be validated. There are some competing
models for doing this that are currently being consolidated.

It's hard to look at headers to determine where an email originated from,
because the beginning part of the header can itself be spoofed to make it
look like the email had been originated elsewhere and merely handled by the
machine that turns out to be the one that actually originated it. A spammer
could "pad" the header to make it look like it originated from some other
machine.

So this is basically why we have the problem we now have with spam and virus
via email activity. The original system put into place for email did not
anticipate the kind of abuse it is now subjected to. But solutions are in
the works, although not that's not of much comfort for now. Keep your
antivirus updated and use it. Use something like K9 or PopFile and train it
to recognize the difference between mail that you want versus mail that you
don't want.



Relevant Pages

  • Re: Gridlock script rewrite
    ... an other and then the virus would not be able to survive. ... There was no dramatic reversal to do with Gallifrey. ... the reason inadequate, but you can not deny that there is a reason, ... only supposed to use bricks that are the same colour on each level otherwise ...
    (rec.arts.drwho)
  • Re: SPF = Sender Policy Framework
    ... image, even if it's ntyo a web bug, is *NOT* within reason). ... seen a virus with "real" content yet). ... If it's sent to a real account, ... Solid Web hosting, responsive support, effective spam-blocking. ...
    (comp.os.linux.misc)
  • Re: 5 Cosmic Events That Could Kill You Before Lunch
    ... :A complete virus has not yet been constructed from a gene synthesiser ... :although there is no in principle reason why you can't. ... The US 'smallpox stocks' are one of two legally held samples (the ...
    (sci.space.policy)
  • Re: Antivirus?
    ... > The reason is because the mail server will transfer files along with the ... The virus scanner should be set ... > to open the mail as it passes through your linux system and remove any ... > don't have any need for antivirus whatsoever. ...
    (alt.os.linux)
  • Re: Why the obscurity myth does not explain Mac OS X malware
    ... To write a virus for a decent OS, you probably have to be pretty fluent ... I'm sure that much less than 5% of programmers program for the Mac even ... which is almost always writing for Windows. ... the reason is its based on Unix. ...
    (comp.sys.mac.advocacy)