ankman Posted March 2, 2009 Posted March 2, 2009 I'm not sure if this was discussed before, didn't quite know what to search for. I got this header line, amongs others I ommited. My addy is at spamfence.net, so we can trust this line. Received: from 222.50.91.253/32:9985 (from=<ezarjs[at]hexz.org>;helo=hexz.org) by eXpurgate V2.1.1.1, id=expurgator37/090302145317-5EB138E0-F07C2428 for <$my_addy[at]spamfence.net>; Mon, 02 Mar 2009 14:53:17 +0100 Spamcop failes here. It works if I manually remove the "/32:9985". Btw. spamfence (eXpuregate) also fails detecting this spam with Chinese characters too.
Farelf Posted March 2, 2009 Posted March 2, 2009 ... Received: from 222.50.91.253/32:9985 (from=<ezarjs[at]hexz.org>;helo=hexz.org) by eXpurgate V2.1.1.1, id=expurgator37/090302145317-5EB138E0-F07C2428 for <$my_addy[at]spamfence.net>; Mon, 02 Mar 2009 14:53:17 +0100 Spamcop failes here. It works if I manually remove the "/32:9985". I'm not surprised at the failure, those eXpurgator lines are totally whacky. IP address 222.50.91.253 is thoroughly listed on the SCBL with both spamtrap and member hits. So it certainly seems the receiver line is at fault in your case. If you already have mailhosts set up you need some other sort of routing through eXpurgator so SC can ignore it as internal. Here is an example of that, borrowing a Google groups spam posting: http://www.spamcop.net/sc?id=z2662655082zc...5dd4e75b4111d4z Unfortunately the parser fails spectacularly in finding the spam source in the above example, but it would all be different with mailhosting set up. [on edit - ah, it changed its mind and got it right after all - probably something to do with relay testing.]
Wazoo Posted March 2, 2009 Posted March 2, 2009 I'm not sure if this was discussed before, didn't quite know what to search for. I got this header line, amongs others I ommited. My addy is at spamfence.net, so we can trust this line. What would be much more helpful would be the Tracking URL ... although admitting that the addition of an IP Block range and port number seems very odd, definitely not RFC compliant .... However, also noting that your identified changes to header content is addressed within Material changes to spam which involves breaking the rules which can be dangerous to your Reporting Account. If needed, please also see Getting a Tracking URL from a Report ID
Wazoo Posted March 2, 2009 Posted March 2, 2009 I'm not sure if this was discussed before, didn't quite know what to search for. Only now noting that this was posted into the Forum section set-up for issues with a SpamCop.net e-mail account. I don't see the linkage, so with this post, moving this Topic to the Reporting Help Forum section.
ankman Posted March 3, 2009 Author Posted March 3, 2009 What would be much more helpful would be the Tracking URL ... although admitting that the addition of an IP Block range and port number seems very odd, definitely not RFC compliant .... However, also noting that your identified changes to header content is addressed within Material changes to spam which involves breaking the rules which can be dangerous to your Reporting Account. If needed, please also see Getting a Tracking URL from a Report ID http://www.spamcop.net/sc?id=z2665725276z0...c4eb5e0b0200b4z (which I didn't sent then) Spamfence is added to my mailhosts since months. And 194.145.224.20 is in my list as I just verified. Spamcop admins might want to have a look (permission granted herby :-) into my accounts what could be wrong.
SpamCopAdmin Posted March 3, 2009 Posted March 3, 2009 Received: from 222.50.91.253/32:9509 (from=<ryyy[at]jk.net>;helo=jk.net) by eXpurgate V2.1.1.1, There isn't anything wrong with the parse. SpamCop simply doesn't see that "Received" line because of the goofy IP format. - Don - .
Wazoo Posted March 3, 2009 Posted March 3, 2009 Received: from 222.50.91.253/32:9509 (from=<ryyy[at]jk.net>;helo=jk.net) by eXpurgate V2.1.1.1, There isn't anything wrong with the parse. SpamCop simply doesn't see that "Received" line because of the goofy IP format. On one hand, I'll agree with Don. As seen in a non-MailHost Configured Reporting account, that line is ignored. See Tracking URL On the other hand, the parse result is wrong, wanting to target your poorly written spam tool source. If one digs a bit deeper, as Farelf did, making the assumption that the screwed up and non-RFC compliant header line is actually identifying the actual initial source of the e-mail, then one finds that this IP Address is listed in numerous BLs. I'm not easily swayed that this particuar situation can be 'fixed' in the MailHost Configuration database either, as the 'problem' is actually with the parser not being able to make sense of that trashed line. I would say that the bottom line would seem to be that you cannot report these until (or if) your 'spamfence/eXpurgate' tool manager gets around to fixing that tool. As it seems to be 'allowing' spam to continue to be received, not sure what purpose it's supposed to be serving .. is it actually useful in any way?
ankman Posted March 4, 2009 Author Posted March 4, 2009 Received: from 222.50.91.253/32:9509 (from=<ryyy[at]jk.net>;helo=jk.net) by eXpurgate V2.1.1.1, There isn't anything wrong with the parse. SpamCop simply doesn't see that "Received" line because of the goofy IP format. Whos mistake is this line? If Spamfence's one (may be me?) should tell them to fix that. But if it's technically okay (Spamfence figured this out correctly), the spammer might know that with that goofy format it can trick reporting services. And Spamcop should IMO change something to detect it.
Farelf Posted March 4, 2009 Posted March 4, 2009 Whos mistake is this line? If Spamfence's one (may be me?) should tell them to fix that. ...I pointed to one eXpurgator user with a configuration that did not mess with the parser in http://forum.spamcop.net/forums/index.php?...ost&p=69511 (linear post #2 above). That received line is non-compliant and needs to be standardized or you need to 'by-pass' it, as shown. I tried to make that clear. As Wazoo says, the situation with a mailhosted parse isn't so clear but it would certainly be worth trying. I don't think SC can be expected to program around every bit on non-compliance (M$ provides more than enough of that already).
Recommended Posts
Archived
This topic is now archived and is closed to further replies.