Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

1,173 profile views

AJR's Achievements


Member (2/6)



  1. I see the same in the whois records - whois.iana.org says that RIPE is authoritative for the IP address range, so ARIN is correct in referring to RIPE. The RIPE whois records have plenty of allocations in that block, but there's a hole spanning which RIPE lists with the referral back to IANA (i.e. their "we're not the RIR for those addresses" response.) RIPE publish a daily report of what IP address ranges they're allocated (no contact details shown, just the address ranges, allocation date, and country of the registrant) at ftp://ftp.ripe.net/ripe/stats/, and the entry for these disappeared on 26 September: delegated-ripencc-20190925: ripencc|DE|ipv4||1024|20180410|allocated ripencc|AL|ipv4||1024|20180410|allocated ripencc|LT|ipv4||1024|20180410|allocated ripencc|DE|ipv4||1024|20180410|allocated ripencc|DK|ipv4||1024|20180410|allocated delegated-ripencc-20190926: ripencc|DE|ipv4||1024|20180410|allocated ripencc|AL|ipv4||1024|20180410|allocated ripencc|DE|ipv4||1024|20180410|allocated ripencc|DK|ipv4||1024|20180410|allocated I.e. on 25 September those addresses were listed as having been allocated to someone in Latvia on 10 April 2018, and become unallocated on the following day. There's no entry for these addresses in RIPE's published transfer records (https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics), TL;DR: so those addresses don't currently belong to anyone, and if, as they appear to be, the previous holder is still routing them then they are now squatting on those addresses.
  2. Spamcop parser says "No reporting addresses found", RIPE whois says "Abuse contact for ' -' is 'abuse@afranet.com'"
  3. Parser is only asking ARIN, and getting search-apnic-not-arin@apnic.net, checking APNIC whois shows "Abuse contact for ' -' is 'abuse-id@myrepublic.net'"
  4. According to Spamhaus's FAQs about SBL CSS (https://www.spamhaus.org/faq/section/Spamhaus CSS), for IPv6 addresses their listings are not of single addresses but of ranges of addresses that are small enough that they should only cover a single customer: If your provider have only allocated a single IPv6 address rather than a full /64 for your server, and have multiple customers in the same /64 address range, then they are ignoring standard practice for IPv6 addressing in a way that could mean that you're being affected by bad behaviour by other customers of theirs.
  5. Parser says "Cached whois for : search-apnic-not-arin@apnic.net", actual whois records (from APNIC) say "Abuse contact for ' -' is 'hanfumaoyi@hotmail.com'"
  6. The specific example was, for which APNIC whois says inetnum: - ... abuse-mailbox: abuse@godaddy.com But SpamCop appears to be asking ARIN about 43.x.x.x and is getting: Found AbuseEmail in whois search-apnic-not-arin@apnic.net -
  7. As an email makes its way from the sender to the recipient, it will pass through multiple mail servers. Each server adds a "Received" header to the top of the message, and so you can (in theory) follow the route of the message from the sender to you by reading these headers from the bottom upwards. (Aside: Some servers will add other headers as well as their "Received" one, e.g. a server that's using SpamAssassin for filtering will add headers with the test results, and these often appear immediately below that server's "Received" header in the raw message, though these are not included in the SpamCop trace.) There are two main things that can go wrong with this: firstly, the headers can get mangled or re-ordered by systems that are handling the emails (some versions of Outlook had a habit of doing this), and secondly, malicious senders can add extra headers to try to point to blame onto someone else (which is essentially impossible for a server further along the chain to distinguish from round-about forwarding/routing of mail.) The first of these can't really be dealt with automatically unless you build a system specially to handle those mangled headers, but the second can be handled by reading the headers from the top down, which is what SpamCop does. By reading from the top down, you start with the Received header added by the mail server where your inbox lives, which is a server that you trust (well, if you don't trust it then you're a bit stuffed) and then follow the chain backwards until you reach the origin of the message - though this can be quite hard to define (do you care about the routing between the sender's mail servers? For spam reporting, probably not, but for other purposes that can be useful.) When you've registered mailhosts on your SpamCop account, it knows which lines are added by your mail provider's servers and which were added by the sender, and uses that knowledge to determine which servers to report. In the case of a Gmail account, it is the one that says "by mx.google.com" (marked 0 in your example) that shows which server handed the message off to Gmail, though whether this is the one that's reported depends on how your email is set up (e.g. if you have a you@yourdomain address forwarding to your Gmail account, the server listed in that line is the one doing the forwarding and SpamCop will know from your mailhosts configuration that it needs to follow the chain further.) TL;DR version: To answer "Which IP did this spam originate from?", read the "Received" headers from the top down until you reach the earliest one that was added by a server belonging to your email provider, and take the sender IP address listed there. This may or may not be the actual origin, but it's a suitable point to use for spam reporting.
  8. I notice that in the top Received header, your mail server is identifying itself with a private-use IP address ( in the first tracking link, or in the others.) I don't know if this will cause a problem, but I wouldn't be entirely surprised if this is throwing off Spamcop's logic, e.g. because it can't use that IP address to uniquely identify a particular server.
  9. arin-notice@wayfair.com is the contact address shown in the WHOIS records (see https://whois.arin.net/rest/nets;q=, which will be why that's being used as the reporting address. If wayfair.com are the spammer themselves, then this isn't a case of SpamCop not finding the correct reporting address (i.e. a routing issue), it's a case of reports needing to be DevNulled. ARIN are an address registry - they and the other Regional Internet Registries (ARIN covers North America, RIPE for Europe & Middle East, APNIC for Asia/Pacific, LACNIC for Latin America & Caribbean, & AFRINIC for Africa) ensure that IP address assignments are globally unique, but don't control what people do with the IP addresses that have been assigned by them.
  10. Currently getting "no reporting addresses found", RIPE whois says "Abuse contact for ' -' is 'support@datacentreplus.co.uk'"
  11. I suspect that spammers' use of link shorteners is more to do with avoiding URL-based filtering, with avoiding reporting being a bonus for them. (Bitly etc. are too widely used for filters to treat those links as anything other than neutral, whereas the actual URL might look positively dodgy.) In my experience, bitly do tend to deactivate short links on their system that are spammers' ones (or rather, they make the short URL go to a page that says "Stop - there might be a problem with the requested link", with an explanation and then a small "Or, continue at your own risk to..." and the original destination URL.) The problem is that bitly don't require you to have an account to create short links, so they're unlikely to be able to identify who created the link beyond an IP address (which is probably going to be part of a botnet or similar) or have a way of preventing spammers from creating more bitly links. As for Cloudflare, they appear to be fine with hosting full-on criminal DDoS services (see http://mailman.nanog.org/pipermail/nanog/2016-July/087257.html), so it's I don't see that they'll care about spammers either.
  12. Hi, and welcome. The short answer is, to get SpamCop to correctly identify the actual sending mail server (rather than identifying servers within the Virgin Media mail system as the sender, or indeed from going too far down a chain of 'Received' headers and getting an earlier hop on the sender's side rather than the server that actually handed the message off from them to you) you should set up 'Mailhosts' in your SpamCop account, as described at https://www.spamcop.net/fom-serve/cache/397.html - basically, you tell it the email address(es) of yours, and it sends you a few 'probe' emails to allow it to trace how your incoming mail is routed.
  13. Parser says "no reporting addresses found", RIPE whois says "Abuse contact for ' -' is 'gary.armstrong[at]pulsant.com'"
  14. Parser says "no reporting address found", RIPE whois says "Abuse contact for ' -' is 'support[at]datacentreplus.co.uk'"
  15. SpamCop normally sends "munged" reports, that hide the reporter's email address. (This isn't only done by SpamCop - some of the big email hosting providers have automatic "feedback loop" reporting that's munged as well.) This is done to prevent "listwashing", which is where a spammer will remove email addresses from their lists when they receive complaints but otherwise continue to send spam to everyone they can find - there's an obvious benefit to them if they can manage to only send their spam to people who don't report it. What you need to do is look at the report, identify the customer/user responsible, and if necessary speak to them to find out what's happened. In my experience (I work at a small hosting provider, and see email sent to our abuse[at] address) you will probably find that it's one of the following: a naive user who's bought an allegedly "opt-in" marketing list that's nothing of the sort (they will probably be mortified when you tell them you've had spam reports about their emails); an unrepentant spammer who's going to keep going until you cut them off (cut them off ASAP); an account that's been hacked (suspend access for clean-up/security review); or a report of something that isn't spam (either an obviously-wrong report, or a well-run list with a recipient who has decided to report it rather than unsubscribing - the latter will only be identifiable by speaking to the user who sent the email and understanding how they manage their mailing lists, though is probably fairly unlikely to be the case with reports via SpamCop.)
  • Create New...