Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

969 profile views

shochatd's Achievements


Member (2/6)



  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 (nothing found) No reporting addresses found for, using devnull for tracking. Yet, when I run (RIPE) whois one of the first things in the output is this: % Abuse contact for ' -' 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. 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.
  3. 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?
  4. 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.
  5. 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
  6. Oops. I see now that Johannes also posted his discovery here (I guess I wasn't "following" this one). Thanks again, j-f!
  7. 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!
  8. 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
  9. When I click on that, I get "Sorry, you are not authorized to view this message."
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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?
  15. Sorry, I don't understand. I'm not surprised that 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?
  • Create New...