Jump to content
Sign in to follow this  
ankman

Parsing failed on header with port (range)

Recommended Posts

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.

Share this post


Link to post
Share on other sites
...

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.]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 -

.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×