[SpamCop-List] Re: Spamcop finding wrong source in spam

[J G]

On 6/19/2005 10:26 AM Mike Easter scribbled:

> J G wrote:
> 
>>Mike Easter scribbled:
>>
>>
>>>Bjorn Solberg wrote:
>>>www.spamcop.net/sc?id=z776345977zd805c0fb84b4d093699d28c9b8361121z
>>>
>>>That item consists of 7 Received tracelines, from the bottom up, 1
>>>bogus; 4 usc ones including the one for the source, and 2 from your
>>>own service.  SC breaks the chain prematurely on one of the usc ones.
> 
> 
>   Abbreviated Received lines *comment
>   from (bjorn.famsolberg.com [127.0.0.1]) by maui53.famsolberg.com
> *serves recpt
>   from email.usc.edu [128.125.253.78] by localhost *serves rcpt
>   from (msg-mx0.usc.edu [128.125.137.5]) by msg-store3.usc.edu *usc mta
>   from scf-fs-eri0-1.usc.edu ([128.125.253.183]) by msg-mx0.usc.edu *usc
> mta
>   from (sjes at msg-mx4.usc.edu [128.125.137.9]) by scf-fs-eri0-1.usc.edu
> *usc mta
>   from @nice2mailu.com ([222.84.29.223]) by msg-mx4.usc.edu *sourceline,
> usc mta
>   from 204.39.194.2 by nice2mailu.com *bogusline
> 
> 
>>>>Finds usc.edu (128.125.253.183) as source, but the real source is
>>>>222.84.29.223.
> 
> 
>>>You are correct about the source, the chinanet guangxi proxy/trojan.
> 
> 
>>>Those headers are fairly 'elaborate' -- the noncompliant localhost
>>>famsolberg/hekneby ones are simply ignored, but the numerous usc ones
>>>give plenty of opportunity for SC stumbling and tripping in the parse
>>>that the mailhosts configuration might help relieve.
>>>
>>>
>>
>>Another interpretation - what caused this utility to choose
>>222.84.29.223 as valid - can one say?
> 
> 
> SC broke the chain prematurely while it was going down the usc mta/s.
> Going from top to bottom in numbering, it could not connect the 4th
> 'from' field to the 5th 'by' field - or alternatively stated, it could
> not connect the 2nd down usc line to the 3rd down usc line.
> 
> 
>>The mailserver that received that mail is msg-store3.usc.edu which is
>>different from the one who delivered the mail in the previous
>>Received: line, which is email.usc.edu
>>but the ip of the previous line is on the same netblock of the one in
>>the current one,
>>The trusting level of this Received line: is 100%
>>x doesn't seem to have valid MX records
> 
> 
> I don't like the way you are going about this analysis of the hostname
> and arbitrarily assigning a trusting % level for a line.
> 
> A server may not always call itself by its rDNS, but our job is to see
> if we can parser backwards to get a frontwards analysis.  In this case,
> the frontwards analysis derived from backwards parsing is 222.84.29.223
> 
>>128.125.137.9 msg-mx4.usc.edu > 128.125.253.183 scf-fs.usc.edu >
> 
> 128.125.137.5 msg-mx0.usc.edu > 128.125.253.78 email.usc.edu > 127.0.0.1
> localhost [which is actually 69.235.29.131 mail.hekneby.org for
> bjorn.famsolberg.com] > maui53.famsolberg.com mailbox
> 
> 
>>The trusting level of this Received line: is 100%
>>x doesn't seem to have valid MX records
> 
> 
> When the item got into the usc system, it was moving thru' usc MTA
> agents.  It is possible that the USC MX might declare itself in the
> first USC line when it took the mail from the source, or it is possible
> the USC MX may never actually be seen.
> 
> 
>>The trusting level of this Received line: is 25%
>>x doesn't seem to have valid MX records
> 
> 
> Balderdash the 25%.  I don't know where you are going with 'x doesn't
> seem to have valid MX records'
> 
> 
>>204.39.194.2 is the last valid ip, probably the spammer?
> 
> 
> No.  That is a bogus line.  The way I parse those header is that the
> chain breaks for me at the transition between the 6th from and the 7th
> by;  that is the projan/proxy 222.84.29.223 no rDNS is *NOT*
> nice2mailu.com - which is 195.8.224.85 -- and further than the MX for
> nice2mailu.com is mail.wtal.de which is 195.8.224.4 -- which is such a
> bad bunch of bogosity as to be not even worth considering.
> 
> The timestamp is OK, but the forgery is no class.
> 
> 
I did not do that analysis - a utility named Abuse came up with that.
I'm not sitting here assigning probabilities - I ain't that good...
Balderdash the 25%- love it..