Jump to content

ankman

Members
  • Content Count

    24
  • Joined

  • Last visited

Everything posted by ankman

  1. ankman

    Multipart parsing

    It seems that Spamcop fails parsing URLs in Multipart spam. Since about a week or so if there is Multipart declared in the headers and the text/html with some URLs in the body Spamcop fails to see the URLs. Is there a problem?
  2. ankman

    All spams lately get "no links found"

    Sorry I didn't see this before and wrote my own report at http://forum.spamcop.net/forums/topic/16633-multipart-parsing/ . It seems to me that (as noted here already) Spamcop fails parsing URLs if Multipart is involved. To test this I removed the multipart header lines and the corresponding part in the body and Spamcop successfully found the URL then. Thus it not seems to be an issue with conservative parsing to prevent wrong results to me but a bug. And that's quite new. It worked well until past month or so before.
  3. ankman

    Website redirectors

    This post is quite old (10 years), but due to the recent Google redirectors I would like to pick it up again, because I couldn't find a (satisfying) answer. Why doesn't Spamcop when parsing URLs in spam follow them and pull out URLs following. A spam today had the URL goo.gl/GqxowX and I parsed it manually (wget) and get Resolving goo.gl (goo.gl)... 173.194.43.104, 173.194.43.102, 173.194.43.99, ... Connecting to goo.gl (goo.gl)|173.194.43.104|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://armadaglobalinc.com/fl/?coment/piso...itamadeira.html [following] --2014-03-09 11:28:08-- http://armadaglobalinc.com/fl/?coment/piso...itamadeira.html Resolving armadaglobalinc.com (armadaglobalinc.com)... 173.201.97.1 Connecting to armadaglobalinc.com (armadaglobalinc.com)|173.201.97.1|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://thegenericsrx.eu/?fl/ [following] --2014-03-09 11:28:20-- http://thegenericsrx.eu/?fl/ Resolving thegenericsrx.eu (thegenericsrx.eu)... 178.19.107.91 We have 2 targets. The latter is the spammer itself or a spammer friendly ISP though. armadaglobalinc.com (173.201.97.1) is Godaddy. Often those URLs are compromised sites under control of "good" ISP or web site hosters. Umm, not sure if they quality as "good", but I often see Bluehost, Godaddy and such. Because of Spamcop not following redirects (forwarders) I tend to manually report them. Sholdn't be hard to implement? Or does it cause a too high load on Spamcop's systems if it would do it? Wouold IMO be nice to have this feature.
  4. I cannot see this is in discssion here recenntly, so I post. I'm getting messages like Please wait - subscribe to remove this delay (or click reload if this page does not refresh automatically in 1366 seconds.) since today. Frequent refreshes of the page let's me report earlier. Is it just me?
  5. I can't see this was discussed before. "The Canadian Pharmacy" is since a few days (and with additional measurements since today) using (very likely) unique subdomains. Here is one of a recent spam (click it if you want, I already reported via Spamcop) http://05098.whichhot. com/ (remove the space) Every spam I receive has a different subdomain (is I guess how you call those). Since today they also add a unique sort of session ID at the end. I fear (and it seems it is true since after I started reporting spam from this spammer increased massively) that Spamcop is confirming that the mail was read and the link was clicked to the spammer. As in the reports I can see the full domain, not altered. It's so also send to the (bullet proof) hoster in China of the spammer (Chinatietong and other fu**ers).
  6. More, checking that the owner clicks the link. Well... All right then. It was later explained Spamcop merely does a DNS lookup. Then I see no problem there anymore. Thanks all.
  7. Okay, sorry for that. Spamcop has nothing to do with my test orders. I used it as example what happens when a verification link in spam gets clicked. Even without placing orders you get more spam. I assume the spammer has a database. The subdomain part is assigned to the email address the spam got sent. So clicking (even "wget --spider", what Spamcop probably does in some way when checking whom an URL belongs to) the link tells the spammer who clicked it. You might probably recall the old method. who_ever.com]http://www.spammer.tld?email=what_ever[at]who_ever.com That is to obvious and Spamcop replaces the email address by an "x". What I reported here seems to be another method of link verification. And I fear that Spamcop here, not replacing the subdomain by something, confirms the link was clicked when the spam gets parsed.
  8. Despite dra007 says they have botnets, which is true of course, I know that if you place an order (I did several tests with newly created email addresses of mine and placed test orders on pill or Rolex spammers, to see what happens) that all spammer bomb you with even more spam. The (fake) name given in the form is used often in the subject line ("Dear Clint Eastwood", they don't really check if it could be real or not :-). Or you get a reminder to refill, with a listing of your (failed, of course) test order you placed before. You are a "valuable" customer then. I assume those unique subdomains tell the spammer who is interested and send him more (possibly even different that others receive) spam. What reason would those unique subdomains, and now also this session-ID like thing they put behind the URL, otherwise have? If an URL is black listed - for evaluating if a mail is spam or not - it doesn't matter for my knowledge if this URL has unique parts before or after and gets recognized anyway.
  9. I'm not sure if this was discussed before, didn't quite know what to search for. I got this header line, amongs others I ommited. My addy is at spamfence.net, so we can trust this line. Received: from 222.50.91.253/32:9985 (from=<ezarjs[at]hexz.org>;helo=hexz.org) by eXpurgate V2.1.1.1, id=expurgator37/090302145317-5EB138E0-F07C2428 for <$my_addy[at]spamfence.net>; Mon, 02 Mar 2009 14:53:17 +0100 Spamcop failes here. It works if I manually remove the "/32:9985". Btw. spamfence (eXpuregate) also fails detecting this spam with Chinese characters too.
  10. Whos mistake is this line? If Spamfence's one (may be me?) should tell them to fix that. But if it's technically okay (Spamfence figured this out correctly), the spammer might know that with that goofy format it can trick reporting services. And Spamcop should IMO change something to detect it.
  11. http://www.spamcop.net/sc?id=z2665725276z0...c4eb5e0b0200b4z (which I didn't sent then) Spamfence is added to my mailhosts since months. And 194.145.224.20 is in my list as I just verified. Spamcop admins might want to have a look (permission granted herby :-) into my accounts what could be wrong.
  12. ankman

    URLs not reported

    Little older article here. But there is this new Social Network spammer at FanBridge dot com. I get about 3 spams a day, trying to complain via Spamcop results in == Tracking message source: 74.86.91.162: Routing details for 74.86.91.162 [refresh/show] Cached whois for 74.86.91.162 : abuse[at]softlayer.com Using abuse net on abuse[at]softlayer.com abuse net softlayer.com = postmaster[at]softlayer.com, abuse[at]softlayer.com Using best contacts postmaster[at]softlayer.com abuse[at]softlayer.com ISP has indicated spam will cease; ISP resolved this issue sometime after Sat 12 Jul 2008 02:09:40 PM EDT -0400 Message is 0 hours old == So the spam is from today (13th) and Softlayer is not larted because he "indicated" something. And the previous days the same happened, decrease day by one for the Spamcop message "ISP has indicated spam will cease...". And I bet it will continue tomorrow and so on. Since Fanbridge seems to be a fairly big spammer and need to spam, and Softlayer appears in reports often too, Softlayer is lying and Spamcop obeys. That sucks. Spamcop should have a database, and if there come further complaints for an ISP which "indicated spam will cease" notes of this ISP should be ignored and complaints be filed to get them listed. Or do I get something wrong?
  13. I (or somebody else) seems to have Yahoo made to understand to use a scri_pt or some other automatitsm to detect spammer (basicly they use meta refresh forwarders) and today ALL spamervertised pages hosted at Geocities bring an error page that the page isn't there. Yay! However, I always noticed Spamcop fails often to file complaints to Yahoo. Sometimes it does, somtimes not, though the spam looks about the same with an easy to parse geocities URL. while it ALWAYS works on other, like 0catch.com involved pages. Why? But now that all Geocities' links throw a 404 if I click at a link coming from a spam mail, Spamcop does the same: sometimes wants to send reports, sometimes not. Spamcop now should never send complaints when a link throws a 404 (I guess yesterday I also had a 301, may be Geocities is still configuring). My question (I couldn't find an answer reading the forum) is, doesn't Spamcop check the web page status and acts accordingly? It's also because many Spamcop users do not check if links in spam work. Neither do I all the time. So they send reports even though a spamvertised page does not exist anymore. Here Spamcop should honor a 404 and such, not to kick Yahoo's a**, since they managed to get spam off their servers. Now if also Google could do the same with their abused Blogs, since I notice spammer's abuse them more after they have no luck at Geocities anymore. One would assume Yahoo people are smarter then those at Google.
  14. ankman

    4xx web page status and reports

    Well it's not Sunday. But having time checking, no changes. On 404 links Spamcop still sometimes wants to create reports, while on 200 links in spam it sometimes doesn't want. Sometimes does though. It looks like pure random to me when complaints are filed, not matter what the link returns (2xx or 4xx).
  15. ankman

    4xx web page status and reports

    Would be interesting to know how long the caches last. It's now two days that none of the Geocities links would lead to a spammer page. All pill spammer gave up and now, as predicted (wasn't hard to predict, eh? ) they abuse Google's Blogspot instead. Still one OEM spammer tries it with Geocities. I assume the spammer does not test if the Geocities account is still available when sending the spam, so all four links in spam of OEM spammers from today are dead. But in one of the four cases Spamcop created a report, so I unchecked to box. I have an eye on this. Assuming, all Geocities links are dead by default, Spamcop's cache lasts too long if this is the problem for creating reports for 404 pages. I will post on Sunday here again if Spamcop still creates reports of 404 links by then. NB: I gave up sending reports to Google (yes, I read the thread about Blogspot), they seems to be just ignorant and no matter how many complaints you send, Google doesn't care. Thumbs up for Yahoo/Geocities though. It works, showing spammers abusing their service will not work for them.
  16. Kind of old article, but before starting a new topic may be I add it here. Wouldn't it be possible, that Spamcop did several whois on every IP found on a nslookup (host)? Like for example now the spammer at "we-need-your-help-d.com" has the following IPs (a bot net): we-need-your-help-d.com has address 69.243.17.93 we-need-your-help-d.com has address 71.59.39.237 we-need-your-help-d.com has address 75.42.211.52 we-need-your-help-d.com has address 75.56.221.99 we-need-your-help-d.com has address 76.208.138.29 we-need-your-help-d.com has address 84.237.155.86 we-need-your-help-d.com has address 89.20.148.9 we-need-your-help-d.com has address 98.203.197.253 we-need-your-help-d.com has address 124.86.136.145 we-need-your-help-d.com has address 124.244.154.210 we-need-your-help-d.com has address 125.231.209.1 we-need-your-help-d.com has address 216.186.177.74 we-need-your-help-d.com has address 218.93.5.234 we-need-your-help-d.com has address 221.127.213.120 we-need-your-help-d.com has address 222.110.111.82 we-need-your-help-d.com has address 58.92.130.174 we-need-your-help-d.com has address 60.41.212.85 we-need-your-help-d.com has address 69.22.240.204 we-need-your-help-d.com has address 69.104.54.133 we-need-your-help-d.com has address 69.182.209.214 Why not generate multiple reports to all hostmaster of the IPs appearing here? If Spamcop just grabs one and sends reports like now, AND the hostmaster would take actions, there are still the others there and no complaints are sent, and no (possible) action will be taken. May be it cause a too high system load?
  17. ankman

    Disguised URL using google

    This is a social, not technical problem. Google and other will likely not contact Spamcop about these users, since it's easier (and cheaper to not have the abuse desk involved into a conversation of "stupid" Spamcop users) to just refuse Spamcop complaints instead.
  18. ankman

    Disguised URL using google

    I agree to that wholeheartly. But you (or Spamcop) neither can control Google, nor the (stupid) users. The result is (stupid) users will file complaints anyway addressed to Google and Co. (because Google stupid too, not deactivating redirects) and Google and Co. will thus refuse to accept complaints. This won't help no one. Spamcop has the power to protect stupid users from filing (wrong) complaints to Google, and Google from refusing Spamcop complaints in future because of this. It should be possible to not offer those redirected links for complaints. No?
  19. ankman

    Disguised URL using google

    Some users may be stupid, not read the page, leave all checked and just send complaints. This results in that Google and Co. refuse to accept these kinds of Spamcop complaints. In my opinion Spamcop should "protect" Google and Co. from stupid Spamcop users. Otherwiese Google and Co. will refuse more and more Spamcop complaints. I'd say if Spamcop's parser notices a redirect, it shall just not create a complaint, if Spamcop cannot extract the "true" URL for what reason ever.
  20. ankman

    SpamCop cannot parse header

    Well Spamcop should be able to notice that and assume, it was Gmail to Gmail. Do you have a pointer?
  21. ankman

    419 scams

    Oh, another old article I reply to, couldn't find a newer. I propose to extract 419 addresses from spam and offer to send complaints to the post admins of the abused servers, usually Yahoo, Gmail, Myway and so on. This should be easy to achieve. Parse the body first for and email address. If that fails, parse the header's Reply-To:, if this fails the From: is likely to be the scammer's dropbox. Then create a complaint page where the user MUST check the boxes which are the likely 419 addresses. Also finding out if it is 419 spam should be not too hard.
  22. ankman

    SpamCop cannot parse header

    If the spammer used the Gmail server and spam is received by a (my) Gmail account Spamcop fails parsing and stats "Nothing to do".
  23. ankman

    Disguised URL using google

    I know this is a rather old article, but would like to comment it. I agree, you should uncheck. But, I can see in the Report History, that many Spamcop users don't uncheck and that complaints to Google and Co. were sent. I'd suggest to parse those spamvertized links. It should be easy to get the real URL. In this is not inteneded, deactivate those complaints to Google and Co. But may be also Google and Co. could do something to just not allow those redirects at all.
×