nei1_j Posted May 21, 2013 Share Posted May 21, 2013 Delivered-To: x Received: by 10.70.28.226 with SMTP id e2csp128240pdh; Tue, 21 May 2013 08:34:26 -0700 (PDT) X-Received: by 10.68.163.132 with SMTP id yi4mr3336989pbb.64.1369150465811; Tue, 21 May 2013 08:34:25 -0700 (PDT) Return-Path: <x> Received: from munitism.com ([2803:d300:5461:3451::1]) by mx.google.com with ESMTP id wt9si2817765pab.95.2013.05.21.08.34.24 for <x>; Tue, 21 May 2013 08:34:25 -0700 (PDT) Received-SPF: neutral (google.com: 2803:d300:5461:3451::1 is neither permitted nor denied by best guess record for domain of x[at]x.munitism.com) client-ip=2803:d300:5461:3451::1; Authentication-Results: mx.google.com; spf=neutral (google.com: 2803:d300:5461:3451::1 is neither permitted nor denied by best guess record for domain of x[at]x.munitism.com) smtp.mail=x[at]x.munitism.com Date: Tue, 21 May 2013 08:34:25 -0700 (PDT) Message-Id: <519b___________________________________________SING[at]mx.google.com> From: x Subject: x Content-Type: text/html; charset=US-ASCII Content-transfer-encoding: 8bit Choose up to 50k Protection for your Family <a href="http://munitism.com/x"> ----------- And the Parser says: Yum, this spam is fresh! Message is 0 hours old No reporting addresses found for 2803:d300:5461:3451:0:0:0:1, using devnull for tracking. [Darn.] ----------- Sometimes, it seems like all the spams in my gmail-spam-folder are ipv6, and they're only going to Devnull, not being reported to the sender's ISP. But I might be wrong. If there are ipv6's that are sufficiently identified and reported, then I'm probably processing them without giving them a 2nd thought, and I only notice the ones that only go to Devnull. In summary, I'm getting plenty of ipv6 spams from gmail that are not being sufficiently identified and therefore not reported to the sender's ISP. Is that a problem with all ipv6 spams? Thanks, -neil- PS: Are you getting email spasms? How about leg spams? Link to comment Share on other sites More sharing options...
Farelf Posted May 22, 2013 Share Posted May 22, 2013 Here is a tracking link which shows all the parse results: http://www.spamcop.net/sc?id=z5506564790zd...95598a6f21f154z SC does find a reporting address but doesn't trust it - not wanting to bug the nic-hdl: DAA48 person address which is not an abuse address. In this instance, even lacking a proper reporting address, I would be going with the domain registration detail: Administrative Contact: Tiburon Networks, LLC. William Davis ( mailto:support[at]tiburonwebhosting.com) +1.3077635525 Fax: +1.5555555555 PO Box 1045 Jackson, WY 83001 US Technical Contact: Tiburon Networks, LLC. William Davis ( mailto:support[at]tiburonwebhosting.com) +1.3077635525 Fax: +1.5555555555 PO Box 1045 Jackson, WY 83001 US - that is the support address. And using that as a user-nominated report since SC didn't find it and we assume tiburonwebhosting.com actually want to be rid of the vermin. Link to comment Share on other sites More sharing options...
nei1_j Posted May 22, 2013 Author Share Posted May 22, 2013 Hi Farelf. OK, I re-parsed, and I see I get the Tibruon on there, too. I'm with you about adding the authority to the list of recipients, in the case where SpamCop doesn't do it do it, itself. Thanks for cluing me in. With the parser identifying the authority, and then neglecting to inform them, I wonder if the parser needs a little adjusting. But, who you gonna call... Link to comment Share on other sites More sharing options...
Farelf Posted May 22, 2013 Share Posted May 22, 2013 ... With the parser identifying the authority, and then neglecting to inform them, I wonder if the parser needs a little adjusting. But, who you gonna call...Well, Don D'Minion's The Man but maybe SC is achieving the "right" result on this one. It sticks with the hosting network - just so happens in this case that is the same as the domain and so some more - Registrar - data to consider (for a human). It would be nice if the parser could be as "smart" as a person but then SpamCop/CISCO would own the world, a prospect to gladden the stockholders for sure, but ... but still not a "proper" abuse address. Not sure Don would want to put an over-ride in on it until they put up a dedicated abuse record/note in the LACNIC inetnum: 2803:d300::/32 record or an abuse.net record (but, considering the parser's Cannot find ip range in whois output message, I think I see where you may be coming from - the parser's IPv6 handling is deficient because the LACNIC whois record clearly states the range). All conjecture at the end of the day - only SC staff could say. Looks like yours is the only report so far for that address, but not necessarily for that network. In any event when SC can't find a reporting address and I fancy I can find a half-way decent one, I will add it to the user-defined recipient box (without notes under that special circumstance and with no other sightings - http://multirbl.valli.org/dnsbl-lookup/280...51:0:0:0:1.html). Just a reminder BTW, multiple comma & space separated addresses can be used in that report completion/confirmation form user-defined recipient box - up to 4 of them, I think. Link to comment Share on other sites More sharing options...
nei1_j Posted May 24, 2013 Author Share Posted May 24, 2013 Hi Farelf & y'all. I made a real pest of myself and sent Spamcop reports to the "only available email address" as a user-defined recipient. I only sent reports that were Fresh spam, but I was getting so many of them that whenever I sat down at my computer, there were always a couple of fresh ones to report. A day or two ago, they suddenly stopped arriving. I hope that's the end of it, and maybe I had a small part. On the other hand, Farelf says I was the only one getting them from that address, which is kinda ominous. best luck, -neil- Link to comment Share on other sites More sharing options...
Farelf Posted May 24, 2013 Share Posted May 24, 2013 Thanks for the update Neil - here's hoping. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.