SpamCop cannot parse header

[Miss Betsy]

Also, reporting to spamcop means not only a report being sent, but also the IP address getting points towards being on the blocklist.

Much nicer to tell your email provider that they have a problem with spam. If it is a major problem, then why would you continue to use them? If you weren't using them, then you could report their spam easily. If it is a minor problem, that they always fix quickly, then why get spamcop involved?

Miss Betsy

[webmaster]

Sure, it'd be amazingly simple to add in some code ... however, noting that it would probably end up with wrong results time after time ....

but it is very hard to forge the messageID.

Probably true, but the 10 dot IP addresses from Google is presumably a temporary issue that will be fixed by their admins in the near future, so the idea of adding another feature to SC's parser is unnecessary.

However, if these emails continue to be an ongoing issue for months and months I would probably agree with that. But, as I stated previously, I have not seen any of these emails since reported the last two I got. Not saying it's still going on, but it seems like it's either slowed down or might have even been fixed already.

i dont see what it is that makes the private IPs either temporary nor an issue. there is no reason for them not to route the email through their own private network instead of out on the internet.

and, this has been an issue for me for months.

[StevenUnderwood]

but it is very hard to forge the messageID.

That does not help SpamCop get the correct source, which, after all, is SpamCop's primary objective. Helping Google clean up their network in NOT a stated object of the SpamCop reporting tool.

i dont see what it is that makes the private IPs either temporary nor an issue. there is no reason for them not to route the email through their own private network instead of out on the internet.

Nobody has said they should route their internal messages on the internet, but unless the sender of these messages is also inside the Google network, it is originating outside the network somewhere. Spamcop has no way of determining the source of these messages.

If Google would record that "somewhere" then everyone could be happy.

[ankman]

If the spammer used the Gmail server and spam is received by a (my) Gmail account Spamcop fails parsing and stats "Nothing to do".

[StevenUnderwood]

If the spammer used the Gmail server and spam is received by a (my) Gmail account Spamcop fails parsing and stats "Nothing to do".

You are correct. GMail does not include any internet IP addresses so there is nothing for SpamCop to trace. You need to make a manual report to gmail. There is another thread here somewhere fully explaining this.

[ankman]

You are correct. GMail does not include any internet IP addresses so there is nothing for SpamCop to trace. You need to make a manual report to gmail.

Well Spamcop should be able to notice that and assume, it was Gmail to Gmail.

There is another thread here somewhere fully explaining this.

Do you have a pointer?

[StevenUnderwood]

Well Spamcop should be able to notice that and assume, it was Gmail to Gmail.

Do you have a pointer?

Even better, I have merged your topic into that one.

PM sent to inform OP.

[Wazoo]

If the spammer used the Gmail server and spam is received by a (my) Gmail account Spamcop fails parsing and stats "Nothing to do".

Correct. Check the header of that e-mail and you will see that no "internet" resources were used to deliver that e-mail. Therefore, there is "nothing to do" as this e-mail was all GMail internal ... take it to GMail themselves. This is not an abnormal condition. AOL to AOL, Yahoo to Yahoo, in general, most any ISP to the same ISP ends up with this same result .. no "full, complete" headers, as it was all handled internally ... think "the same computer" ....