mMerlin

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mMerlin

  • Rank
    Member
  1. Maybe the initial post was not clear enough. The post was because SC was not parsing the body of the spam email, not because it was get the wrong reporting address. Unless can not find any links is the same as wrong address. What I see is that the post has been moved **to** "Spamcop Reporting Help", while I thought I had initially put it in the "Routing/Report address issues". Which is the reverse of what @Lking seems to say. Neither seems to be quite correct, but I could not find a place to report that the parser is (partially) unable to handle an email that was submitted with full content. And with a trivial solution. Once the start of an alternative block is detected by the parser, trim trailing white space until the end of the header (for the block) is found. That should allow this type of email content to be parsed, without breaking anything else. Given the messages I got, I assume that the parser currently does not see that line with a space as the end of the header, and keeps reading more lines expecting more header content. Which then fails. But it seems to work just fine in gmail.
  2. I have had a few spams recently (windward casino) that spamcop gave error message: at the end of "Finding links in message body" I did some exploration, and discovered that the problem seems to be the way the spam emails are constructed. They are multipart/alternative, and the alternative header blocks are ending with a line containing a single space. Deleting that space in the body of the content lets spamcop parse the body correctly. --Section.«guid» Content-Type: text/plain Winward Casino: US Players, … That *blank* line is really a space. Deleting the space character allows the "Finding links" to work again. Example: https://www.spamcop.net/sc?id=z6408256844z01c6f10262d93f7fd6bc56e589ea4e33z I understand that the original purpose of that message, was due to an error in the user handling the copy/paste/forward of the emails in such a way that email header was no longer accurate. However, in this case, the "couldn't parse head" is really the multipart header in the body of the message. That was not really clear from the context.
  3. 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.
  4. 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.
  5. 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"
  6. 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)
  7. 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
  8. Looks like the problem is fixed now. I got another spam from the same source today, and it reported just fine. <thumbs up /> Don
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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)
  14. 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
  15. 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.