[SpamCop-List] Re: Mail Admin Reply...

[J G]

On 7/3/2005 1:14 PM Mike Easter scribbled:

> J G wrote:
> www.spamcop.net/sc?id=z781639333z0cb4ca8a5a8832a64cdc77c79a0458eaz
> 
> 
>>This was an attempt to report the redirection bounce.  The 1st one was
>>rejected by my ISP
> 
> 
> That is a complicated structure with 6 sets of headers, I'll number them
> from 1 to 6 from the top down.  It would probably be better to start
> from the bottom, so I'll start from the top :-)
> 
> At the top #1 is the header put directly in your mailbox by your cox
> system, no Received line in which cox is telling you it can't mail the
> item, but the submission to the parser obfuscated the To:
> 
> Jumping down to the bottom #6 is the header of a spam sourced at/from
> 219.128.170.142 a multilisted .cn proxytrojan -- no body -- handled by
> an amadis.com server for recipients.  That spam header was emailed as a
> newmail DSN by the amadis to a cox account, presumably yours.

What was sent to me was the misdirect bounce, not the spam, but for what
I can tell, that could be what you are saying.

> 
> The next thing up the structure we see is you #5 trying to forward that
> mail to several addresses which the parser has munged out, and cox is
> trying to tell you that all of those addresses, whatever they are, are
> no good for various reasons, deactivated mailbox x 2, not a valid
> mailbox x2.

As mentioned in another post, I was using SpamID to parse the misdirect
because it correctly, I believe, identified the source and automatically
supplied abuse addys to Lart to - also as previously stated, I do not
have the experience you do and need to rely on those addys as correct,
but it seems we are all dealing with moving targets here which makes
comprehension difficult at best.  Net, net, SC just serves up the sender
of the misdirected bounce,, which is about al I can say I can do myself.
 The only munging being done by this whole process is SC - everything I
send with SpamID goes out raw.  And the mails to Cox in this case are
just my cluing in their spam report desk, not their abuse desk.

> 
> The MTA which is telling that information is 66.28.189.140  rDNS
> mw140.mail2world.com  so apparently those addresses must've called up
> that MX for some reason that I don't know.

not do I - sorry to say this is where it becomes greek to me...

> 
> Now, jumping back up to the top #2 to find out what cox was telling you
> it couldn't mail we find you trying to mail something to 5 different
> obfuscated x/s and calling it a misdirected bounce, but the misdirected
> bounce you are trying to report is your own provider telling you that it
> can't mail something, which is header #3.

that is pretty obtuse, but, again, net net, could be me shooting myself
in the foot and hitting my brain...

> 
> So, now that we're closing in on the middle, I'll list the headers from
> top to bottom.
> 
>  - internal cox to you
>  - you trying to email
>  - internal cox to you
>  - you trying to email
>  - misdirected bounce
>  - original spam headers
> 
> In this case, feeding such a thing to the parser makes things more
> confusing than they would have been if you had posted it in .spam,
> because the parser munges out all of the important <x> addresses which
> are causing the problem.
> 
> The problems are several, not the least of which is you trying to report
> your own provider for 'misdirected bounces' when it is telling you that
> it can't complete the mail the way you have addressed it.
> 
> In all of those headers, there is only one which belongs to a
> misdirected bounce;  that is #5, all the rest of the headers are due to
> you doing something wrong.
> 
I have a headache - I have many more screwups to perform before I rest...
Are you in the CIA??
p.s.  Thanks for the efforts - you do your Phd thesis on this stuff?