[SC-Help] Re: Is this for real?

[Mike Easter]

BMW wrote:
> Help me read this header it looks like emc.emc.com.tw then received
>   this from spamcop.net (192.168.33.104)

Don't start at the bottom and go up.  Start at the top and go down,
chaining from an upper 'from' field to a lower 'by' field watching for
the first sign of bogosity -- where the chain breaks.  Brian's
asterisked annotations of the header are correct.

> (an unroutable LAN address),
> then emc.emc.com.tw. (192.168.10.1) (another unroutable LAN address)
> sent it
> to emclog.emc.com.tw, then emclog.emc.com.tw (192.72.220.9) sent it to
> blade5.cesmail.net (the spamcop mail server). . . I did read this
> right, RIGHT?

Well, you read the last part correctly, which is where to start.  The
uppermost Received headerline is the reliable part.  You are trying to
figure out how far down the reliability goes.

I like to depict them like this:

  Abbreviated Received lines *comment
  from unknown (192.168.1.101) by blade5.cesmail.net *serves you
  from emclog.emc.com.tw (192.72.220.9) by mailgate.cesmail.net
*sourceline, server
  from emc.emc.com.tw (emc [192.168.10.1]) by emclog.emc.com.tw *bad or
bogusline
  from spamcop.net ([192.168.33.104]) by emc.emc.com.tw *bogusline

After the headers come a 3 part message body in mime delimitors, whose
parts consist of plaintext antiviral characterization & deletion info,
html viral propagation body, and plaintext antiviral filename & deletion
info.

>From the appearance of the structure, my guess would be that the
original item was a viral propagation pretending to be From SC webmaster
addressed To rwcs and containing body information claiming to be from
spamcop and having an attachment named account-report.zip which archived
a mytobe worm in an executable .pif file disguised as a .doc file.

When the propagation passed thru' the emc .tw server, its AV agent
stripped the attachment and continued the item on to you.  In doing so,
it also stripped the original Content-type line and replaced it with its
own.  That seems like a rather bizarre behavior, but I have seen it
before.

The original propagation headers contained a bogusline.  The .tw
server's line is flawed, noncompliant.  There /is/ an smtp server at
192.72.220.9 rDNS emclog.emc.com.tw  which does not relay promiscuously,
but refuses to be manipulated and quits after a few tries.


-- 
Mike Easter
kibitzer, not SC admin