Snowbat Posted August 8, 2014 Posted August 8, 2014 Abuse contact for '194.165.26.0 - 194.165.27.255' is 'tiger.net.abuse[at]gmail.com' Routing details for 194.165.27.150 [refresh/show] Cached whois for 194.165.27.150 : tiger.net.resources[at]gmail.com Using abuse net on tiger.net.resources[at]gmail.com abuse net gmail.com = gmail-abuse[at]google.com Using best contacts gmail-abuse[at]google.com Reports disabled for gmail-abuse[at]google.com Using gmail-abuse#google.com[at]devnull.spamcop.net for statistical tracking.
Farelf Posted August 9, 2014 Posted August 9, 2014 Abuse contact for '194.165.26.0 - 194.165.27.255' is 'tiger.net.abuse[at]gmail.com'... Yep, over-rides (precedes) "organisation:" and "person:" abuse-mailbox entries to a different address in RIPE Database entries for that range - while the abuse.net lookup seems to dumbly take an [at]gmail.com reporting address as indicating the domain of the source. But reporting to that range may be disabled for other reasons? But 194.165.26.0/23 doesn't look to be a bad spammer to me (SenderBase and SC IP Space Map)... Don will know.
SpamCopAdmin Posted August 9, 2014 Posted August 9, 2014 Fixed! Thanks! - Don D'Minion - SpamCop Admin - - service[at]admin.spamcop.net -
A B Posted August 9, 2014 Posted August 9, 2014 Yep, over-rides (precedes) "organisation:" and "person:" abuse-mailbox entries to a different address in RIPE Database entries for that range Is there any authoritative reference, that this line should have higher priority? In this case, this reporting issue is not completeley solved, because reports are currently directed to tiger.net.resources[at]gmail.com instead of tiger.net.abuse[at]gmail.com. Probably a minor issue in this case, but it should be consiered by SpamCop in general. According to my observations, SpamCop nearly always ignores the "Abuse contact for ..." line in RIPE whois responses, even if there is no other adress given. This might be related to the pinned topic "No reporting addresses found", Code Changes, but this was expected to have been resolved more than two years ago. Parsing this standardized line should be pretty simple, so why are there still so many cases, where it fails? Fixing this problem would make adding all these manual static routes obsolete. while the abuse.net lookup seems to dumbly take an [at]gmail.com reporting address as indicating the domain of the source. This is not abuse.net's fault. The purpose of abuse.net is to find reporting adresses for domains, so the response is likely OK. SpamCop just should not use abuse.net for domains of known mail providers, as the results will be wrong in nearly every case. It might even be better not to use abuse.net at all, since I cannot see a situation, where whois data only gives a domain instead of an email address and abuse.net could be helpful in finding a proper mailbox for this domain. Maybe it could still be used a a last resort, if the mailbox given in the whois data is known to bounce. So this report by Snowbat even shows two problems in SpamCops reporting routines. While a static route fixes this special case, it does not really resolve any of the underlying problems.
Farelf Posted August 9, 2014 Posted August 9, 2014 All you say is true A B - all we users can do is keep waving our hands about (and help out with observations such as these). I'm sure SC staff are even more aware of the shortcomings than are we, and wish it were otherwise. And no, I'm not aware of any rule to say the "headlined"/over-arching abuse address in the database record takes precedence - ideally there should be no ambiguity at all of course - but it seems a reasonable assumption. Anyway, those adding their findings to "Report Address Issues" are helping, as things stand. And your own efforts are notable. This topic is marked "Resolved" concerning the specific route and reminds staff they've already dealt with this one.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.