Patch problem

Having tried several patch products and purchased the St Bernard application, I have one major problem: There's no way to set up a patch repository for remote WAN sites. To patch my company's remote site for Windows 2000 SP4, I have to send that 124Mbyte file over the slow WAN link to every workstation instead of being able to designate a remote location.

Regarding how the solve the 'spam equation', spam is more than a nuisance, it's an expense most people fail to understand. I see customers forced to buy additional bandwidth and expensive upgrades for PCs and mail servers to deal with this phenomenon, not to mention service to fix problems caused by poorly written spyware.

Recently I was surprised at hearing a woefully poor second suggestion for dealing with spam: new laws.

We don't need politically inspired laws to curb spam; it's not just a bad idea, but an unworkable one. In the Internet age, a Web site can be built and housed anywhere in the world.

In the age of modern terrorism, do we need our law enforcement wasting resources chasing spammers? As we worry over taxes and budget deficits, do we want to create a big, wasteful, government bureaucracy to monitor and enforce compliance with such laws? No.

The best solution is not to reward spam. Don't do business with companies that use it, and tell them why. Filter it in corporate environments. Find the e-mail addresses of the site owners and put them on spam lists.

Citizens have always felt government should be less invasive in our lives, and should not be looked on to solve every petty annoyance we suffer. The Internet should not change this philosophy.

As a Webmaster managing seven divisional sites, I get a lot of spam. In the nine days I was on holiday recently, I got 648 spam messages; 12 were valid messages.

The best filter? If you shunt any HTML-encoded message into a folder marked "spam?" you'll catch 90 per cent of it with better than 99 per cent accuracy. Such a filter will catch a few newsletters, but they're no great loss. I've never had a valid HTML-encoded message that gained anything from the coding, nor an HTML message with information I could not afford to lose.

If all correspondence were in ASCII plain text or mime encoded, the spammers would land between a rock and a hard place: if they use HTML, it goes to trash; if they use plain text, filtering becomes more effective.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments