Jump to content

Farelf

Forum Admin
  • Content Count

    7,012
  • Joined

  • Last visited

Everything posted by Farelf

  1. 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
  2. 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.
  3. 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.
  4. 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 ...
  5. 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.
  6. % 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
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. Should be OK at the moment - vmx.spamcop.net (184.94.240.112) is presently clear in the spamhaus lists.
  15. 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?
  16. 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?
  17. 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!
  18. Yes, a tracking URL - http://forum.spamcop.net/forums/topic/4473-spamcop-glossary/#TURL You don't have to wait for a new problem instance, you can retrieve an old one through your "Past Reports". Just don't quote the link with the Report ID (useless to others) you have to go to the report, follow the link to the parse, and pick it up from there. The most common cause of "no date" recently has been goofy headers from goofy servers en-route. The "Received:" headers have to have both the IP address of the releasing server and a date-stamp from the receiving server (on the same line or continuation of the same line). The goofy headers split the information into two consecutive but separate headers. The parser can't work that out and will not offer to report if it can't determine that the age of the spam is within the allowable 48 hour window. There's no "fix" for that but lambasting the responsible parties and all their descendants in perpetuity is good catharsis. [edit] Ah, belay that about getting the Tracking URL from "Past Reports". "Past Reports" detail is only kept for sent and cancelled reports, the links to "no date" cases won't be saved in your history, just a note "No reports filed" with date and time. Sorry about that - you will need to wait for a new instance after all and to be sure to copy and save the Tracking URL link before quitting the parser page.
  19. whois.ripe.net 217.149.177.35 (nothing found) No reporting addresses found for 217.149.177.35, using devnull for tracking. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Information related to '217.149.176.0 - 217.149.179.255' % Abuse contact for '217.149.176.0 - 217.149.179.255' is 'noc[at]unico.com.ru' inetnum: 217.149.176.0 - 217.149.179.255 netname: VGSU-NET descr: Volgograd State University country: RU admin-c: SIS19-RIPE tech-c: MVP44-RIPE status: ASSIGNED PA
  20. Farelf

    [Resolved] yahoo problems cant find headers

    Thanks - the key to success must be in the "compliant browser" then. I can confirm IE8 is NOT compliant. Perhaps subtle differences between PC and Mac text processing helps as well, unknown. The parser is shown in action in that Tacking URL I provided - https://www.spamcop.net/sc?id=z6064318009zcf76a76477789fb5d783375a67cbc9b7z You will see something similar every time you make a spam submission except there is a bit at the bottom where you can optionally add comments to the reports, optionally review the reports and (necessarily) either send the reports or cancel. After you have sent or cancelled reports they are stored for 90 days under your "Past Reports" tab on the member reporting page. You can access them from there through the listed ID numbers which gives you the (hopefully) anonymized spam with a link to the parse. When you pull up the parse from the link, you see something like the presentation above, with your Tracking URL (link) highlighted near the top. Let's know if you have any trouble unravelling any of that and we will help you sort it out - it is often useful, especially if you have "Show technical details" checked (on the reporting page) and especially if you want to safely discuss reporting problems and solutions/explanations referencing the specific spam.
  21. Just to mention a useful tool for fairly complete information on just about all aspects of domains of interest, to blow away any uncertainty, doubt and supposition, robtex.com. A particularly useful feature is the discovery and presentation of shared resources. Like: https://www.robtex.com/en/advisory/dns/net/spamcop/ and https://www.robtex.com/en/advisory/dns/com/inchlovers/ (latter same as 18asianz.com, etc., etc.). ISPs are not obliged to receive SC reports and those in the spam/exploit business seem to prefer not to.
  22. Farelf

    [Resolved] yahoo problems cant find headers

    Great news ArtmakersWorlds, thanks for passing it on! Will mark this as resolved. But, it won't work for everyone (well, it doesn't work for me, neither pasting in a copy of the "Full Header" view, nor pasting a copy of the "Printable View"). I guess it depends on the version of Yahoo mail and the browser. I get the "undifferentiated mess" for "Full Header" (as discussed) and only the abreviated headers and no proper message body in the "Printable View". You can illustrate the data (text pasted in) by posting a Tracking URL from the top of the parser page when you make a submission - or retrieve it from your "Past Reports" (not the report ID, need to open the report, go to the "Parse" view and copy the link from the top of the page. We don't do external images here - refer to the "Help" file, bottom of any Forum page. You must be using the current version of Yahoo mail and a "supported browser"? PC/Laptop or mobile device? Anyway, if you're up-to-date, sounds like a potent argument for those of us hanging on to legacy versions to "go with the flow". Certainly no fun trying to report with whatever they've done to the elder version(s)/"unsupported browser".
  23. Sounds like it could be a spambot (or two) and your address(es) are on one or two "lists" - or not, spambot operations don't necessarily depend on a high proportion of functional target addresses which is part of their menace to the internet, the sheer waste of resource. Just guessing, based on behaviour and probability in the absence of any disclosure of IP addresses involved. If, when you report, you notice in the parser results that the source IP address is flagged as being on the CBL, that is a good thing - it means the network has access to detailed information about the hacking of their resources (in addition to the very detailed information about specific breakout instances provided through SC reports to them). A potent combination. It might not seem so at the time but it HAS to be doing some good - if the network is actually trying to (re)assert control. If the network is (largely) successful in getting them out, they will move to other hosts. Depressing but it seems to be a cycle we have to endure. Or, it could be part of some out of control "campaign". That would be theoretically easier to address (since the perpetrators are not hidden criminals, merely obscure). An account (free) with SenderScore.org and the lookup tool and information available there might help put a spotlight on them.
  24. There was no insincerity in anything I posted Lancer and if you have managed to construe otherwise then I am sorry but must decline blame, praise is not belittlement and common difficulty is no cause for division. You are correct that the "Content-Type:" header must not be altered under the provisions of the "Material changes to spam" reference already provided however if you receive spam without that header or with the other content types noted within that header then you should not have difficulty with any (plain text) links in the body. SpamCop long ago decided not to try closely matching the great profusion of non-standard approaches to non-text messaging foisted upon the users of the great mail service providers (a disparity in budgets for one thing), consequently there are many instances where the parser cannot resolve all material presented in the changeable environment. SC staff do request development resources for the parser and I am sure would be open to suggestions for their future bids - especially in relation to the Yahoo matter which has become chronic. I shall move this topic to the "Reporting Help" section where they are more likely to see it and where, incidentally, there are many other topics touching on the reporting of spam received from/through Yahoo. You could see from at least one of those that I no longer consider Yahoo spam worth the effort of SC reporting as things stand - an alternative (though not mutually exclusive) is using the Yahoo internal spam reporting system, while we lack the ease with which we formerly reported it to SC (just my opinion and admittedly doesn't address those "payload" links). Yes, spammers know full well that their efforts are resented which is why they have ramped up their efforts, using robots and (largely) hijacked resources so that with minimal effort and outlay they can multiply negligible rates of return into some sort of subsistence-level aggregate. Here is CISCO's "Overview" of global spam, note that the volume thoroughly dwarfs that of legitimate messaging: http://www.senderbase.org/static/spam/
×