Jump to content

Jank1887

Membera
  • Posts

    206
  • Joined

  • Last visited

Everything posted by Jank1887

  1. have been steadily getting AlsonMedia.com sourced spam. they're reporting address comes up as alson@alsonmedia.com. Their spam/abuse page gives abuse@alsonmedia.com as the notification address. (https://alsonmedia.com/antispam_policy.html), and abuse.net lists both the alson@ and the abuse@ address. I realize it pulled the alson@ from the domain WHOIS record. Wasn't sure if it was worth adjusting the reporting address based on their stated abuse reporting destination. example report: https://www.spamcop.net/sc?id=z6696312978zfb08e15f2244f3e87214f2e29b52cabaz
  2. Tracking URL: https://www.spamcop.net/sc?id=z6106757373z395bb5769d3ea4684a4cc5d1039aabf7z thought it was odd when it suggested the source was 11.0.1.3 and wanted to direct the report to mail.mil. Not that that would be impossible, but looking at the header line Received: from mail6.bemta7.messagelabs.com by mail.asme.org (IceWarp 11.0.1.3 x64) with ESMTP id 201504290744006092 for <x>; Wed, 29 Apr 2015 07:44:00 -0400 I googled and apparently IceWarp is a server software and 11.0.1.3 is the version number. So, not sure if the problem is on the mailserver side (is that received line RFC compliant?) or on the parser side, but 11.0.1.3 is not part of the chain. Cancelled the report, but thought I'd post this in case it comes up again or can be fixed.
  3. http://www.junkfax.org/fax/profiles/wsp/BHLL.htm see the above for the full details. If you bought over a specific time while they were allegedly illegally issuing shares, you may be entitled to part of the settlement. I believe this stock was heavily touted over the internet and broadcast junk faxes.
  4. ok, lets recap: SC still does its job, providing an automated mechanism for assisting people in notifying ISP's about spamming activity, and maintaining the SCRBL. We've seen some evidence here and a pretty straightforward process (template) for communicating spamvertised site abuse to responsible parties, with success ranging from marginal to exceptional. Now, what? TerryNZ has hinted at direct past contact with some of the Powers that Be here with SC, and they've indicated a lack of resources to take this same approach in an automated fashion with the SC submissions. (more later) My thoughts: 1) start a new thread in the New Feature Request board. Link to this discussion (possibly to individual posts since this is getting long) showing the 'template' and results. Recommend SC find a way to implement some form of this Template. TerryNZ mentioned that it doesn't make sense to send a million of these to the registrars. So, maybe limit based on reported volume (1 report per day for each... ?domain? ?server? per #Threshold# reports). I.e., something with similar methods but "reasonable" resources. 2) Based on the statement above, would it make sense to implement similar limiting to the standard SC ISP reports? (one per IP per unique spam per... ?day? ?listing renewal? ?#threshold number of reports#) Maybe another New Feature Request. THose with better knowledge of the current reporting mechanism could shoot this down. End goal: ease up SC mailserver resources. (rather that send the ISP a link to individual reports, send them a link to a single page listing the reports for that IP, which gets updated as they come in.) 3) I just started playing around with the PhishTank. For those who aren't aware, it's a "new wacky cool Web 2.0" open (free) Phishing site database which is user driven. (submit a site with spam background, users vote it up or down onto a confirmed list, list available for free to those who could use it, with an open API) Currently I think it just feeds OpenDNS, but it's something. Anyway, the point is, would something like this approach be useful for facilitating item #1 above. Some user supported, system facilitated mechanism to notify the appropriate bodies in a controlled fashion. Just a thought.
  5. thought it was interesting that the first item in the "qmail bounce" search now is the thread where we were trying to find the "qmail bounce" information It's like Google SEO on a micro-scale. And, since it is going through Google, would the use of any of THESE help refine what results appear? Specifically, I'm thinking of the Query modifiers: site, allintitle, intitle, allinurl, inurl.
  6. I'll beat Wazoo to the punch: There are a number of other threads dealing with the web site resolving, reporting prority, etc., issues. But, here's the main FAQ link where most opinions have been summarized.: FAQ: SpamCop reporting of spamvertized sites - some philosophy Also, there is a SURBL, which I believe does pull from the SC reported lists:SURBL.org website
  7. well, I'm already going to claim stupidity at this point then, and wait for someone a little more clued in on Qmail to respond. I'm not familiar with what those patches attempt to do, and why they wouldn't be working for you.
  8. here's a page in the original Spamcop FAQ addressing misdirected bounces, corrections, and a specific entry on Qmail: http://www.spamcop.net/fom-serve/cache/329.html (to save Wazoo the time of posting the obligatory "you could have just searched the FAQ..." statement, this page didn't come up in a first attempt search using the "spamcop forum and spamcop FaQ" search option. I had to switch it to "Spamcop.net and original FAQ". the first attempt (search terms: qmail bounce) was just a wash of people who had qmail messages somewhere in their posts. I.e., qmail 8481 invoked from network, etc., etc. Would adding a 'spamcop faq only' search option be helpful? or just one other thing commonly ignored by people looking for help? Another thought (and likely an implementation headache unless someone's got a better idea), instead of a dropdown box for the search options, maybe some sort of radio button select, that way all options are visible, and a searcher is more likely to select an appropriate one? Not that this would have helped in the above case, but it's a thought.
  9. I recommend Sneakemail ( http://www.sneakemail.com ). I've been using it for a couple years, and my spam volume would be at least double or triple if not for that. Limited accounts (bandwidth limit only i think) are free. You create unique forwarding addresses (i.e., they redirect to your real address), and have a 'desktop' for managing them. So, each time you sign up with a company you're unsure of (or every company, if you want), pop over to sneakemail, create a new address (pretty quick process), and use that new one. You now will know if spam ever comes from that company, or as a result of their actions, because all email to you through that forwarding address will be identifiable to them. I've had 3/4 addresses scraped/sold/etc, in the years I've been using them. Posts about one of these Here. Edit: link fixed.
  10. troll, food. food, troll. Enjoy. *munch munch munch*
  11. because it typically shows up as the .doc attachment that it is. And we know that people LOOOVE to open unexpected attachments, and MANY computers have MS Office and can open those files. They aren't sending unreadable code. They're sending mainstream documents to the correct target majority.
  12. Here's the link: How To Fight spam Using Your Postfix Configuration Lot's of posts about RBL's, collateral damage, how horrible blocklists are, etc. I'd assume a few knowledgeable people here could add insight to the discussion.
  13. That's one of the advantages of a gmail account is that they give you a view as html option. makes things a 'little' safer. I haven't seen anyone throw anything nasty in a MSWord doc yet that still executes when viewed as a converted html. Anyway, that readable text is likely an MSWord web link. That's how all of these that I've been getting have been set up.
  14. I would suggest we mark this as: Resolved. As in, no more to see here. Just someone trying to get out of trouble with their ISP because they didn't think what they sent out was spam...
  15. from the spamcop parse, it's tough to tell what you mean by unreadable code. If you mean the Base64 encoding, that's how anything that isn't text is sent via email (MIME formatted, etc.). when you attach anything, a picture, a executable file, a zip file, etc, the email software encodes it into base-64 text. Email is a text ony medium, so that's how it gets transmitted. Your particular code is a MS Word document. I've been getting a lot of these lately. I even put in a feature request to parse the documents for links, since that's the actual "payload". (topic link: MS word / pdf attachment parsing... ) Edit: fixed link
  16. and these are nothing new, either. before spam (and still) they were/are heavily promoted via junk fax companies. There are stories of groups that have cooked up completely fictitious companies, raked in tons of 'stock purchases' and then they head for the carribean. Reminds me of the movie Boiler Room. here's a link to a story of one such company: http://www.junkfax.org/fax/profiles/wsp/wsp.htm (note, some speculation on this page, but lots of data to back it up. These people get really pissed at junk fax-ers.)
  17. Yeah, I know, it's a long shot. But I just started getting spam (mostly "OEM software" spam) with useless body text, and either MSWord or PDF file attachments. Since GMail gives a 'view as HTML' option, I peeked inside one, and sure enough the document had a web link to an OEM software site in it. Manually reported and WDPRS'd it. We don't need to go into the 'primary function of SpamCop' rant, but I'll make this official request for implementation... when the parser programmers have some free time, that is. Example tracking URL here: http://www.spamcop.net/sc?id=z1025137563z1...981dac7e807791z
  18. you have replaced everything in the original email that might have been a tracking code with the word TRACKINGCODEHERE. That makes it a bit difficult to tell if any of it actually was a tracking code. For it to be a tracking code, it would have to be unique to your email address, generated by the spammer while sending out or while preparing the spam run, and tracked by the spammer to id live addresses. Not every 'random character string' in the message would be a tracking code, as some of them are legitimate to general email form (as mentioned above.) Likely tracking code places are: 1) graphic URL's - the spammer can track which links have been accessed. These can be tracked without the recipient doing anything other than reading the message with images enabled. (that's why many email clients/programs turn off graphic display by default). 2) click-able links used to always contain tracking codes. don't see it as much anymore. 3) other 'random string' locations: unlikely. and some are (were) munged by spamcop. They are only useful to the spammer to find out who's complaining about/reporting the spam, for the purpose of whitelisting. Less common now as most spammers are using 'bot-nets' and complaints don't affect them directly. the third brings up an interesting point. Since SC can less-and-less affect the actual spammers, instead focusing on the often-hijacked "innocent" bystander, and then trying to help them, maybe spamcop (or at least the forum) should be renamed SpamEMS?
  19. I get the same stitched spam as well. Submittal usually exceeds the SC pars limit (XXXXX characters, truncate?) Since Gmail pops up attached images automatically, I can actually see the ticker name being pumped. So I forward to the SEC address mentioned by Telarin, and in the comments section I usually add: XXXX stock spam (replace XXXX with the ticker symbol) If the SEC ever decides to start doing anything about them, adding the ticker symbol to the comment makes it so it'll come up in a text search, since it's not listed anywhere else in the body text.
  20. once again... the directions say to send a Private Message with your email address, and I'll send you an invite.
  21. I think we all know the real answer to that question. Ran across this website (blog) that is trying to verify how much he'd lose if he trusted spam advertised stocks. Turns out the answer is 'almost everything'. Not too much meat, and lots more could be done with this type of analysis, but I thought the site was interesting. http://www.spamstocktracker.com/
  22. What Wazoo is indicating here is that this is not a problem with the Spamcop parser. It is operating as it should. There are many threads here describing how link detection is only a secondary function of the system. As such, a reasonable effort is made at detection, but it aborts after a certain amount of difficulty, as it should. The spam is correctly reported to the responsible mailhost, so all is well. You may manually run the 'actual' link through the webform for the parser, and can then manually report the link to the webhost if you so desire. Spamcop has no way of knowing which of those links is the 'real one', and at this point isn't expected to do so.
  23. FYI: It appears that you get your "1 received message" because all of your spam is email-submitted individually to your spamcop reporting address. If you were able to 'submit as attachment' with multiple messages tied to one submission email to your reporting address, you would only get one email acknowledgement stating, as you want, XX messages are ready. My guess is that the email parsing system is currently configured to send a reply to the submittal email immediately after it finishes parsing the contents of that email. Now, your request for 'summary' acknowledgements seems perfectly valid to me, but it'll probably take a significant rewrite of code for that to happen. I.e., right now the parser can process the submittal, send the reply, forget about the whole thing, and move on to the next email it receives (even though it might be another one of yours). If you want the summary info, it would have to have a stored list of each person's reports generated by email submittal for the past 5/10/15/?etc? minutes. The parser would have to parse a submittal, append any new reports to the list of the appropriate person, and then before moving on to the next submittal, check whether time's up for any of the queued summaries and send any that are, then it moves onto the next submittal. Not that it's a bad idea. I think it would shave a little off the parser's email overhead. Total load might be reduced. But some people would get annoyed at the delay, so you'd have to make it a user option (or customizable delay length.) The powers that be would know better, but I wonder how much overhead is generated via emails as you describe, where I submit a whole bunch of single emails, and even a 1 or 2 minute delay/summary would turn XX email replies into a single email summary reply. Interesting. By the way, even more interesting is that spam, email, and spamcop are not in the forum spellcheck dictionary
×
×
  • Create New...