Re: Reporting My own IP?

Mike Easter wrote:
> 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

Some people hate my abbreviated Received lines, but I think they help to
understand the 'from' to 'by' chaining.

The configuration of your totalsystemcontrol and speakeasy server's is
to make the tracelines like this:

from helo (rDNS [IP]) by domainname

and SC 'associates' the 'from' IP of the upper field with the 'by'
domainname of the lower field.

But 64.81.88.120  is not Server-03.DMIndustries.NET  - so that's the end
of the line, and SC sez:

.... oops.  Things have changed since the first time I looked at this,
SC is beginning to figure things out, but it still gets the parse wrong

64.81.88.120 is an MX for Server-03.DMIndustries.NET
   Chain test:Server-03.DMIndustries.NET =?
dsl081-088-120.lax1.dsl.speakeasy.net
   host dsl081-088-120.lax1.dsl.speakeasy.net (checking ip) =
64.81.88.120
   64.81.88.120 is an MX for Server-03.DMIndustries.NET
   64.81.88.120 is mx
   Server-03.DMIndustries.NET and dsl081-088-120.lax1.dsl.speakeasy.net
have close IP addresses - chain verified
Possible relay: 64.81.88.120
64.81.88.120 not listed in relays.ordb.org.
64.81.88.120 has already been sent to relay testers
Received line accepted

... now that SC has gotten the situation about speakeasy and
dmindustries misconfiguration figured out, it should be able to
successfully get down to the 2nd line where the source is, but it blows
it while I'm looking right now and still names speakeasy

Report Spam to:
Re: 64.81.88.120 (Administrator of network where email originates)
   To: [email protected] (Notes)

... now I've cancelled the report, and I'll access the tracker yet again
to see if it gets it right;  because the parser reparses the item
everytime it is accessed.

Here is where SC is screwing up

Received:  from carmen017.9opica.com (HELO coa05.topica.com
[4.221.24.168]) by sandblast017.1opica.com (tournamentTV_Wostfix+sws)
with SMTP id F0A0EFE1F for <x>; Sun, 13 Mar 2005 00:29:28 -0200
4.221.24.168 found
host 4.221.24.168 = dialup-4.221.24.168.Dial1.Dallas1.Level3.net
(cached)
dialup-4.221.24.168.Dial1.Dallas1.Level3.net is 4.221.24.168
61.83.201.212 not listed in dnsbl.njabl.org
61.83.201.212 listed in cbl.abuseat.org ( 127.0.0.2 )
Open proxies untrusted as relays
61.83.201.212 discarded as a forgery, using 64.81.88.120

In the topmost part, SC is examining the bogus line.  Then, below that,
SC is 'thinking' about the line which came above the bogus line.  In the
'thinking about' the sourceline, SC recognizes that 61.83.201.212 is a
proxy IP, but somehow it jumps all the way back to the top line and
names the speakeasy even after it has resolved the misconfiguration
problem.

Dumb parser.  I don't know why it is doing that right now.


-- 
Mike Easter
kibitzer, not SC admin