Jump to content

gnarlymarley

Membera
  • Content Count

    228
  • Joined

  • Last visited

Community Reputation

0 Neutral

About gnarlymarley

  • Rank
    Advanced Member

Contact Methods

  • AIM
    gn02020202
  • Yahoo
    gnarlymarley

Profile Information

  • Gender
    Male
  • Location
    utah, USA
  • Interests
    reporting spam

Recent Profile Visitors

1,541 profile views
  1. gnarlymarley

    SC parse incomplete

    Spamnophobic, The problem seems to be the existence of a dot at the start of the hostname that seems to be stopping the parser, as can be seen by the other forum link below. It appears to be the following line: Received: from localhost (127.0.0.1) by .z2bozghMJqWR3w@amazonses.com Sounds like your options are to submit without mailhosts, or to just remove that dot before you submit.
  2. gnarlymarley

    Report Ends With "Parsing Header:"

    I have located "Reporting form not loading fully afterparsing spam" from 2018, so this issue is pre-V5.0. I don't see any solutions on that post. My solution was to have two account setup and if I see a dot at the beginning of the hostname, I send the spam to the non-mailhosts account. By this comment, I meant that it would be nice if the parser was fixed...
  3. gnarlymarley

    Report Ends With "Parsing Header:"

    Jelmer, I get this occasionally too. I had some communication with the SpamCop Admins in 2017, but I am not sure if that is when I first saw it. Being that some folks called it a dot or period or {DOT}, it does make searching the forum difficult. Since spammers do not always get the reports (their ISP does and doesn't always pass it on), they probably do not know for sure what is caught by spamcop.
  4. Another reason why I would prefer an automated solution over the manual one is that the current solution can override any whois lookup attempts. Once an entry is made manually, it will constantly need to be manually updated as it can prevent the fresh "whois" link from gathering new contacts. If an IP range is passed back and forth between (for example) APNIC and ARIN, each pass would require a manual update. If automated, The system can either expire the cached entry or else the refresh whois link could pull in the updated contacts.
  5. gnarlymarley

    email-abuse@amazon.com - is this spam

    MIG, This is one that does nearly sound legitimate and had me going for about 10 days now, but I think I have cracked it. It appears that the bounce should be coming from 162.255.118.61 or 162.255.118.62 and not 54.240.8.31. The MX record for client76701.host appears to be namecheap.com, not amazon. The more I look at this, the more I think backscatter
  6. gnarlymarley

    What do do with Amazon hosted spammers

    I will explain further. Yes, I believe this does need to be updated as long as SC is not identifying the proper email addys. I also believe we should be able to figure out "why SC is not identifying the proper source" and we should be able to fix it. The "NEVER will" part needs human intervention with "both" the programmers to fix SC and also putting manual entries. I believe if SC could be fixed, it would automatically determine "most of the proper addys", but there would still be a smaller percentage that needs to be manually entered (due to bad whois or some other circumstance).
  7. gnarlymarley

    Report Ends With "Parsing Header:"

    Yes. I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts". Then they could continue their submissions with one account that has mailhosts enabled.
  8. The answer to the permissions question would be not solved by a permissions grant since SpamCop goes to ARIN and stops. It does not appear to be trying the other registrars. As near as I can tell, the "Redirect to ripe" or "Redirect to apnic" or "Redirect to lacnic" or "Redirect to afrinic" that shows up is manually made entry from http://forum.spamcop.net/forum/39-routing-report-address-issues/ and not automatic. "whois xx.xx.xx.xx@whois.arin.net" (Getting contact from whois.arin.net ) Redirect to ripe As a reminder here, this is happening with more than just RIPE as it is happening with all IP registrars. It is most notably with APNIC, which has granted full permissions. Also, I thought there was a whois copy at SpamCop using rsync that would be queried first, which would also
  9. I went through my logs and noticed I didn't have any from the the IP range of 2402:bc00::/32. The last time I had anything from 2402::/16 was in 2017. So I definitely missed this.
  10. gnarlymarley

    ripe whois -B

    If this does get looked at for implementation, then I would note that it appears AFRINIC is also doing this. It might be wise to look at an automatic implementation that could work for any registrar if they turn this on. % To receive output for a database update, use the "-B" flag. [refresh/show] Display data:
  11. Ah, I thought you mean the IP range. I did send a note to the SCA about the possibility of implementating this in Feb, when I had also them fixed the both a RIPE IP range and an APNIC IP range. They thought it was a good idea. I figure I would post it here for the rest to see just in case there was anything else I missed. If I understood the SCA correctly at the time, this was thought to be in the works for the 5.0 upgrade. I should also admit that I have never seen any typos from the manually fixed entries. One note, if this is implemented, I am not sure how far one would follow the referrers. I know IPv6 on Hurricane Electric goes down to data put in on when a tunnel was created. (AKA, but someone setting up a free account at the time.)
  12. At this time I am unable to find my RIPE IP (because the link is past 90 days), but it used to be accessible from https://www.spamcop.net/sc?id=z6524466667z591f1e62a326f6b7f0346018215c0821z. If you have restore capabilities, you can find it. I noticed this down on Feb 24th, so it would be that day or before. If I can location the IP again, I can post it. (I figure I can post it now and keep searching through all my spam to see if I can find it.) I am starting to think this is all of them and previously the SCA has been manually putting in the forward from ARIN to APNIC or RIPE or LACNIC, or AFRINIC. The whois program I was referring to is the one ran by the whois command on freebsd, but it also works on linux the same way. That program detects the referrer and does a whois look up at the referred server. We are, but in this day and age with IPv4 runout, the registrars are dividing and passing small IP blocks back and forth and I imagine the intensity of those transfers will increase. If this could be automated, it could alleviate the addition of human error (since most of us are getting it from the whois anyway) and also expedite the process of getting updated information. All
  13. Sorry about that. Using a Code takes out the links. Both sections I posted are from the same whois output. (One is from above and the second from further down.) If you look at [refresh/show], you can see that that it has the ReferralServer entry in the Display data area, but the whois chain stops at the ARIN output without apppearing to try to query APNIC. I would expect SpamCop to follow the ReferralServer between registries like my whois program does, or when it forwards to LACNIC (Such as on [refresh/show] for 177.38.191.21). (I have another example of it not following at from 158.140.160.0 below since the original IP has a manually entered entry on it Routing details for 150.107.103.51.) The feature I would like added is to have it automatically follow the referral without any manual intervention. .......................... Parsing input: 150.107.103.51 Routing details for 150.107.103.51[refresh/show] Cached whois for 158.140.160.0 : search-apnic-not-arin@apnic.netI refuse to bother search-apnic-not-arin@apnic.net. Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking. Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net .......................... Tracking details Display data:"whois 150.107.103.51@whois.arin.net" (Getting contact from whois.arin.net )Found AbuseEmail in whois search-apnic-not-arin@apnic.net150.0.0.0 - 150.255.255.255:search-apnic-not-arin@apnic.netRouting details for 150.107.103.51I refuse to bother search-apnic-not-arin@apnic.net. Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking. Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net .......................... Parsing input: 158.140.160.0 Routing details for 158.140.160.0[refresh/show] Cached whois for 158.140.160.0 : search-apnic-not-arin@apnic.netI refuse to bother search-apnic-not-arin@apnic.net. Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking. Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net
  14. gnarlymarley

    ripe whois -B

    RIPE whois now requires a "-B" for to be able to get actual email abuse email addresses from it. $ whois 91.219.88.121@whois.ripe.net [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '91.219.88.0 - 91.219.91.255' % Abuse contact for '91.219.88.0 - 91.219.91.255' is 'a.kazakov@ktstelecom.ru' If for any reason that the local RIPE whois cache is bypassed, it would be good to see this option added as a possibility so we can have SpamCop see the automatically capture the proper abuse addresses. [me@ ~]$ whois -h whois.ripe.net -- 'MP18628-RIPE' % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to 'MP18628-RIPE' person: Michail Pudikov address: 20 Partsyezda str. 11b address: Tashtagol, Russia phone: +7 3842 396006 nic-hdl: MP18628-RIPE created: 2010-09-20T09:37:31Z last-modified: 2016-02-25T13:06:00Z source: RIPE # Filtered mnt-by: KUZB-MNT % This query was served by the RIPE Database Query Service version 1.94 (WAGYU) [me@ ~]$ whois -h whois.ripe.net -- '-B MP18628-RIPE' % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Information related to 'MP18628-RIPE' person: Michail Pudikov address: 20 Partsyezda str. 11b address: Tashtagol, Russia phone: +7 3842 396006 nic-hdl: MP18628-RIPE created: 2010-09-20T09:37:31Z last-modified: 2016-02-25T13:06:00Z source: RIPE mnt-by: KUZB-MNT e-mail: noc@kts42.ru notify: noc@kts42.ru % This query was served by the RIPE Database Query Service version 1.94 (WAGYU) [me@ ~]$
  15. We need to have SpamCop automatically detect when an entire IP range is transferred from one registrar to another. Right now, there are a lot of manual updates being put in to get the reports to the correct destination. This should be automated so that the correct whois entries can be detected without manual human intervention. Routing details for 150.107.103.51 [refresh/show] Cached whois for 150.107.103.51 : search-apnic-not-arin@apnic.net I refuse to bother search-apnic-not-arin@apnic.net. Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking. Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net I believe this is what it would detect in the code. ReferralServer: whois://whois.apnic.net
×