Re: Obvious manipulation of e-mail headers - what good are they?

From: Jeff Cochran (jeff.nospam_at_zina.com)
Date: 04/29/05 

Date: Fri, 29 Apr 2005 19:28:29 GMT

On Thu, 28 Apr 2005 22:30:20 -0400, "Karl Levinson, mvp"
<levinson_k@despammed.com> wrote:

>Perhaps you are assuming the weird %VARIABLE% stuff in the headers indicates
>that the sender can manipulate what is in the headers. This is not the
>case. The sender can only add garbage to the bottom of the headers, but
>this is usually obvious and fails to fool someone who knows how to check
>them. ISPs know this and have been dealing with this for a while, and would
>usually not use this as a way to claim spam did not come from them.

As a matter of course, spoofed or falsified headers often trigger
ISP's SPAM filtering, and get the messages rejected. ISP's are very
keen on the SPAM issues, since consumers don't want it to get through
and being blacklisted by other ISP's is a death sentence.

Jeff

 The
>ISPs aren't held liable for spam, nor are they required to investigate or
>respond to your spam reports, so they would just as easily ignore your spam
>report. They have no need to lie about whether they sent spam or not. Such
>lying wouldn't keep them off of DNS black lists either.
>
>I wouldn't worry about the spammer being able to add to the Received From:
>header. That's been the case for years and is nothing new. It's due to the
>way the decades-old SMTP protocol works. It is still possible to determine
>where a spam came from, more or less. At some point, the headers start to
>be real, and you can often tell where by doing a ping -a against both the IP
>address and the alleged server name and comparing all the results to see
>whether they are a credible match, for example.
>
>It has been hard to catch spammers for years, but the reason why doesn't
>have much to do with the ability to forge headers. A bigger problem is that
>a spammer can use Trojan-infected workstations to 1) send spam and 2) to
>chain together a series of proxies to conceal her true location. There are
>other problems.
>
>For example, it is a pretty good guess that this SMTP email originated from
>84-121-165-206.onocable.ono.com (84.121.165.206). The fact that this IP
>probably represents an innocent person with an infected computer and
>wouldn't help you determine where the spam really came from has little to do
>with the headers being forged.
>
>So I guess you're right that there is a problem in that spam is hard to
>trace back, but it's not a new problem or a problem I would get too upset
>over.
>
>
>"George Hester" <hesterloli@hotmail.com> wrote in message
>news:ubMGVLFTFHA.2548@TK2MSFTNGP14.phx.gbl...
>I did not post all the headers because that was not necessary for my point.
>But if you want them here they are I don't see how the rest of them say
>anything about the %RANDOMIZATION% that is being used here:
>
>Return-path: <iheskhfcbe@action.com.au>
>Received: from ms-mta-03 (ms-mta-03-smtp [10.10.4.10])
> by ms-mss-01.nyroc.rr.com
> (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005))
> with ESMTP id <0IFM003G4Y3VVL@ms-mss-01.nyroc.rr.com>; Wed,
> 27 Apr 2005 22:40:46 -0400 (EDT)
>Received: from orngca-mx-03.mgw.rr.com
> (orngca-mx-03.mgw.rr.com [66.75.160.130]) by ms-mta-03.nyroc.rr.com
> (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005))
> with ESMTP id <0IFM00L0XY19O9@ms-mta-03.nyroc.rr.com>; Wed,
> 27 Apr 2005 22:39:15 -0400 (EDT)
>Received: from 84-121-165-206.onocable.ono.com (84.121.165.206)
> by orngca-mx-03.mgw.rr.com with SMTP; Wed, 27 Apr 2005 22:40:28 -0400
>Received: from %STATIC_3WORD
> (IMLI-852-880.%S_1FROM_DOMAIN [%LIST_IP] (may be forged))
> by %STATIC_2WORD.%S_1FROM_DOMAIN (MOS 3.3.6-GR)
> with ESMTP id DLT75284 (AUTH %STATIC_3WORD-02) ; Thu,
> 28 Apr 2005 01:37:32 -0200 (IST)
>Date: Wed, 27 Apr 2005 22:39:15 -0400 (EDT)
>Date-warning: Date header was inserted by ms-mta-03.nyroc.rr.com
>From: Martha Peck <iheskhfcbe@action.com.au>
>Subject: Message subject
>To: dverdow@nycap.rr.com
>Message-id: <3kmqqq$ehe806@orngca-mx-03.mgw.rr.com>
>MIME-version: 1.0
>Content-type: TEXT/PLAIN
>Content-transfer-encoding: 8BIT
>
>My point being this allows the ISP of the spammer to deny they are part of
>the problem. Call it a rant if you choose some rants are true you know.

Relevant Pages

  • Re: Junk Email - Obvious SPAM being overlooked
    ... The RFCs do not define what constitutes SPAM. ... The actual routing of the email is indeed included in the message headers. ... Now, while it is true that I am a single recipient of the email, I own my ... filter them out, and certainly *not* harmful. ...
    (microsoft.public.outlook)
  • Re: Obvious manipulation of e-mail headers - what good are they?
    ... > that the sender can manipulate what is in the headers. ... ISPs know this and have been dealing with this for a while, ... > usually not use this as a way to claim spam did not come from them. ... > I wouldn't worry about the spammer being able to add to the Received From: ...
    (microsoft.public.security)
  • Re: Cant copy "Message Source" area ?
    ... It didn't bring up the message source. ... > into the spam for the ISP to block them? ... The people designing the filters want to see the full headers ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Amazing offer on Glucosamine,Fishmeal & Refined fish Oil, Chitin, Chitosan and Squid meal
    ... Newsgroups: alt.support.mult-sclerosis ... If you are using a newsreader, simply copy the headers above, paste them ... "Spam - Spam is strictly prohibited on our servers. ... "Hosting Policy - Data Unlawful or Against the Terms of Service: ...
    (alt.support.mult-sclerosis)
  • Re: Spam and using a real email address
    ... the person who had reported on individual modems. ... run into spam filters, or firewalls - it's a "best effort" mechanism ... to look at the headers on the POP server, ... still seeing maybe one in twenty that get past the filter being spam. ...
    (news.software.readers)