AJR

Members
  • Content count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About AJR

  • Rank
    Member

Recent Profile Visitors

343 profile views
  1. The specific example was 43.255.154.114, for which APNIC whois says inetnum: 43.255.152.0 - 43.255.155.255 ... 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 43.0.0.0 - 43.255.255.255:search-apnic-not-arin@apnic.net
  2. 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.
  3. I notice that in the top Received header, your mail server is identifying itself with a private-use IP address (172.20.20.12 in the first tracking link, or 172.20.20.13 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.
  4. 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.
  5. 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'"
  6. 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.
  7. 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.
  8. 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'"
  9. 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'"
  10. 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.)
  11. 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.
  12. 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 :-) )
  13. Parser says no address found, whois says "Abuse contact for '91.109.40.0 - 91.109.47.255' is 'support[at]virocom.co.uk'"
  14. 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'"
  15. 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.