Re: Spamcop failing to detect true originating IP
"Mike Easter" <[email protected]>
| Newsgroups | gmane.mail.spam.spamcop.help |
|---|---|
| Organization | SpamCop |
| Message-ID | <[email protected]> |
wskrispy wrote: > Hold on a sec Ellen and N. Miller-- if you look at the entire message > at tracker > http://www.spamcop.net/sc?id=z785186974zfb5c4d04f5694f362a90b200bac251bfz;action=display > you will see that in the header block below the SA Content Analysis > there is a third Received header which does in fact identify the > connecting IP (85.40.108.210). Why didn't Spamcop use this and > proceed? Actually what you are describing as a 'third Received header' is a /first/ Received header traceline of the *original* item, which your provider's server calls Content-Description: original message before SpamAssassin of the mime structure of the attachment. That's what I was describing in news:[email protected] Mike Easter wrote: > This structure is thus found: > > topheaders > body1 > attachment headers > body2 > AVG info > whereas the attachment headers show the source > IP of the propagation. <resume wskrispy wrote:> > Ellen said "For some reason and for some spams, your server will > print 2 received headers as above rather than showing the connecting > IP as it does for other spams". This is not so. All these spams have > this header block eventually showing the connecting IP. You are saying that all of 'these' spams have attachment headers which show the source IP just like the example item which is actually a viral propagation, not a 'simple' or regular spam per se. Then all you will have to do is find a technique to isolate those original 'attachment' headers, which are also contiguous with the spambody [see body2 above], to submit to the parser. In such isolation, the parser can not only find the source IP but also any contained spamvertiser URLs. -- Mike Easter kibitzer, not SC admin