Jump to content

HN Support

  • Content count

  • Joined

  • Last visited

Everything posted by HN Support

  1. Actually the way I'm reading things Microsoft is the cause of the problem in the first place so in addition to manually determining and reporting to the actual source ISPs of the spam messages I'm also leaving the check mark on to submit to the incorrect MS spam reporting address as well. The intention there is for them to notice the error and as a result put some action on to fixing their IPv6 rDNS entries to conform with the standard.
  2. Hi there for a couple weeks now I noticed most reporting was going to report_spam@hotmail.com. I started to get suspicious and so started looking into it. It seems as though there's some Microsoft IPv6 addresses which aren't in our "Hotmail / MSN" drop-down list of the Mailhosts section our account and every time the parser hits on one of those it decides that's the source of the spam instead of continuing through the headers to the actual origin. Case in point: www.spamcop.net/sc?id=z6456858877zb5f21cf2fa16ca99611a32e08c680ae7z As you can see in this case it stopped at 2a01:111:e400:c47c:0:0:0:49 instead of realizing that was not the sender IP and continuing on to the more likely candidate. Here's some more failures of this type: http://www.spamcop.net/sc?id=z6456858879z4145dd35d533293621e90955a03d735bz http://www.spamcop.net/sc?id=z6456858881z5f2552c0a0b58982773dc4351afcbf34z http://www.spamcop.net/sc?id=z6456858882zaf7ea911350a7960e8187700288a3ff8z I tried deleting my Hotmail/ MSN mailhost entry from within our "Mailhosts" section and recreating it didn't help. Also here's a sample of some of the IPv6 addresses that have been incorrectly identified as the source of the spam messages in some of our submissions: 2a01:111:e400:5a6b:0:0:0:40 2a01:111:e400:5a6c:0:0:0:36 2a01:111:e400:5311:0:0:0:11 2a01:111:e400:5311:0:0:0:30 2a01:111:e400:5311:0:0:0:32 2a01:111:e400:5311:0:0:0:42 2a01:111:e400:c47c:0:0:0:49 2a01:111:e400:c47c:0:0:0:52 2603:10b6:300:2c:0:0:0:28 2603:10b6:301:0:0:0:0:27 2603:10b6:403:0:0:0:0:22 2603:10b6:403:0:0:0:0:32 2603:10b6:403:0:0:0:0:33 2603:10b6:404:109:0:0:0:18 2603:10b6:404:109:0:0:0:21 2603:10b6:405:1:0:0:0:11 2603:10b6:406:bc:0:0:0:25 2603:10b6:406:bc:0:0:0:29 2603:10b6:910:3d:0:0:0:39 Also please note that whenever all the Microsoft / MSN IPv6 addresses in the message header ARE listed in the current Microsoft / MSN dropdown those messages are correctly parsed and the source of the spam message positively identified. However this seems to be only 1 out of every 10 submissions which means I'm cancelling the reporting of 9 / 10 submissions at this point. Please advise.
  3. Initially I was cancelling these but I've now realized it's possible to uncheck the report_spam@hotmail report, check the 'user report' option under it, then fill in the abuse address for the ISP who's in charge of that particular IP address. You can find this by looking in the headers for the point at which a non-Microsoft server has handed off the messaging to a Microsoft server and running a whois on the IP address of that hand-off server. From your link above this is the relevant section: Received: from mail1.listingbookmail.com ( by HE1EUR02FT053.mail.protection.outlook.com ( with Microsoft SMTP Doing a whois | grep Abuse gives us the following results: OrgAbuseHandle: TWTAD-ARIN OrgAbuseName: tw telecom Abuse Desk OrgAbusePhone: +1-800-829-0420 OrgAbuseEmail: abuse@level3.com OrgAbuseRef: https://whois.arin.net/rest/poc/TWTAD-ARIN RAbuseHandle: TWTAD-ARIN RAbuseName: tw telecom Abuse Desk RAbusePhone: +1-800-829-0420 RAbuseEmail: abuse@level3.com RAbuseRef: https://whois.arin.net/rest/poc/TWTAD-ARIN network:Abuse-Contact;I:abuse@twtelecom.net So then you fill in abuse@level3.com into the blank 'user' field and submit that, instead.
  4. The problem, petzl is not that the parser is generating a report addressed to the report_spam@hotmail.com address but that it is doing so INSTEAD of creating a report addressed to the actual ISP where the reported spam message came from, making the whole exercise relatively pointless. What's Microsoft going to do about a spam that originally came from somewhere not in their control? Nothing. And then at the same time the ISP of the spammer isn't getting the notification it needs to take action. That's the real issue here. For example in the link you put into your reply the origination IP address of that spam message was most likely the IP address listed in the headers. When spamcop is parsing correctly it would most likely have found that it should address the report to security@level3.com, the abuse email address on file for the ISP in charge of that IP address. As you can see at the bottom of that parse job that's NOT where it's addressed to and that's a fail. Microsoft is not in charge of that IP address and therefore has no jurisdiction to correct the issue.