Jump to content

mMerlin

Members
  • Content Count

    24
  • Joined

  • Last visited

Everything posted by mMerlin

  1. 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.
  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. I already saw and looked at the more information page. As far as I can tell, that is talking ONLY about mangled email headers, usually because of dropped leading whitespace. It does not mention anything about the in the body section headers, and the content is not being mangled. The 'trivial' solution was explicitly qualified with only trimming the trailing spaces once an alternative block header start was detected, and only doing it until the end of the block heading was found. IE, until the first blank line (after trimming) was found. That was intended to cover don't break other things. To be even safer, that could be done only as a second pass, when the first pass fails to parse (per that error message). Tracking *errors* made by spammers or their tools may not be useful effort, but handling parsing of things that show as valid, usable content in an email client does seem appropriate. Otherwise those tools will eventual evolve (survival of the fittest) to versions that our tools fail to parse and report. That is already true from the number of links I have checked out that simply point to a redirector. Several levels of redirection sometimes. And only the first gets reported. Unless the abuse handling team does the extra work to follow up on the chain, instead of just killing the reported link page. As far as feature request, I would start with making the error message clearer for this case, and pointing to a more information page that has some relevance to the actual error. The suggested trivial fix would be separate, since that change might not fix every *error* that might cause the link finding to fail.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. mMerlin

    More Ripe access denied

    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"
  9. mMerlin

    More Ripe access denied

    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)
  10. 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
  11. mMerlin

    More Ripe access denied

    Looks like the problem is fixed now. I got another spam from the same source today, and it reported just fine. <thumbs up /> Don
  12. mMerlin

    More Ripe access denied

    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.
  13. mMerlin

    cloudflare bulletproof spammer hosting?

    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.
  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. mMerlin

    Parser lookup choked

    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)
  16. mMerlin

    Parser lookup choked

    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
  17. mMerlin

    Parser lookup choked

    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.
  18. I got a bunch of 'fresh' spam this morning that show back dated in my email client, and Spamcop is saying is too old to file. Examining the headers, I see a common pattern: ... standard stuff ... Received: by mail-vc0-f187.google.com with SMTP id hz10sf1509630vcb.24 for <x>; Tue, 17 Sep 2013 00:56:59 -0700 (PDT) Received: by 10.50.12.67 with SMTP id w3ls2409537igb.25.canary; Tue, 17 Sep 2013 00:55:40 -0700 (PDT) Received: by 10.50.73.1 with SMTP id h1msigv; Wed, 11 Sep 2013 09:42:33 -0700 (PDT) Received: from oms-md02.mx.aol.com (oms-md02.mx.aol.com. [64.12.81.146]) The final time stamp for today is identical on all of the spam (to the second), but the old date varies. I might be tempted to say that some internal google server was broken, and held on to the mail for awhile until something was reset this morning, but the 10.50.x.x address pair around the time warp also vary. Here are some tracking URLs http://www.spamcop.net/sc?id=z5565604476z1...bc28c374a0cbd5z http://www.spamcop.net/sc?id=z5565660357z4...704d377d5949ebz http://www.spamcop.net/sc?id=z5565665336z5...b67ff266547161z http://www.spamcop.net/sc?id=z5565667792z9...43030bcfe86a6ez http://www.spamcop.net/sc?id=z5565668896z0...739afe1808a512z http://www.spamcop.net/sc?id=z5565670132ze...1b99c304da17e4z http://www.spamcop.net/sc?id=z5565671091z5...a6d0fc561f61c6z Is this a parsing problem, trusting headers that have been faked, or was that batch of mail really delayed internally at google?
  19. 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.
  20. That section has nothing to do with *my* email provider. The headers for that is in the part that got snipped. This section is before it got to my ISP servers. The problem section *looks* like internal handoff, or something, between aol and google. Probably nothing to do with the mail delivery problem, but that whole batch of spam is claiming that I received it because (it says) I am subscribed to a google groups group that I have never heard of. If google is allowing email addresses to be signed up to groups without the owners authorization, there is a big problem someplace.
  21. mMerlin

    Back dated spam

    I got 'fresh' spam this morning, but spamcop refuses to process as being 'too old'. Here is a slightly munged extract from the spamcop parsing, and raw headers. The top received line is the only one I can 'confirm' as being good. That is where my mail host received the message. On typical 'good' mail, that would be the only received header. Is that 5 day jump in the message chain timestamps 'real', or something spammy forged, but spamcop accepted as valid? 0: Received: from mail-ie0-f190.google.com [209.85.223.190] by xxx with SMTP; Fri, 30 Nov 2012 05:55:05 -0800 Hostname verified: mail-ie0-f190.google.com TechComm.ca received mail from Gmail/Postini ( 209.85.223.190 ) 1: Received: from mailout-us.mail.com (mailout-us.mail.com. [74.208.122.35]) by gmr-mx.google.com with SMTP id d5si1194249iga.1.2012.11.25.09.16.17; Sun, 25 Nov 2012 09:16:17 -0800 (PST) Hostname verified: mailout-us.mail.com Gmail/Postini received mail from sending system 74.208.122.35 2: Received: from static.215.239.9.176.clients.your-server.de (EHLO 43.187.4.190) [176.9.239.215] by mail.gmx.com (mp-us011) with SMTP; 25 Nov 2012 11:57:49 -0500 Hostname verified: static.215.239.9.176.clients.your-server.de Possible forgery. Supposed receiving system not associated with any of your mailhosts Will not trust anything beyond this header Received: from mail-ie0-f190.google.com [209.85.223.190] by xxx with SMTP; Â Fri, 30 Nov 2012 05:55:05 -0800 Received: by mail-ie0-f190.google.com with SMTP id k10sf375837iea.17 Â for <xxx>; Fri, 30 Nov 2012 05:55:06 -0800 (PST) Received: by 10.50.37.242 with SMTP id b18mr11172269igk.6.1354283706705; Â Fri, 30 Nov 2012 05:55:06 -0800 (PST) Received: by 10.50.6.199 with SMTP id d7ls441289iga.14.gmail; Fri, 30 Nov 2012 Â 05:54:20 -0800 (PST) Received: by 10.42.247.69 with SMTP id mb5mr1128827icb.4.1354283660904; Â Fri, 30 Nov 2012 05:54:20 -0800 (PST) Received: by 10.50.0.146 with SMTP id 18msige; Â Sun, 25 Nov 2012 09:16:17 -0800 (PST) Received: by 10.50.159.193 with SMTP id xe1mr9693087igb.0.1353863777680; Â Sun, 25 Nov 2012 09:16:17 -0800 (PST) Received: by 10.50.159.193 with SMTP id xe1mr9693086igb.0.1353863777665; Â Sun, 25 Nov 2012 09:16:17 -0800 (PST) Received: from mailout-us.mail.com (mailout-us.mail.com. [74.208.122.35]) Â by gmr-mx.google.com with SMTP id d5si1194249iga.1.2012.11.25.09.16.17; Â Sun, 25 Nov 2012 09:16:17 -0800 (PST) Received: (qmail invoked by alias); 25 Nov 2012 16:57:49 -0000 Received: from static.215.239.9.176.clients.your-server.de (EHLO 43.187.4.190) [176.9.239.215] Â by mail.gmx.com (mp-us011) with SMTP; 25 Nov 2012 11:57:49 -0500
  22. mMerlin

    Back dated spam

    In this context at least, google is not *my* e-mail provider. The munged first line is what mailhosts knows about. But spamcop 'trusted' the google related headers anyway, so continued on down. Otherwise it would have been reporting mail-ie0-f190.google.com [209.85.223.190] as the spam source. If those headers really are valid, the question becomes what caused the (google internal?) 10.50.0.146 server to hold the mail for 5 days, and as mentioned, that's a question for google. I got several spam mails today that had all been held for varying times like that, that all traced back to 1and1.com Only the last 2 were new enough to actually report. First guess from other header info, is spammy used a google group to send the spam. Still do not know why it got held for up to 5 days though.
  23. I have tried searching to forum for anything related, but all combinations of search terms I can think of just give me a whole lot of references to reporting of spam . I also took a few hours to read the announcements, pinned/sticky posts and faq info . This seems to be the least unreasonable place to report this. I am a new registered user of the forum. During the registration process, I filled in the password fields using a 32 character tool generated password. The submit kept failing saying there was a problem with the password fields. Deleting the final character of the password got the submit to work. The password section *had* a green checkmark, supposedly showing that everything was OK, but on submit it turned red with error message again. Context: Windows 7 64 bit, Firefox Nightly 18.0a1 (2010-09-23) It appears that: [one of] the 3 to 32 character limit shown in the popup should be 3 to 31 the underlying form processing code is truncating [only] one of the password fields [causing a mismatch] some characters are not allowed in the password, and the ">" that happened to be the final character caused problems
  24. mMerlin

    minor spamcop forum registration glitch

    [at]turetzsr I needed to go over most of that anyway, if I was planning on doing other posts. I just found it very difficult [in the searches] to separate problems with the web site versus problems doing reporting. [at]Farelf To add to your mix of symptoms, the successful 31 character password contains several non A-N characters, so that only seems to be a limit when using the full 32. One possibility is that the password gets URLencoded as some point, THEN checked against the 32 character limit. Only specific characters would cause the string size to expand when encoding, and the ">" is one, which would normally be replaced with ">" In fact it might only be a problem when the 'special' character is at the end, where the encoded version would then end with a "&" (&) character, causing processing to choke on the now incomplete 'entity' [after truncation to 32 characters] As far as using a *really* strong password goes, that is the point of having a *good* password management system.
×