Jump to content

Farelf

Forum Admin
  • Content Count

    7,012
  • Joined

  • Last visited

Everything posted by Farelf

  1. 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).
  2. The payload is what the spammer wants you to see and do - in this case follow the link he is advertizing in the spam. It is perfectly common for one server/IP address to host any number of different websites within different domains, Those domains are not fake - the links wouldn't work if they were and there would be no point in advertizing them. You can look at the perlapostaeltronica.com domain from your example using https://www.robtex.com/ (select the first result) and just look at all the different sites on the one IP address under the "Shared" section, "Domains using the same mailservers as perlapostaeltronica.com" item (it takes a while to load). And that is only the first 100 of them, there will be more. You can filter on the IP addresses of "payload" websites from the spam body (it is arguably more efficient than filtering/blocking on the server addresses sending the spam - the source) but in your circumstance it would be more complicated, it would take an extra layer of processing through whatever filter or blocklist comparison you would need to be using, Far simpler to work with what is in the headers (the message source) since you already have direct access to that layer of information.
  3. (Excessive whitespace removed above). Sorry db17 - I have managed to confuse you quite comprehensively it seems. My fault - I just get too "wordy" the harder I try to explain, it's all "in there", just not clearly enough. Is it still confusing when you re-read it all? Doesn't matter, we can fairly-well start afresh now. I have been asking you to run the parser on some current sample spam and post the result. The header data you have provided is fine. The body text is "close enough" to parse. Here is what the Tracking URL looks like for that data: https://www.spamcop.net/sc?id=z6087547245z98b4e3c92fc33092e01fb750ffd6de02z This is a very straight-forward type of spam, a type successfully handled by the parser in great numbers every minute of every day. "My" parse works slightly differently to what yours might because I do not (and cannot) have your mailhosts set up. That makes it a little more vulnerable to "clever forgery" than yours would be. Don't worry about that, this is not a clever spam (few are). The details: the message source is 153.92.197.71that's the one you want to block to stop spam from that source reaching you there are no bogus "Received:" lines SC finds an abuse address postmaster[at]conware.de SC finds the "payload" spam advertized website is hosted on 193.86.21.118 SC has no suggested abuse address for that serverthat doesn't matter, still worth resolving in case the SURBL or others can use the data SC offers to report - it is up to the reporter whether or not reports are sent. Always, it is YOUR responsibility. You can cancel (as I did) or send. Whether you report or don't, you can use the information for other purposes, such as blocking. No reason you shouldn't do both on a case-by-case basis. The walk-around idea is a sound one and has been done before. The only problem is things change. Here is the previous main attempt http://forum.spamcop.net/forums/topic/2385-how-we-use-spamcop/ Many of those examples of differnt users with different systems and approaches involve the integrated SC mail system which no longer exists - though e-mail submission from other providers still works (alternative to using the paste-in webform). Neither does the "more user-friendly" version of the walk-around mentioned in that topic exist (we lost SCWiki in the last forum upgrade). But some of the information may be worth your review. I have the patience to try an update but I have neither the time nor the specific knowledge of your systems. Perhaps another user can help with Mac-OSX Mail or whatever it is. If there's a way to capture the raw text of entire message (including body) without opening the spam that would be good to know ... Too many words again - but please have a go at reading the parser detail in the Tracking URL and ask questions based on that to prevent us going around in circles. Don't worry if a message is included in the parse saying the information is too old to report (happens 48 hours after the message was first received by your provider. Parsing and reporting are different processes.
  4. Thanks for the explanation. Looks good - only thing is, you MUST HAVE one or more (blank) lines following the headers, followed in turn by some sort of message body. If there is a way to copy and paste the entire "message source" (AKA the "full, unmodified email") then the blank line(s) and body following the headers is all taken care of for you. The body is where the parser picks up the links to any spam-advertized content, You should find the details of how to capture that "full, unmodified email" within https://www.spamcop.net/fom-serve/cache/19.html. Looks easy enough, you've been doing that already to get to the "raw headers" I think? Just keep the full message that follows those too, for pasting in. We're in danger of "overthinking" this I reckon. The whole parser system is designed to work out (to the extent necessary) what is bogus and what is not, especially once you have your mailhosting configuration set up. Until you try a parse you are perhaps needlessly "second-guessing"? 193.86.21.118 appeared to be the host of a spam-advertized website payload from within the body of the spam - nothing to do with the source of the message which is what SC is good at detecting. The parser is designed to take care of both message source and "spamvertized" wesite resolution and usually lets you report to their respective administrators/abuse desks. The SCbl is for message sources (single IP addresses) only. There is no blacklist for those spamvertized websites. The SURBL has a blocklist served in part from SC submissions but is a separate entity. SC doesn't threaten anyone - not with blacklisting nor anything else. Used properly, SC reports should actually help those mail administrators inadvertently hosting spammers by giving them an early "heads up" before they fall into the clutches of other, sterner RBLs. The "X-Originating-IP:" header should (and mostly does) show the message (spam) source. But a little caution is needed (were it otherwise!), it can be "trivially", as they say, forged. Editing your own posts operates in an "edit window", as is the case with almost all forums that allow member edits. Not sure of the window "here" off-hand. It has been discussed in the past ad the answer should be "findable" by searching. But is is also very easy to get "lost" in multiple pages and lose hours of editing by dismissing the wrong one. I do that far too often myself. Direct to MX spam with extensively-forged headers is one kind of spam (in many varieties, a bit "old hat" these days in gerenal) but the parsing service has evolved to see through all of that malarkey. Of course the parser is not perfect but conjecture and second-guessing is fruitless. Just try some submissions (you can cancel them without sending reports if not confident) and discuss any specific cases here or with the SC staff directly by mail - be sure to use the Tracking URLs.
  5. Alas, I know nothing about the use of iptables but to keep stuff out of your inbox it is good to divert (with the subsequent opportunity to examine) the undesirable rather than to simply block. Seeing exactly what would otherwise be dropped adds a dimension to diagnosing what is happening. And allows reporting "in the greater good" because of course blocking by one account has no traction at all to affect the spam operations of the perpetrators whereas, as I have said, I think the various RBLs (and exercise of abuse addresses in conjunction with the SCbl at least) do have a detrimental effect on them over-all, though not necessarily an immediate one. Have you looked at SpamAssassin? Not being a Mac user I keep forgetting about it but I understand there is a long association with SpamCop, Past topics can easily be found by searching these forums.
  6. Way out of my league but those people seem to know their stuff - few alerts with (say) virustotal.com analysis (62 different scan engines, currently) on the (reconstituted) standida.com links and nothing at all with the consequent quttera.com scans on same for malware/suspicious behaviour/blacklists. SC's main game is the e-mail sources of the spam with not much focussed on the spam-advertized payloads. Normally we would be discussing a reporter's Tracking URLs for your examples (or current versions of them) and how the parsing and reporting service is performing in relation to those sources and spam payload sites. IMO SC is not really up to making much impression on operations such as these (might fray them a little around the edges) but, having members "here" with a broad range of knowledge and experience, hopefully some of them might have some thoughts. You're not a SC reporter are you? Or prepared to open an account (it's free)? We could do with a Tracking URL or two. Looks to me like SC would simply offer to report the standida.com and parantly.com "spamvertizing" to forona.com but the SURBL takes some of its feed from SC reported domains and THAT might cause some consternation to these miscreants. Not as sexy as taking down an entire zombie network but everything starts somewhere.
  7. Thanks for the questions dmspac - hopefully someone can address them for you. While you are feeling analytical, you may find https://www.robtex.com/ a useful resource. For instance enter 67.159.200.132, select first result "IP info about 67.159.200.132" and look at the information - progressively displayed, it takes time for it all to come up. It looks like Forona Technologies is fairly well known in computer security circles. SC mostly looks at the e-mail side of things and another resource you can use to explore that aspect is http://www.senderbase.org/ where the sending behaviour (and blacklisting in a number of RBLs) can also be gathered for other IP addresses in the same subnet/CIDR or optionally by domain/network owner. Incidentally, your Wikipedia link in the above is fine but the other external links (not counting the munged ones which I have 'de-linked' anyway) are "404" page not found.
  8. Sorry - probably can't be explained at an appropriate level without proper assessment of where you are in the learning curve (which most of us are still climbing which complicates things a bit as well) but rest assured it can be understood to a useful level by most with some little effort. For a digestible overview of the spam "industry" with layers of optional detail look at Rick Conner's http://www.rickconner.net/spamweb/ The "source address" address, as said before, is the address of the computer sending you the email. That is not the same as the server hosting the spam-advertized website(s) "payloads" with the ilgrandecomunicatore.com domain name. Utterly different beasts. 153.92.194.xxx (and 153.92.195.xxx) are part of a HUGE netbloc (153.0.0.0/8) directly allocated by InterNIC before the Regional Internet Registries were established (look those up if you want but it's just blah-blah). EXCEPT that makes tracking down who-ever is using/abusing them at any given time (using RIR-referred resources) a little more difficult - and if swapped around from spam to spam can degrade the value of any cached abuse.net addresses. Which is why spammers like using those IP addresses. All 16 million and a good many more possible addresses. Because people complain about the spamming abuse from them, one-by-one. SpamCop is evidently picking up abuse addresses via forwards-backwards verification of the accepted sending domain (from the accepted IP address and corresponding server name) and reaching into abuse.net (or is otherwise using the correct RIR, however established). Website servers are a little less easily shuffled around than are e-mail servers but, as discussed, sometimes they have to be moved anyway due to reporter pressure (or non-payment of accounts more likely ). You can see what is in the parse by going into your "Past Reports". Just click on that Report ID field that you have carefully blanked out in the images (needn't bother, only you and SC staff can use that) alongside one of (there can be several) the SOURCE IP address reports, as previously stipulated. That brings up the submitted spam, with a link to the parse at the very top. Follow that link and towards the top of the parse page there are a couple of lines looking like: "Here is your TRACKING URL - it may be saved for future reference: http://www.spamcop.net/sc?id=z641303267z045b750a0c3cf8aa3bfef3b3d92488bfz" That tracking URL can safely be posted here, in public, for discussion of the content and process. Ensures everyone sees the same thing at every level, preserves confidentiality and removes the risk of spreading the payload. It has a life of 90 days, That parse (a re-run) will show you the spam payload (website) IP address used for abuse address location NOW but it will ALSO show you the difference, if any, between the original report address ("Reports regarding this spam have already been sent:") and now. You can run a basic DNS check (the command-line nslookup procedure in an earlier post here - or there are any number of web-based services to do the same) of any such different domain (as sometimes indicated by the report address domain - or there are "other ways", no doubt). As you have correctly deduced, understanding the headers is a BIG THING, understanding the elements of the parse is an even bigger one and the effort needed is correspondingly greater. Reviewing the changes to reporting addresses puzzles many and is key to getting under the hood of the whole spam problem. You will understand none of us can individually spend such amounts of time with every 'enquiring mind" (would love to but time is precious and running serious risk of exposing limits of own knowledge already with concurrent risk of corrupting a whole new generation of Reporters). Which is a kindly-meant (and as self-deprecating as I get) way of saying for a précis of the "self help" resources, don't forget http://forum.spamcop.net/forums/topic/14783-what-is-spamcop/ But there will always be those niggling little queries - that is understood and perfectly acceptable. And others who are prepared to step in and offer guidance. The point I am trying to stress is - though reporting effort mightn't seem to do much good it has a hidden effect, both for the originating source and the spamvertized payloads - it inconveniences spammers and forces them to continually run hard just to stay in place. All of which I contend might be illustrated by your examples which a casual observer might conclude shows just the opposite. Steve
  9. SC, in that graphic of your Past Reports, was offering to send them to the network/DNS owners of the spamvertized websites at ilgrandecomunicatore.com which DNS records presently show to be hosted on: I'm fairly sure that the original parse (which you can pull up from the Report ID for the sources, would have shown that IP address in fact - it is the starting point (after any resolution of link obfuscation) to finding responsibe parties to which to report. It is subject to change - there's a FAQ on it somewhere - here: https://www.spamcop.net/fom-serve/cache/32.html. I'm currently showing "% Abuse contact for '193.86.21.0 - 193.86.21.255' is 'nic[at]t-mobile.cz' (RIPE Database query service).. SC often prefers an abuse.net abuse address or a cached one, for whatever reasons. Sometimes they (SC) will accept a reporter suggestion to use a RIPE (etc.) one instead. Reporting addresses can flop around from one day to the next (even - perhaps especially) within SC's reporting system), I think you just caught ilgrandecomunicatore.com in the process of "change". Maybe your reports helped force that? You don't really need to educate yourself on reading the parses - but I confess one probably needs to look at quite a few of them to understand any, in this "feature rich and dynamic" environment.
  10. Oh, there are "end user" solutions to using RBLs and other selective blocks. (Some) people here are always raving about Mailwasher. Just don't EVER use the "fake bounce" feature which used to be configured as a default selection for spam "handling" by that product, maybe still is. If you do, we shall collectively hunt you down and castigate you so comprehensively that any thought of future gene dilution on your part would remain forever an impossible dream. Or there are are other "consumer level" filters like http://wiki.spamihilator.com/doku.php and http://keir.net/k9.html - you would need to do some homework to see whether those can be configured to your installations and see whether their features suit you.
  11. Just to be clear, there is only one IP address for the one spamvertized web site - ilgrandecomunicatore.com = 193.86.21.118 But you are right - it is not listed, nor is the domain. Again, I think it may be that a certain incidence is required to list. ("Source" is the IP address of the origin of the e-mail conveying those irresistible offers to you.) IP A/Domain are not listed in The URIBL either but there one can register and request listing - I'm fairly sure there's some distance between an individual request and listing though, to guard against the games people play. Oh well ...
  12. Part of the puzzle is that it takes more than one reporter's efforts to get an IP address on the list - see https://www.spamcop.net/fom-serve/cache/297.html Next the list is based on IP addresses and this spammer is changing the originating IP address constantly. Possibly good news - "spamvertized" websites are handled by SC only to the extent of sending courtesy reports to the host networks (who mostly don't want to know anyway) BUT the SURBL takes part of its feed for those from SC. Check that to see if the stuff you're reporting has been listed there. Listing in the SCbl or SURBL isn't going to shut down the spammers overnight - but it allows individual spamsufferers and entire networks to block them and presumably impacts their profitability.
  13. % LACNIC resource: whois.lacnic.net inetnum: 148.245.222.128/26 status: reassigned owner: MARIA LUISA NORIEGA Y SAN ROMAN ... abuse-c: MAN16 ... nic-hdl: MAN16 ... e-mail: rvenegas[at]UTTECAM.EDU.MX
  14. The problem is that you haven't found a way to access the original (standard e-mail content) message body from your version/installation of Yahoo mail. Other have similar (but not necessarily identical) problems with Yahoo mail. Your "body" problem is relevant to just one of the (several possible) "Content-type:" dispositions ("Content-type:" is declared in the headers, the display of which you have mastered). I suggest you should be circumspect about extrapolating that specific failure - Yahoo's failure - into a blanket condemnation of the (free) SC service. It is easy to understand your disappointment that no SC staff member has contributed to this discussion so far - but there have been many other conversations in these forums about the (supposed) iniquities of Yahoo mail, some with solutions, some without. Frankly even I have difficulty keeping track of them, and I come "here" a lot. As Steve T has suggested, the sure-fire way to involve the SC staff is to write to them directly. They will not ignore you.
  15. Farelf

    never ending story-spam

    SpamCop might prefer not to officially reference/recommend the services of a third party (the CBL) over which they have no control and with which they share no commercial interest. Reporters however can make their own judgements and include a helpful note if they wish. As the official SC FAQ says "A brief, personal note like this will make your spam report much more credible." (https://www.spamcop.net/fom-serve/cache/126.html). It may be a waste of time ... or it might make a difference. There are huge net ranges in the Ukraine (I recall seeing) with almost every IP address listed in the CBL indicating the resources (servers) connected to those networks are under the control of criminals. Networks such as those are not likely to be making use of abuse reports or they should have some success before now in re-asserting control. And it is not only (some) in the Ukraine. You can explore internet reputation, including CBL listing, through checking IP addresses in http://www.senderbase.org/ as a starting point (SB is another CISCO company, same as SpamCop). Elsewhere in that SenderBase site you will see average daily spam currently ranges between 36,000,000,000 and 272,000,000,000 (though most of it will never be seen due to filtering). That's each day. Real messages are only 10-15% of those figures. There's no single solution. All that SC reporters can do for their part is report as much as they are are comfortable with and (maybe) enhance their reports, choosing when and how to make the effort, if they believe it might help. No-one has a magic bullet to end the insanity that is mass spam. But even individual SC reporters might make a little difference generally (in some cases specifically). Reporting is an altruistic activity though most reporters want to "hit back" also - but it is unlikely to benefit the reporter directly or immediately. Your first priority is maybe getting "your" spam filtered out of your inbox. That way spam will not affect you so much (drive you mad) and you can maybe pick and choose what to report out of the spam/junk box (newest is better than older). Just be aware there are possibly some real mail items wrongly identified as spam with any filter, you need to check and retrieve those.
  16. Hi Neil, I don't get much spam but just 2 of my last 18 (during March) only offered devnul reporting for the source (somewhat off-topic discussing the source here, sorry O/P, but Neil makes some valid points). Everybody's spam sources are "different", except for those that aren't. For each of those 2, I found an apparently valid abuse address and added that to the report routing (only available if the reporter has reporting credits, otherwise the free reporting account preferences can be finangled to do similar, in clunky sort of way). And I added a topic for each of those "discovered" abuse addresses (I think) in http://forum.spamcop.net/forums/forum/39-routing-report-address-issues/ with that detail for Don to pick up and over-ride present routing if he choses to do so (some he does, some he maybe doesn't - he has his reasons and his priorities). Some other reporters are active in that routing report address issues forum too (to a much greater extent). Oh, and sometimes you can "refresh" the standard cache for the IP's net bloc abuse routing during your review of the parse and before committing reports, to see if SC can find a valid reporting address (a spin-off of the matters mentioned in https://www.spamcop.net/fom-serve/cache/32.html). And back more on topic, we should note that the SURBL uses feed from SC which possibly does more to inconvenience spammers through attacking their spamvertized payloads than does SC abuse reports these days (thinking of high-volume/automated "alphabet soup" domain registrations, botnet webpage hosting, whole countries - let alone networks - effectively complicit in the spam - and exploit - "industries"). But yes, the parser has to find those links first. Which has been discussed in distressing detail already. HTH - oh, and I edited your first post in this topic Neil. Sorry, nothing personal, but we need to be meticulous about external links and (particularly) externally-hosted images which are simply too vulnerable to exploitation over time. So many opportunities for 1st, 2nd and 3rd party malefactors arise from that "full internet experience". Steve
  17. Farelf

    Todays Odd spam

    A couple of techniques there that could be adapted to anything from "web bugs" (of several degrees of intrusiveness) to "drive-by" exploits. Not for nothing do security types recommend not opening e-mails from unknown sources - and the more extreme decry the advent of the HTML e-mail back in 1999 and resolutely use only plain text mail clients (or set their mail clients to "text only") to this very day.
  18. Farelf

    never ending story-spam

    Unfortunately not all of them are going to take action. Some of those that might take action, you can encourage and help. All illegal 'botnet' spam steals network resources by hijacking computer/servers within the network. Many networks will want to regain control of their resources. Those you can help and make sure they appreciate your reports. When you submit spam and see in the parse lines like you can add to the notes to the abuse desk something like "Participating in botnet - check IP address in cbl.abuseat.org". cbl.abuseat.org often identifies the malware that has hijacked the server and often provides detailed information on how to find and remove that malware. SpanCop's detailed report also helps by providing the time-stamps for when the abuse occurred. With both, any administrator who really wants to get rid of those parasites has just about all of the information needed.
  19. Another thing - you may sometimes see the same reporting destination checked as an abuse address for several/numerous "spamvertized" websites (which are within a single spam body). When that happens only the one report appears to be sent to that abuse address, which can be seen/verified after the event, when checking the actual report distribution through your "Past Reports". In any event you do NOT have to uncheck "duplicate" reports.
  20. Farelf

    Invalid or No Headers Error

    Hi frostybytez, No, nothing has changed - but the spam has to include some body content. Headers, one or more blank lines (which signifies the end of the headers), then some sort of body. You can truncate the real body or you can simply substitute a note like "body removed". But after the blank line(s). That's for using the paste-in webform. Actually the parser should offer to truncate excessively-sized spam bodies for you. Try it, any trouble post a Tracking URL (which, for a failed parse, you must get before you dismiss the page). There are some complications with the arbitrary truncation of some kinds of content but those can be addressed if they are a factor. Using the e-mail submission method you don't copy and paste anything - simply "forward" the spam AS AN ATTACHMENT to your (individual, secret) "submit." address, Many providers block that action these days, You will find those bloated spam go away in time ... probably not sufficient return on effort for the spammer, though they may elude some spam filters which assume anything over a certain size is legitimate. Topic moved from Tutorials section to "Reporting Help". Steve
  21. Should be OK at the moment - vmx.spamcop.net (184.94.240.112) is presently clear in the spamhaus lists.
  22. Thanks for the update mortician. I'm guessing that AOL date-time formats on servers sending to other networks are compliant or there would be more than just the occasional SpamCop reporter on their case. Either that or AOL's bizarre format has been accommodated by many/most other networks. I suspected that but the deputies response makes it seem unlikely. In which case AOL has found a neat way to avoid the bother of dealing with SC reports on spam reaching their network. Nice people! Presumably though, they have an internal spam reporting/flagging system for their members' use?
  23. Well observed, what I should have said was dd-MMM-YYYY for RFC 2822 dates - earlier post corrected. Are you sure you're not Denny Crane?
  24. Thanks for the tracker mortician. Looks like the problem in that instance is that server webprd-a61.mail.aol.com is using a partial version the reversed date format of RFC 3339 (Date and Time on the Internet: Timestamps)/ISO 8601 - (YYYY-MM-DD) - instead of RFC 2822 (Internet Message Format) - DD-MMM-YYYY, and the parser can't handle that as revealed by the parser caution "Can't parse date of spam for age detection: 2015-Mar-09 22:05:51". Not sure of the status of RFC 3339 (all my e-mails seem to use RFC 2822 format) but, since some of the internet evidently handles either-both, it would be nice if the parser did too and there may well be a case for a "capability upgade" - BUT the AOL usage isn't a precise implementation of RFC 3339 going by my rushed reading of it and we have the old problem that the parser can't possibly be tweaked for every idiosyncratic variation of the standards by which the major players are pleased to exercise their arrogance or ignorance at odd times. Anyway, whatever we individual reporters see, the SC staff see a thousand time over. If the reversed dates are an emerging problem I would expect the Deputies to either be well aware of it or, in the event you have flagged the leading edge of what could develop into such a problem, they would very much want to be made aware of it. Can you e-mail deputies[at]admin.spamcop.net with your Tracking URL and a brief explanation in case it is the latter? In case they don't read it here. Thanks for bringing this to attention mortician!
×