VSoft Technologies Blogs

rss

VSoft Technologies Blogs - posts about our products and software development.

Why are spam filters so dumb?

I just sent out an email blast to FinalBuilder users with info on the latest Finalbuilder 3 beta. In the email I included a few lines of sample vbscript & javascript to illustrate a new feature in the code completion in FinalBuilder 3. The response was amazing, I have a ton of replies from spam & virus  filters telling me my email contained a worm/virus/or some other disease or was spam and was blocked.

Now excuse me for being so dumb.. but this was a plain text message, how the hell can that be deemed a worm or virus.. are email clients really that stupid that they just execute anything that looks like script? Am I missing something here? Oh, and these mail server based spam & virus filters were all well know and high priced products (I looked up a few).. I wonder if these people know how much email they are missing as a result of bad logic/over zealousness.

Oh, if you didn't get the email and you should have... you know where to look first before contacting me :)

 

 

Related Posts


  • New VSoft Forums

    After years of frustration with Active Forums on Dotnetnuke, we finally got around to moving to a new forums platform. Forunately we are able to keep most of the old content!

  • A Simple IoC Container for Delphi

    This is a really simple (but still useful) IoC container for Delphi 2010 or later.

  • EC2 Support in FinalBuilder 7.0

    FinalBuilder 7.0.0.1497 adds support for Amazon's EC2 Cloud Services.

  • DUnitX Updated : Filtering Tests

    DUnitX has been updated to support filtering of tests from the command line.

  • Dealing with email... and growing pains

    One of the difficult issues we face as a small isv, is managing growth. The fact is we are growing and our customer base is expanding, which is great

  • Continuous Integration Server performance

    Continuous Integration Servers are often underspecified when it comes to hardware. In the early days of Automated Builds, the build server was quite often that old pc in the corner of the office, or an old server in the data center that no one else wanted. Developers weren't doing many builds per day, so it worked, it was probably slow but that didn't seem to matter much. Fast forward 20 years, and the CI server is now a critical service. The volume and frequency of builds has increased dramatically, and a slow CI server can be a real problem in an environment where we want fast feedback on that code we just committed (even though it "worked on my machine"). Continuous Deployment only adds to the workload of the CI server. In this post I'm going to cover off some ideas to hopefully improve the performance of your CI server.
Spam filters
Showing 0 Comment


Comments are closed.