mMerlin

Members
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mMerlin

  • Rank
    Member
  1. Got "I refuse to bother search-apnic-not-arin@apnic.net" for 150.164.64.59. Manual whois output includes: In this case, the correct answer is found with whois --host whois.afrinic.net 150.164.64.59 Looks like the parsing needs to check for this result, and retry.
  2. Reporting spam from 104.192.100.140 got the usual statisical tracking address due to bounces at the calculated address. Refresh/Show for the the message source tracking got: Removing old cache entries. Tracking details Display data: "whois 104.192.100.140[at]whois.arin.net" (Getting contact from whois.arin.net ) checking NET-104-192-100-0-2 Display data: "whois NET-104-192-100-0-2[at]whois.arin.net" (Getting contact from whois.arin.net ) Found AbuseEmail in whois noc[at]garrisonnetwork.com 104.192.100.0 - 104.192.101.255:noc[at]garrisonnetwork.com checking NET-104-192-100-0-1 Display data: "whois NET-104-192-100-0-1[at]whois.arin.net" (Getting contact from whois.arin.net ) Found AbuseEmail in whois abuse[at]garrisonnetwork.com 104.192.100.0 - 104.192.103.255:abuse[at]garrisonnetwork.com Routing details for 104.192.100.140 Using abuse net on noc[at]garrisonnetwork.com No abuse net record for garrisonnetwork.com Using default postmaster contacts postmaster[at]garrisonnetwork.com postmaster[at]garrisonnetwork.com bounces (10 sent : 6 bounces) Using postmaster#garrisonnetwork.com[at]devnull.spamcop.net for statistical tracking. The explicit abuse address found for NET-104-192-100-0-1 looks like a better place to try.
  3. I got another ripe lookup failure. Since previous information is that spamcop is supposed to be using cached information, here is one level 'higher' information, to hopefully track down one of the cases where the lookups go down the wrong path. Tracking message source: 130.193.202.166: Display data: "whois 130.193.202.166[at]whois.arin.net" (Getting contact from whois.arin.net ) Redirect to ripe Display data: "whois 130.193.202.166[at]whois.ripe.net" (Getting contact from whois.ripe.net) whois.ripe.net 130.193.202.166 (nothing found) I know nothing about how the background code works, but that makes me think that since the original lookup went to arin, the code to use the ripe cache got bypassed, and the normal redirect kicked in. Need to add to (or fix) the redirect code to notice that it should use the cached data. Side node: The arin results included # Query terms are ambiguous. The query is assumed to be: # "n 130.193.202.166"
  4. I got another one that failed. This seems to be a recurring / intermittent glitch where spamcop is doing a lookup instead of using the cached Ripe data, although this one shows a temporary failure instead of permanent. $ whois 95.111.80.166[at]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 %ERROR:201: access denied for 184.94.240.91 % % Queries from your IP address have passed the daily limit of controlled objects. % Access from your host has been temporarily denied. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied % This query was served by the RIPE Database Query Service version 1.75 (DB-4) A manual whois finds: $ whois 95.111.80.166[at]whois.ripe.net [Querying 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 '95.111.80.0 - 95.111.87.255' % Abuse contact for '95.111.80.0 - 95.111.87.255' is 'ripe[at]mobiltel.bg' inetnum: 95.111.80.0 - 95.111.87.255 netname: MOTOPISTA-SOF descr: Motopista quarter descr: Megalan Network Real IP address space country: BG admin-c: MNET tech-c: MNET status: ASSIGNED PA mnt-by: MNT-MEGALAN source: RIPE # Filtered role: Megalan Network hostmaster address: Megalan Network Ltd. address: 1, Kukush str. admin-c: TD939-RIPE tech-c: AA83-RIPE tech-c: boko tech-c: SG4736-RIPE tech-c: DT9876 tech-c: II9999 nic-hdl: MNET mnt-by: MNT-MEGALAN source: RIPE # Filtered % Information related to '95.111.0.0/17AS35141' route: 95.111.0.0/17 descr: BG-MEGALAN-20081219 origin: AS35141 mnt-by: MNT-MEGALAN source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.75 (DB-2)
  5. I parsed a junk message where spamcop reported "No reporting addresses found for 106.242.84.142, using devnull for tracking." It appears that the KOREAN(UTF8) content at the beginning of the whois output is confusing the parser. Looking at the final part of the tracking information finds: $ whois 106.242.84.142[at]whois.krnic.net [whois.krnic.net] query : 106.242.84.142 # KOREAN(UTF8) ... # ENGLISH ... [ Network Abuse Contact Information ] Name : Network Abuse Phone : +82-2-2089-0101 E-Mail : security[at]bora.net
  6. Looks like the problem is fixed now. I got another spam from the same source today, and it reported just fine. <thumbs up /> Don
  7. Well that makes sense then. It would appear to be a software bug. Are the "nomaster" reports being processed somewhere, which would include this kind of problem? Is there a practical way of automatically getting this information in front of someone’s eyes. Without relying on a user to check what the problem was and post message.
  8. Spamcop server? got blocked today for a lookup of whois 2.191.104.35[at]whois.ripe.net with message %ERROR:201: access denied for 184.94.240.95 % % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-...1-access-denied A manual whois finds: ... % Abuse contact for '2.176.0.0 - 2.191.255.255' is 'R.javidi[at]tci.ir' ... abuse-mailbox: ripe[at]dci.ir abuse-mailbox: R.javidi[at]tci.ir ... remarks: Please for any abuse report write to abuse[at]mail.dci.co.ir That is a /12 block, which I would expect spamcop to keep cached information about. Also need to either convince ripe to allow (volume) exceptions for spamcop, or find a way to spread the load better to keep this sort of error from prevent reporting of span sources 'behind' Ripe lookups. If there were a way to securely automate it, I could do the lookups locally (for my own reports), and pass the results to spamcop. *MY* volume is unlikely to every get high enough for Ripe to block the querys.
  9. Which would be fine if the sites were innocent (for values of). These sites belonged with the spam. Same pattern / structure of emails I get all of the time, with random (bot net and open proxy) sources, and moving urls. The difference is now almost all of the urls are pointing to sites that are owned / hosted / managed [whatever] by cloudflare. I suppose the spam emails could have been collected (not like they are rare or anything), and sent again from a joe job botnet with adjusted urls. Given that the urls all look 'personalized' with identifier guid, I do not want to go exploring the links to see if they really match with the spamvertized content. I tried some munged variations, but got nothing useful.
  10. A search here shows an old topic about cloudflare not being responsible for spam from and about sites that normal reporting points to them. And another about joe jobbing of sites they host. However .., Almost all of my 'normal' spam for the past few days has been showing links to sites that report to (disabled) abuse[at]cloudflare.com. Some with the email source pointing there too. That includes spam that is attempting to use the links to collect more information, and sell me 'junk'. Has the manager or the botnet that spews most of my spam shifted their hosting to cloudflare? Is it time / possible to find some other place to report these? Examples (with guid style suffixes removed) http:/ /bccdui.com http:/ /cottage-bb.com http:/ /banksville.net http:/ /dcdzine.com http:/ /escape-tour.com http:/ /fmuae.com http:/ /camcoomya.com Suggestions? Edited by SteveT (turetzsr) to break the URL links.
  11. This is still happening, (10 minutes ago) with the same [spamcop server] ip (184.94.240.90). REALLY need to get that machine removed from the list that does lookup on ripe. Or convince ripe to add it as an exception for their 'excessive querying' limit. And spamcop will not let me manually add the correct reporting address auftrag[at]nic.telekom.de according to https://apps.db.ripe.net/search/abuse-finder.html $ whois 87.184.88.107[at]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 %ERROR:201: access denied for 184.94.240.90 % % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-...1-access-denied % This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS3)
  12. Just got another one: No reporting addresses found for 81.19.135.139, using devnull for tracking. with details of: $ whois 81.19.135.139[at]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 %ERROR:201: access denied for 184.94.240.90 % % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-...1-access-denied That is the same IP. Need to either get it allowed again, or take it off the queue so that it is does not keep rejecting reports. User Notification sent to service[at]ivc.nnov.ru, pointed to by ripe abuse-finder
  13. Can not tell from reviewing the changes through the tracking link if the problem is really fixed or not. The original error was reporting a specific source IP. Due to whatever load balancing is being done, the 'retry' may have used a different host that is not, and never was, blocked.
  14. Tracking URL: http://www.spamcop.net/sc?id=z5726040040z8...91cfb6d00e5bb8z whois.ripe.net 212.28.246.106 (nothing found) Display Data %ERROR:201: access denied for 184.94.240.90 % % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. Looks like spamcop needs to spread the load better across multiple query sources. Manual lookup through http://apps.db.ripe.net/search/abuse-finder.html says abuse[at]cyberia.net.lb Do the reports dev nulled to nomaster[at]devnull.spamcop.net trigger any followup to locate appropriate information for later reports?
  15. Thanks. That nicely accounts for both the source of the spam, and a possible reason for the time delay, although the delay looks like it was on server later in the chain. To bad spamcop is not equipped to detect and send appropriate reports about that too.