Farelf

Forum Admin
  • Content count

    7,012
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Farelf

  • Rank
    What Life?

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    Western Australia

Recent Profile Visitors

3,479 profile views
  1. No - that is "listwashing" which is NOT what responsible marketers do!!! They use confirmed opt-in to establish their mailing lists. Listwashing is what spammers try to do, See http://www.rickconner.net/spamweb/optin.html SpamCop deliberately shields the identity of reporters.
  2. You're welcome. E-mail marketing (without getting tagged as as spammer) is difficult and distribution lists need to be carefully managed to avoid that risk. Here is SC's general advice to those who have been reported by SC users - https://www.spamcop.net/reported.shtml There were a number of user reports concerning vs01.yaminyami.ru (46.4.63.154) in April. At that time they would have been passed on to abuse[at]hetzner.de in the event hetzner.de might have wanted to institute damage control before the server got itself into more trouble. Apart from the SCbl, that's the way SC works - as a sort of "early warning" system. There is no notification of SC spamtrap hits but in that instance SC reporters triggered detailed reports to the abuse desk anyway.
  3. Thanks username - it is a known problem which awaits fixing. Current contact information can be found at http://forum.spamcop.net/forums/topic/14783-what-is-spamcop/#entry91803
  4. Hello username. That message doesn't seem like it came from SpamCop blocklisting - info[at]yaminyami.com resolves to IP address 46.4.63.154 (vs01.yaminyami.ru) which is not blocked (see https://www.spamcop.net/w3m?action=checkblock&ip=46.4.63.154). Consulting http://multirbl.valli.org/dnsbl-lookup/46.4.63.154.html you can see that SORBS is the only serious RBL listing that server - yet again, the message format does not indicate that SORBS was interrogated to provide a reason to block. I think you (or someone) must talk to moscowpost.ru to find out why those messages are rejected. Maybe the cause is false positives from their own anti-spam application? (see P.S.) Good luck ! P.S. I see that your server has a POOR reputation in SenderBase - http://www.senderbase.org/lookup/host/?search_string=vs01.yaminyami.ru You have apparently sent (during April) a high volume of e-mail, including some to non-existent addresses and to several spamtraps. Also there have been many complaints that the messages were unsolicited and commercial (=spam) I cannot tell whether or not 46.4.63.154 was listed in the SCbl but it was certainly reported by SC users. I now think the rejection reason "due to content restrictions" is misconfigured, the real reasons are probably one or more of poor reputation (current)SCbl listing (no longer, spam has stopped) SORBS listing (current) receiving network private blocklist (?)
  5. I see "OrgAbuseEmail: disa.columbus.ns.mbx.arin-registrations[at]mail.mil" for 30.25.6.0 (ARIN). There's some sort of history there I seem to vaguely recall but I forget the detail
  6. Agree - and no, that "Received:" line doesn't look compliant - it should include IP address 216.82.255.55 for mail6.bemta7.messagelabs.com.
  7. Do not post any images on this site, thanks. See the item "Anti-spam" in Help for some rationale on this. As Lou says 92248[/snapback], copy and pasting the full spam source should resolve the actual spam-sending source, (There are many kinds of spam and in the most common types the sender e-mail addresses are false/spoofed.) You may like to refer to How do I get my email program to reveal the full, unmodified email?. The resulting plain text is suitable for copying and pasting into the (reporting) member submission form. Results can be discussed by reference to the Tracking URL which is available from the resulting parsing and reporting page. Whether or not you actually submit the report is up to you - it sounds like you do want to become a reporter. As Lou also says this is the start of the process that makes SC an effective tool in the fight against spammers - but as he also cautioned in his first post 92244[/snapback] you may not be seeing immediate results in terms of the instant elimination of "your" spam that you might have been anticipating.
  8. Just review and try to assimilate the information you have been given already. There's an awful lot of it, no need to get defensive - you have been trying to soak up in a month more than most of us managed to come to grips with over a period of years. You need to read and take onboard What is the SpamCop Blocking List (SCBL)?. A single reporter will never get any IP address listed - it takes several (nominally within the same 12/24 hour period) and/or spam from the subject address being detected by SC spamtraps (also within that short time frame). You are doing good in reporting even if it has not (yet) apparently resulted in listing. All it will take is one or a few other reporters to add their data ... It appears that the administrators of eonix,net have not been responsive (that is the other "string to the bow" for SC reporters). There can be many reasons for that - we reporters tend to assume it is because they are effectively complicit in the spam operation (because we're mostly paranoid). That assumption may or may not be justified. It is hard for others here to tell without Tracking URLs to help test the conjecture - for instance if the parsing and reporting page (pulled up by the Tracking URL) shows the IP address of the e-mail source is participating in a botnet as indicated by listing in the CBL those administrators might benefit from a user note (completed before releasing reports) pointing them to that fact. Ideally that might have immediate effect (for a single IP address out of many) but in large networks it is usually more complicated than that. But it is a start. But, in the examples you have shared, both the source of the e-mail and the hosting of the payload spam links (websites) are in the same network. That pattern is unlikely for botnets, it is more likely in a spam-friendly network and in that case we can't expect the administrators to be helpful in eliminating that spam. The only recourse is to keep reporting and trust that will contribute to a generally poor network reputation which might, in turn, have economic consequences that will eventually force the network owners to re-examine their business model.
  9. Thanks JoeF ... it would be hard indeed to disagree with your assessment. What can be done to bring them to account, I ask myself - unfortunately without any ready reply.
  10. I don't know what's going on, the devnul addresses usually substitute hash for arroba thus the previous abuse address was delwyn[at]tiburonhost.com but is now devnulled, probably because ownership of that netbloc has changed. You can always add craig[at]modvismedia.com for 104.140.95.174 and 104.140.95.253, or abuse[at]eonix.net (from http://whois.arin.net/rest/nets;q=104.140.95.174?showDetails=true&showARIN=false&ext=netref2), which you have found, as a user-defined reporting address to your reports for 104.140.95.174 and treereadmastkenp.info. You could also report your findings in the Routing / Report Address Issues subforum I will leave it to others to explain how to do any of that if you can't work it out because, frankly, I have run out of patience because ... Despite repeated requests, you continue to post spammer's live links - thus making this forum a spam host and yourself possibly a more effective spammer than the people you are reporting. The URIs in green in my edit of your last post were coming up as clickable links before I broke them. They may not have looked so in edit mode, but did you even review your post after you made it? I don't know what those links do but I do know they are supposedly the links the spammer wanted clicked or otherwise promulgated and which you continue to gleefully expose despite multiple exhortations to only reference spam content by pointing to the appropriate Tracking URLs.
  11. Haven't been there for ages but I think the way it works is - when you switch to mole status (via preferences) you stay a mole until you switch back. Such is entirely at your discretion, SC doesn't recommend anything (except to note that mole reporting is "mostly pointless"). If an abuse desk is known to SC as abusive, SC would not send reports. That is one of the several reasons why, in the reporting stage, some IP addresses/ranges might generate a message something like "No valid email addresses found, sorry!" (followed by a - partial - list of reasons). The main purpose of reporting is to build up statistics towards quickly listing an extensively abused IP address in the SCbl while the abuse is in progress. External reports to ISP/abuse desks are a courtesy - plus some ISPs are actually using those to control spam in their networks, the way it is intended. A double-barrelled approach but certainly there is no need for despondency if no ISP/abuse desk reports are sent, whatever the reason - "You can lead a horse to water, but you can't make him drink," eh? Feeding the SCbl is the "main game". When you opt for munged reports, SC will alert you if the ISP is known to reject those and will not send a report to them unless you take the option (for that individual report) to send an un-munged report. I think. It is fairly rare but you will know it, if you stumble into such a case. Don't sweat it - there is more than enough to learn - if you are resolved to "look under the hood" - without moiling in the dark depths of the more esoteric realms. The reporting process itself is generally quite easy.
  12. Spammers could, hypothetically, put an identifying code of their own devising in the headers or the body of the original spam. That would be a "tracking code". There is no evidence that they currently do this. If they did, their next problem would be to get a copy of the report from the ISP/abuse desk to which the report is sent so they could decode it to identify the reporter (for some unlikely purpose). SC would regard report sharing with spammers as a hostile act and discontinue sending reports to any such complicit ISP/abuse desk if there was any evidence/hint of it happening. There is no way spammers could see your munged e-mail address/details directly, even if they did get a copy of the ISP/abuse desk report. Some ISP/abuse desks do not accept munged reports. You would be given the opportunity to forgo munging in those specific instances. Even with an unmunged report, the spammer would have a problem seeing a copy. The Tracking URL is SC's link to the parsing and reporting page and is NOT to be confused with any hypothetical code which may or may not have been inserted in the original spam by the malefactors Silent reports are not sent to anybody, ISP/abuse desks get nothing. They are like 'devnul' reports, they only affect the SCbl statistics for the IP address "reported". EXCEPT the mole reporter's "silent" reports are discounted - they do not have the same "weight" as an ordinary report (even a devnulled one). They do not contribute much to tipping an abused IP address into the SCbl. But they may help keep a listed IP in the sin bin, when spam is continuing.
  13. Looking at the full source of the example you provided via Tracking URL, blocking the display of remote images should prevent the several images which could work as web bugs (though that is somewhat unlikely) quite effectively. There could be tracking codes in the text (or even the headers) but none are obvious and for any such to work the spammer would need to have access to the reports you send to servermania. SC staff take a dim view of abuse desks that feed the spammers (or are part of the spam enterprise) and will discontinue reporting to them if there is any evidence. There has been much discussion over the years of the "increased spam" some people observe when reporting, if you care to search that topic in these forums. Having seen those discussions as they took place, I keep coming back to "Why would the spammer bother?" The high-volume, scattergun operational model most use doesn't require either list maintenance or "pay-back"/revenge against reporters (and is reduced in effectiveness should the spammer resort to those). The Copernican principle would indicate you (or any of us) are unlikely to be a special target - mediocrity is our most likely lot in life. No, I think it is most likely all part of the "spam cycle" and they will just go away in time. You could take a holiday from reporting to see if it makes any difference - some, doing that in past times, have sworn it does. Others have sworn it doesn't. To a statistician such mixed results would indeed indicate the cycle is most probably independent of reporting.
  14. Hi db17, I'm afraid I don't know enough about your system/setup to suggest anything more in the way of filtering without adding a third-party solution (such as SpamAssassin) which you have already said is not suitable. There really ought to be a way to meet your needs with one of those but I'm afraid I don't know enough about that either. Perhaps some other helpful member could step in and advise ... I'm sure there are some who have their heads around the configuration you are using and practical solutions. Now, you haven't quite grasped the use of the Tracking URL - the URL is the only reference to post here in public, as now amended. When you post the text of the parse AS WELL, you are also posting the spamvertized links from the original spam and you are doing the spammer's job for him, except 1,000 times more effectively than he did in a single e-mail to you. And you are making this forum look spammy and unsafe to search engines and other monitors. Don't worry, lots of other people make the same mistake of not thinking through the consequences (or realize that the forum posting process converts plain text to live links) - just don't do it again, please. Use the URL of the parsing and report process page only, nothing else. Sure hope someone comes along with some ideas to keep that spam out of your inbox.
  15. If you view the full message source code per the external listing you provided - I removed the live link - that is the usual format to include in your spam submission. However, you could simply include the text you have posted instead (or a simplified version of that) - but a final line --Mark=_634250613171253082044-- may be required to close the content declarations in that example (not sure). There must be at least one blank line between the headers and the body. Getting back to the full source: It is permissible, but not required, to substitute decoded Base 64 in the spam body - see Material changes to spam But see the full context in the "material changes" link. HOWEVER I think that spam in its "full form" may exceed the 50k limit per individual spam (but it is OK to truncate the body). I had a brief look at the decoded content using http://www.toastedspam.com/decode64.cgi but had some problems due the utf-8 character encoding. SC's "main game" is finding the massage source - unless there are special reasons you may prefer to simply leave it at that and include just the body outline in your submission as you showed first up. That's what I would do, FWIW (without the line numbers or white space - except for a blank line between the headers and the message body).