Re: Is this for real?
"Mike Easter" <[email protected]>
| Newsgroups | gmane.mail.spam.spamcop.help |
|---|---|
| Organization | SpamCop |
| Message-ID | <[email protected]> |
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