AJR

Members
  • Content count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About AJR

  • Rank
    Member

Recent Profile Visitors

229 profile views
  1. arin-notice@wayfair.com is the contact address shown in the WHOIS records (see https://whois.arin.net/rest/nets;q=162.208.32.165?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2), 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.
  2. Currently getting "no reporting addresses found", RIPE whois says "Abuse contact for '185.70.10.0 - 185.70.10.255' is 'support@datacentreplus.co.uk'"
  3. 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.
  4. 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.
  5. Parser says "no reporting addresses found", RIPE whois says "Abuse contact for '185.43.76.0 - 185.43.79.255' is 'gary.armstrong[at]pulsant.com'"
  6. Parser says "no reporting address found", RIPE whois says "Abuse contact for '185.70.8.0 - 185.70.11.255' is 'support[at]datacentreplus.co.uk'"
  7. 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.)
  8. SpamAssassin is free & open-source, so any spammer who wanted to try to minimise the scores that their messages get could simply run their own copy of it anyway, and so the scoring headers from the spam you receive won't be revealing much more. Aside from the points on the SpamAssassin wiki (http://wiki.apache.org/spamassassin/PublicRules, for anyone interested), there's a simple functional observation: SpamAssassin has been freely available for years, giving spammers plenty of opportunity to try to take advantage of its openness. And yet it continues to be an effective tool, so optimising their spam to get around SA rules must either be too difficult or too niche for spammers to bother doing.
  9. The Postfix header_checks documentation lists settings nested_header_checks & mime_header_checks, which default to be the same as header_checks and are applied "to message headers of attached email messages" and "to MIME related message headers only". If you haven't set those to be different from the main header_checks setting, then it's probably one of them catching the headers of the attached message when you try to forward it to SpamCop. (I wouldn't like to say which one it is without testing it, and I don't have a Postfix server handy for testing right now :-) )
  10. Parser says no address found, whois says "Abuse contact for '91.109.40.0 - 91.109.47.255' is 'support[at]virocom.co.uk'"
  11. Parser says "No reporting addresses found for 79.170.198.103", RIPE whois says "Abuse contact for '79.170.197.0 - 79.170.198.255' is 'mike.tree[at]intrahost.co.uk'"
  12. Note that in the whois records in your example, Alpnames are not the registrant (owner) of the domain name, they are the registrar, i.e. the ISP that the spammer has used to buy the domain registration.
  13. The parser says: But the results from whois.krnic.net include:
  14. The AfriNIC whois database shows a description for this network as "used for AIRTEL Burkina Faso partners", so presumably it's managed by Airtel even though it's in Burkina Faso. Not really any different to e.g. a US provider with networks in Europe, I would say.
  15. But he's saying that he shouldn't be receiving those reports. Something does look at bit odd here - the domain fateful.co from the links has IP address 50.2.145.55, which ARIN whois says belongs to "Eonix Corporation" (not Serverhub, FWIW) with abuse contacts as admin[at]infinitie.net & net-admin[at]eonix.net, but Spamcop is wanting to send reports to a completely different Gmail account that it says is the "Administrator found from whois records" (see https://www.spamcop.net/sc?action=showroute;ip=50.2.145.55 ) Presumably, that Gmail account is the OP's?