Re: Reporting My own IP?

The Father Mind of DM Industries wrote:
> I attempted to post in the Reporting forum as I saw a post with the
> similar problem but it seems I do not have permission to post there.

You have to register to post there.  I've never registered or posted
there.  I prefer to interact in newsgroups.

> Here is my problem.
> 1. I have accidentally reported my own Servers IP a few times.

Don't do that.  You should know what/who 'you' and your provider are.
You should know/understand enough about headers that you have a clue
about what is going on in the Received lines and who your own provider
is, even if the provider's 'name' might be obscured or misleading in its
Received traceline's configuration.

> And
> once my desktop IP.  I understand what I did wrong for my desktop IP
> but not for the Server IP.

Don't do that either.

> It seems that if I move the bottom header
> line (with the real source IP) to the top of the header when I
> manually report it, then it fixes the problem.

Don't do that either.  Good grief!  You can't go around re-manufacturing
ie forging headerlines for reporting.  Some of 'us' [at least me] forge
headers 'experimentally' - but not for reporting.  If you or I forge a
header we must cancel it;  it is against the rules to do material
changes to a spam http://www.spamcop.net/fom-serve/cache/283.html
Material changes to spam

>  I am pulling this
> from Outlook Express 6.

You have attached a uuencoded .eml to your post here.  That is also a
'relative' no-no.  The best way to communicate about a specific spam
parsing is to submit it to the parser, copy the tracking URL to paste
here to discuss, and not be posting spam or attachments in this
newsgroup.  Once upon a time the newsgroup .spam was for posting spam,
but the tracker is better.  The subject of attachments and uuencoding is
another topic that I'll save for later after discussing the problem you
are asking about.

This is the tracker of the spam you attached to your message and this is
what you should've posted instead of what you did
www.spamcop.net/sc?id=z741670376z53404350a858828ce0e0d17543fc1e06z

I like to talk about parsing problems by abbreviating the salient parts
of the headers like this:

  Abbreviated Received lines *comment
  from Server-03.DMIndustries.NET (dsl081-088-120.lax1.dsl.speakeasy.net
[64.81.88.120]) by mail-in.totalsystemcontrol.com *serves you
  from 64.81.88.120 (unknown [61.83.201.212]) by
Server-03.DMIndustries.NET *sourceline, bogus helo
  from carmen017.9opica.com (HELO coa05.topica.com [4.221.24.168]) by
sandblast017.1opica.com *bogusline

> I found that forwarding eMails as an
> attachment resolves the problem most of the time but not all of the
> time.

The only you can submit to the parser is by pasting into the webparser
or email forwarding as an attachment.  There is no other alternative.

> I have attached one eMail header that is not working when I
> paste it or forward it.

You have attached a uuencoded spam, not header, and the parser breaks
the chain prematurely because of a misconfigured server which serves
you.  If you are going to submit items from misconfigured servers, you
are going to have to use a properly configured mailhosts system which
can overcome such foibles.

> Can some one tell me is this something I am
> doing wrong or a flaw in the SpamCop logic system? (Note my Servers
> IP is
> 64.81.88.120)

The problem is in the configuration of  64.81.88.120  rDNS
dsl081-088-120.lax1.dsl.speakeasy.net  which is calling itself
Server-03.DMIndustries.NET in the 'by' field and its helo.  The helo
isn't a problem, the problem is the 'by' field configuration.

If you look at the 3 lines of Abbreviated Received headers above and if
you also look at the verbose of the parse which can be seen by clicking
on the tracker link above if you have configured your preferences for
Show Technical Details during reporting in the Report Handling Options
you will see how SC parses.

SC parses by chaining backwards from top toward the bottom until the
first sign of bogosity by chaining from the upper 'from' field to the
lower 'by' field.  In the case of the misconfigured server, SC considers
64.81.88.120  to be dsl081-088-120.lax1.dsl.speakeasy.net -- not
Server-03.DMIndustries.NET -- which is found in the 2nd 'by' field, so
it has to break the parse chain prematurely and name the speakeasy
server.

In SC's parse, it names the speakeasy as source, but the source should
be 61.83.201.212  no rDNS  at kornet which is using the bogus helo of
your server's IP.  That IP is listed on some blocklists, including cbl
which is a sign of a proxified IP hitting spamtraps.


-- 
Mike Easter
kibitzer, not SC admin