Jump to content

Farelf

Forum Admin
  • Content Count

    7,012
  • Joined

  • Last visited

Everything posted by Farelf

  1. So that's what the "Check post length" link is about, in the edit console. Seems like there's scope for some background and usage notes on this and other tools in the Forum FAQ. Do bells sound and lights flash if you do the check and the number is excessive? I swear I saw something about maximum post size somewhere once but can't find it at the moment.
  2. Thanks once more to paradoX over at news.grc.com (grc.techtalk), pointing to http://billmullins.wordpress.com/2009/09/0...h-free-geswall/ Further review on YouTube - Operating systems: Windows 2003, Windows Vista, Windows XP, Windows 2000, Windows 7 I haven't tried this one. Sounds good though 'experienced and intuitive' applications worry me (even if they do promise they are 'non-intrusive'). It would be good to hear from any intrepid user who is running it. If it goes half-way to meeting the promise/hyperbole it could be the answer to the prayers of the more technically-challenged amongst us (definitely including this humble scribe). As an aside, the resources devoted to anti-virus/spyware/malware on my machine are way past being a joke. The only positive slant I can come up with in my situation is that (apparently) Malwarebytes and SuperAntiSpyware may fight with each other but, when they try, my Norton Internet Security seems to be keeping them from each other's throats. As far as I can tell from the thing that passes as an activity log in NIS these days (the only indication, other than that they all still work). Or NIS might be lying. Or I might be reading it wrong. Bottom line, I loved it more when computers, and everything that ran on them, constantly did exactly what you told them.
  3. http://code.google.com/p/browsersec/wiki/Main
  4. Farelf

    SSL Certificate Faked

    O/T to continue in the original post's subject but to follow-up: Update on that http://www.win.tue.nl/hashclash/rogue-ca/ So - an actual/practical exploitation of the MD5 weakness. A very short piece of 'text' involved, computing resource included a 'supercomputer' consisting of 200 banked PS3s, but the writing is well and truly on the wall with this progression of the attack on this hash function. As the authors of the paper say, "MD5 considered harmful today."
  5. Farelf

    Portable applications

    Too cool. Can't vouch for this personally but every reason to believe functionality is 'as advertised'. Thanks to member Dark Samurai {Loud} at the Whirlpool discussion forums (iiNet) for his posting and recommendation. Advantages: portability (all fits on any of the tiny flash drives with loads of space left over for data), privacy (minimal footprint) and cost (none). http://portableapps.com/
  6. Farelf

    Firefox exploit patched

    (Especially) since Firefox is a recommended/supported browser in connection with the 'Reporting and Parsing' service ... A 'zero day' exploit was announced: http://www.darkreading.com/security/vulner...cleID=218500758 or http://preview.tinyurl.com/kloogx The requisite patch was released 'yesterday' (for some value of that tag for the majority - who live permanently in my past anyway), warranting its own version number (3.5.1): http://en-us.www.mozilla.com/en-US/firefox...1/releasenotes/ (with download link). This zaps several add-ins, including Google toolbar (darned if I can recall how it ever inveigled itself into my setup anyway, so good riddance*). [* on edit - yet still it lives! The tenacity! Oh well, the 'spanner' icon (RH side) of the Google toolbar accesses the 'uninstall' process - an alternative is to bury it at a crossroads with a wooden stake (and/or a silver bullet) through its heart and at the same time the intonation of the phrase Requiscat in Pace in suitably sepulchral tones might not go astray either, YMMV on any and all of the foregoing.]
  7. Update from 2.0 received 16 Dec. Soon after (though not immediately) attempts to address e-mail in Compose resulted in application freezing. Addressing through main profile address book not affected. Situation - Autocomplete enabled (Edit-Preferences-Mail & Newsgroups-Addressing-"Local Address Books" checked). XP-Home. Outlook Express had been used at some stage, address books included "OE Contacts". What worked for me - removing the .wab file at C:\Documents and Settings\Admin\Application Data\Microsoft\Address Book (Admin.wab). Only had a couple of addresses anyway, long since duplicated in personal address book. Caution - running wab.exe ("Address Book" under "Accessories") will restore a blank book there. That is enough to restore the problem too. Maybe using "Windows Live Messenger" too?1 Using Hotmail (sending) is enough to restore it anyway. But not, apparently, Yahoo. It doesn't restore on re-boot. Some small mercies. I've seen reference to the problem in networked installations where presumably a Directory Server is checked under the "Autocomplete" options. Unsure how that is fixed (other than to disable checking there which is a "no solution" solution). There is a 'bug' report lodged on this - https://bugzilla.mozilla.org/show_bug.cgi?id=535528 Someone goofed at the Snicker-Snak factory. Oh well, only superannuated survivors of the Netscape era use this free application anyway, I suppose. One day we'll all be gone and the humus will be richer for it. Ah, the pathos, the pathos! [edit]1 Yes, signing in to Messenger recreates the troublesome admin.wab file. Sooner or later. Maybe it is after a re-boot. Underwent a 279Mb 'upgrade' to find that out, the bulk of which were for mandatory other applications, supposedly connected in some way. The curse of a murrain on M$ and all its herds. I wonder how many people develop an abiding belief in the afterlife, not as much in the hope of personal salvation as in the happy anticipation of the divine retribution awaiting the sundry malefactors under whom they have suffered ungladly and for so long?
  8. swingspacers mentioned this resource back in June 2005. I've seen it crop up in discussion elsewhere from time to time (notably Mike Easter in the NGs). www.virustotal.com/en/indexx.html Submitted virus samples are checked against a raft of AV scanners and (default) your sample is forwarded to those that want it to test and update their definitions. Despite the best efforts of the botnet recruiters not many viruses get through the layered defences of most users these days . Needless to say, not every AV provider is right up to date on all threats and not every user is up to date with the latest definitions anyway. Thus the window of opportunity for the virus distributor. Here's one that made it to my inbox: http://www.spamcop.net/sc?id=z1179387135z3...;action=display Copying "postcard.exe" into a file (don't do that unless you are confident the thing is NOT going to run off and execute) and loading it into VirusTotal produced mostly negatives except: Confirmation, as far as I am concerned, of the incipient foray of the recruiters. And a heap of AVs (would) have missed it. Never open untrusted mail, never run untrusted executables (remembering all negatives from VirusTotal is NOT complete assurance) - but sometimes it is nice to know/ remind yourself what such discipline is all about.
  9. Farelf

    Secure your router ...

    http://www.networkworld.com/community/blog...y_pm_2011-04-25 I think "baffled" would be a faint name for it, were it me! Don't use wi-fi myself (but that seems to be the way the world is going, or large parts of it). The page for Securing a Linksys® router gives an idea of how to improve wireless network security: http://www.linksysbycisco.com/EU/en/learni...cureYourNetwork - it could pretty well serve as a template for the process with other types, it seems to me. Other explanations, tutorials, tips and comments would probably be useful - quite a few of the problems for which members seek assistance in these forums could be due to hijacked/piggybacked connections. One source for all of that is: http://whirlpool.net.au/wiki/Wireless_Home_Network_FAQ
  10. MxToolbox frequently mentioned here, thanks to member jay90210 of the Whirlpool forums for highlighting their header parsing tool "This tool will make email headers human readable by parsing them according to RFC 822." which helps with analysis - particularly with relay delays (converts times to common UTC) which might indicate service problems or clumsy forgeries etc.: http://mxtoolbox.com/EmailHeaders.aspx Individual analyses can be saved for discussion and/or comparison with SC parsing: http://mxtoolbox.com/Public/Tools/EmailHea...a8-9ce8ca8e6e7b http://www.spamcop.net/sc?id=z5447580466z5...4fa7b2aa07e056z Doesn't choke on IPv6 (doesn't extract/verify host addressing data from it either, but that's not its job): http://mxtoolbox.com/Public/Tools/EmailHea...c0-5df15bcf0957 http://www.spamcop.net/sc?id=z5438237110z6...d592fc42b57cddz Anyway, since apparent transmission delays are a fairly frequent query "here" (and some of us struggle with manual time-zone conversions, the back-to-front header sequence, etc.) this little facility may be of use.
  11. See fragile's solution (Shift-Alt-F) in http://forum.spamcop.net/forums/index.php?...amp;#entry82630
  12. 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.
  13. 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.
  14. 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
  15. 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 (?)
  16. 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
  17. Agree - and no, that "Received:" line doesn't look compliant - it should include IP address 216.82.255.55 for mail6.bemta7.messagelabs.com.
  18. 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.
  19. 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.
  20. Farelf

    namecheaphosting

    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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×