Jump to content

shochatd

Members
  • Content Count

    20
  • Joined

  • Last visited

Everything posted by shochatd

  1. The spam with tracking URL https://www.spamcop.net/sc?id=z6246572546z9a124429f6c8f92ebdeb5a0ab269ed34z shows a frequent phenomenon which seems to me to be a failure of the Spamcop engine to see abuse contact information that is clearly visible in the output of whois. In the example above, Spamcop claims in reference to the spam source: whois.ripe.net 194.226.26.13 (nothing found) No reporting addresses found for 194.226.26.13, using devnull for tracking. Yet, when I run (RIPE) whois 194.226.26.13 one of the first things in the output is this: % Abuse contact for '194.226.26.0 - 194.226.26.255' is 'ip-box@ripn.net' Usually, I can add the abuse contact that Spamcop is ignoring via the user notification (although in this case, it gets mysteriously stripped off). Why doesn't Spamcop see and use this information?
  2. Starting today, I have received numerous spams (on my yahoo mail account), all of which have very obvious links, in fact the main point in every case seems to be to get me to link on the link. Yet, when I submit them to Spamcop, they all come up with "no links found". What is the problem? It is a pain having to determine the corresponding abuse addresses manually (nslookup, whois). The required blank line under the headers seems to be present. Here is just one example: X-Apparently-To: shochatd[at]yahoo.com; Mon, 28 Mar 2016 22:44:27 +0000Return-Path: <ticket[at]viet4mua.vn>X-YahooFilteredBulk: 203.162.238.44Received-SPF: pass (domain of viet4mua.vn designates 203.162.238.44 as permitted sender)X-YMailISG: Rw8P28EWLDvl2QLXKsyZngnzxMFbKBBZLBP6pGumuepah2f7 ImjWsrYRb2BuhBPuXuOdsfi_j55YUY.DgRgWQ_BJTLl7rPCAJBiSIcLBntoc AIJHi5aLdYx4KRF5dKZt.24n0qvOMJ027kmollFrCAGhfQWa3rHLTS4AeMg4 fPV9DeV_2dZqj4_xGiSH71q5QNCDNuKIkkFTcL9aUElJI1OyovTm2SWNv29B viddZJU6BgL37LVc6HC_pfWTCO5uQfdlH0YBt4ETjVQ0viIT_ORnzSPN8VYm P08HqeULCWr7fgBC93zjHDPGjzMFPKFDRSWTBWzd4cQJzqtl3BOugDEQOgNd r0VVZgHDz_e.3.78Q3l_xsOifggrUc3Hs0jfD6X453roOadiYZeNutwivdOM 63_3MFD136gdXvewBvvoKag.9crZOV.1lBx1tiMb3aL9_iMXr7F50M5.aCUg m.gzxvLM3r6e5t5IqMzm4M.JkI7yvOZEVN.oTltZ3QjdK1kqvf1k86i8P9XB GMAGGfuHlUahsh7AUqj_FvqJ1PuCJSrzFPXHy02XUB4C0X8XDht5iJ8pokDP rcbHyUsYUNLVJnXjIDWLEXWF2OTLrveFRYDzImYfBT5YGojWNJ4WSsO7RM8i hsBPIigwEN_A.q.acfM9UU2kdoYoDwwz5.J4kTMda0HmAle32PqsfTCD_YM7 kzdSopgvMjzFkZnQhwLYCIFy2m0ED7ak7f9hUQ9xepEDz8iLDRb2qOeORjqU mZ4JS_WGChQYkTDzDR2o1J3ftjIy8PUkNhWl_5URekiJ_DrFQZscLL6ix.IB POiMgfmT6fYnI1fhwsHC2wiQl8w5JUTKufVTaZR3pk7nfzQZWz8hew_WAyRA rL3K_4Xa6IjuxSqLr8WfTnF1Xih0.exi07axSkJz_1DVgb5Pi2M.FI9zwV9y EUbHFh0gRQVDO6UPZZ_oXoPc6yqs9ALnZFaxG9hvlo35PZCwVJ7IKIxFTepl 9X7HjgoYx6zwAo28taIBrimJ8MWsnamLJX1Ysa1IIdWYfn4SI9VCdBztsxv0 hMHCq2iqgi03FYvlUHvd2hStKw9noddaYWGN5l6pqfzgfHzCgLA7W1GINM.G YVPMCXuUSP8nrBUWFeHxKV420Pzh5StnhdSTvrHlAd7L51.J1unXWyGFg5I1 33LO5nrcdwHBH9xJfUufd56t9zjpIn.Ng8yqDkhlFCGVAC_bCDioxv9M4N8Y kNytR1EXl48V3Lgf.MG0XlGyvt26DgkebA1xNjM3gDVqYBxozkuO1DLeZvy3 t0QtMgSy5aSC2WBumeHarI5ap_lcVYGhzEpJ5WWy9DrnMNF.t06PknwpZmeD o.SUqgBgd9u3RvMGMF_KAIF6U5en8RZY6FpV9bR5AmehOvFvMpgGWETdRy8r __14BOx7sm2yxitCSRkaHuiBsleon01_4XZQZBMcX93Ky_3VhWX9B9JkEhAH B5nmoncrzMU7mL2fiby.N3mcxy3EaXhNlwxIkbz4E1feCc02rg--X-Originating-IP: [203.162.238.44]Authentication-Results: mta1396.mail.ne1.yahoo.com from=viet4mua.vn; domainkeys=neutral (no sig); from=viet4mua.vn; dkim=neutral (no sig)Received: from 127.0.0.1 (HELO hsp.vn) (203.162.238.44) by mta1396.mail.ne1.yahoo.com with SMTP; Mon, 28 Mar 2016 22:44:26 +0000Received: from bjzw.org.cn ([101.200.234.158]) by hsp.vn ; Tue, 29 Mar 2016 05:44:17 +0700Date: Tue, 29 Mar 2016 06:44:17 +0800Return-Path: <ticket[at]viet4mua.vn>To: shochatd[at]yahoo.comFrom: Bobbie Scott <ticket[at]viet4mua.vn>Reply-To: Bobbie Scott <ticket[at]viet4mua.vn>Subject: Invited to H00kUpMessage-ID: <7d6071c0ac92d0b5d33bd75d48e1fa8f[at]bjzw.org.cn>X-Priority: 3X-Mailer: PHPMailer 5.2.6 (https://github.com/PHPMailer/PHPMailer/)MIME-Version: 1.0Content-Type: multipart/alternative; boundary="b1_7d6071c0ac92d0b5d33bd75d48e1fa8f"Content-Transfer-Encoding: 8bitContent-Length: 782--b1_7d6071c0ac92d0b5d33bd75d48e1fa8fContent-Type: text/plain; charset=iso-8859-1Content-Transfer-Encoding: 8bitHi! Will you feed me with your c0ck?Save me from my loneliness!Will you stimulate my G-spot?[ http://tiendoan.vn/start.php?d=61&9ruunMTk=RBXMu3FdfP&9dS=G3g ] Message me hereHope you won't miss the given chance!--b1_7d6071c0ac92d0b5d33bd75d48e1fa8fContent-Type: text/html; charset=iso-8859-1Content-Transfer-Encoding: 8bit<html><body>Hi! Will you feed me with your c0ck?<br><br>Save me from my loneliness!<br><br>Will you stimulate my G-spot?<br><br><a href="http://tiendoan.vn/start.php?d=61&9ruunMTk=RBXMu3FdfP&9dS=G3g">Message me here</a>Hope you won't miss the given chance!</body></html>--b1_7d6071c0ac92d0b5d33bd75d48e1fa8f--
  3. shochatd

    Multipart parsing

    Just in case anyone following this had not heard, or noticed, this bug has been fixed. Parsing of these multipart messages is now succeeding consistently. The boundary string definitions using double quotes are no longer causing any problems.
  4. shochatd

    All spams lately get "no links found"

    I almost cannot believe what I'm seeing, but I believe the bug is fixed. The Spamcop parser has succeeded for me in two tests involving spams with exactly the kind of multipart/alternative structures that have been under discussion here, both the original "single" version and the newer "nested" strain that I posted about 2 days ago. The boundary strings continue to be defined using double quotes, but this no longer causes the parser to fail. Can anyone else confirm, so I'll know I'm not dreaming?
  5. shochatd

    All spams lately get "no links found"

    I have started seeing a new strain (see https://www.spamcop.net/sc?id=z6229228184ze8b04363d42199bc6530a8eedbf82535z)which has an outer multipart/alternative structure (with the usual boundary string beginning b1) but whose second part is an inner multipart/related structure with boundary string beginning b2_. Both have boundary string definitions with the string in double quotes as is perfectly legal, though not required, as explained by j-f earlier in this thread. He mentions section 5.1 of RFC 2045. I think it's worth looking also at section 5.1.1 of RFC 2046 which talks specifically about the multipart cases and is a bit less abstract to read. Anyway, in order to prevent the Spamcop parser from failing, the quotes must be removed from both boundary definitions. Since the meaning of the message is the same with or without the quotes (these boundary strings are pure alphanumeric after the initial b1_ or b2_), this is in a sense a no-op change. The Spamcop parser is basically in violation of the RFCs by treating the two cases differently.
  6. shochatd

    All spams lately get "no links found"

    I respectfully disagree. While it is certainly true in general that "SpamCop does what it does and doesn't do for a reason.", this is different: It is an obviously unintended bug in the parser. This is clearly by mistake and not "by design". And the removal of the quotes, in my opinion, does not constitute a "material change". -- David
  7. shochatd

    Multipart parsing

    Oops. I see now that Johannes also posted his discovery here (I guess I wasn't "following" this one). Thanks again, j-f!
  8. shochatd

    Multipart parsing

    In case you're not following this other thread http://forum.spamcop.net/forums/topic/16624-all-spams-lately-get-no-links-found, j-f/Johannes has just found the problem: In ALL the spams I'm getting that have this problem, in the initial Content_Type: multipart/alternative; the boundary string is given with double quotes around it like this: boundary="b1_b421a616f2a7415e9edb2c535efad9b4" These are unnecessary (though legal) in the string above, and are causing the Spamcop parser to screw up. Remove those and Spamcop finds the links!
  9. shochatd

    All spams lately get "no links found"

    Thank you. I believe you have nailed it! I removed the quotes from the boundary string (after Content-Type: multipart/alternative;) and Spamcop found the links! This is going to save me a great deal of effort. Excellent discovery! -- David
  10. shochatd

    All spams lately get "no links found"

    When I click on that, I get "Sorry, you are not authorized to view this message."
  11. shochatd

    All spams lately get "no links found"

    AI = Artificial Intelligence I only know how to add one recipient. On the results page, there is a box labeled: "Re: User Notification (Notes)". Normally, whois only provides one reporting address, so I don't generally have a need to do more than one. However, I did run into one today with two reporting addresses. It actually said to send reports to both (very unusual). If there's a way to do multiples addresses, that's new to me. If you click on the "Notes" link, you get a box where you can supply comments that go only to that recipient, although I generally put my analysis in the main "Additional notes" box.
  12. shochatd

    Multipart parsing

    Yes, I'm seeing exactly the same thing and noticed as you did that the problem is quite recent. The ones I'm getting are all multipart/alternative and appear to be properly structured. The text/plain part has the URL in square brackets and the text/html part has the same URL in an anchor tag. And Spamcop can't see either one! Latest example: https://www.spamcop.net/sc?id=z6226526475zb4f37537206bffda67da5ca9c9f6bae9zGetting 50 or so of these per day. The host in the URL is always different and looks to me as if in every case, the host has been hacked and a php scri_pt planted on it (model.php in this example) to which a complex argument it passed. Because of this, I think it is extremely important that the spam be reported to those responsible for the IP range including the hacked host. This is a serious bug.
  13. shochatd

    All spams lately get "no links found"

    I do have that box, and as you can see from this thread, I've been using it a great deal lately. It is my understanding that only paid accounts have this.
  14. shochatd

    All spams lately get "no links found"

    I don't consider the correct parsing of multipart/alternative to be AI. I would describe it as an elementary parsing exercise, which, by the way, is performed by any valid E-mail client. Spamcop clearly knows how to identify links. It's the multipart/alternative structure that seems to be throwing them. On those (for me, currently rare) occasions when Spamcop does find links, they always give me the option to uncheck ones that are inappropriate (such as those Avast links that some spammers like to throw in). The process I'm currently having to go through has become quite mechanical, so I may try automating it myself. My problem with sending these to KNUJON is that I have the (perhaps incorrect) impression that KNUJON is assuming that the domain in the link is owned by the bad guys. In the spams I'm currently being flooded with, it looks much more like the spammers are planting or modifying php files on compromised websites and then linking to them (I'm sure this is a highly automated operation). I assume that the owners of these sites would prefer to know this and secure them. They are a key link in the spammer's activity and so I think it is worth whatever it takes to notify people who can fix them.
  15. shochatd

    All spams lately get "no links found"

    Thanks for the information. I did not know the trick of pasting the link by itself into the "report box". Right now, I'm still wondering why the Spamcop parser is failing consistently. All of these "no links found" spams have the same MIME structure (multipart/alternative). They also appear so similar -- looking at the boundary strings -- that I'd say they're all from the same spammer, although each uses a different botnet host sender, and presumably hacked website for the link. Maybe different spammers using the same "kit". I found some threads in this forum about problems Spamcop has had in the past with multipart/alternative, but in these recent cases I cannot see anything wrong with the way the messages are structured. They seem to me to be obeying all the rules. Am I missing something? Is the spamcop parser simply incapable of dealing with this (very simple) structure? Is there any way to file a bug report?
  16. shochatd

    All spams lately get "no links found"

    Sorry, I don't understand. I'm not surprised that 79.96.64.19 is a botnet attack host (Did you determine that yourself? -- I don't see that in the spamcop analysis). But what does that have to do with the failure of spamcop's parsing to find the link in the message body?
  17. shochatd

    All spams lately get "no links found"

    Ok, just got another one with the same problem. And this should be the tracking URL: https://www.spamcop.net/sc?id=z6224655497zf8374024e6dfa03f1115b671aa0b58cfz
  18. shochatd

    Spamming from KVCHosting

    But they have been getting full reports from spamcop and have obviously done nothing. Every spam I receive is reported (just received and reported yet another).
  19. shochatd

    Spamming from KVCHosting

    I too have been receiving a great deal of spam which spamcop traces to kvchosting. They often turn up as responsible for both the spam source and the spamvertised links. Another annoyance is that they forge my own E-mail address into the From: header, so that the spam appears superficially to be coming from me.
  20. shochatd

    yahoo header problem

    I can confirm that this works. I set up an IMAP account for my yahoo mail within thunderbird (very easy, and configuration is automatic). Oddly, the Yahoo "spam" folder is called "Bulk Mail" within TB. I use the "Forward as attachment" function to send the spam to the SC reporting address that I set up for yahoo mail. To report, you can either click on the link in the E-mail that will soon arrive from SC, or simply log into the appropriate SC account, and there will eventually be a link for "unreported spam".
×