End-users have it easy with spam. They only have to delete a few hundred messages a day. For real spam misery, try being a network or e-mail administrator with tens of thousands of spam messages clogging up your network pipes or mail server's storage.

Fortunately, an old approach, mail server authenication, has often been suggested to stop spam that may be coming back in a variety of new forms. This tack is to modify how Simple Mail Transport Protocol (SMTP) works.

Today, when a mail server gets a message from any SMTP client, it passes it on to its destination without bothering to check if the user or domain is legitimate. It's that very trick that worms like MyDoom, Gibe and Netsky use to turn infected systems into spam generating machines.

SMTP's other problem, as anyone who has ever gotten spam from what appeared to be a friend knows, is that it doesn't do a decent job of stopping spammers from spoofing, aka forging, e-mail headers. Besides making you open messages you otherwise would never have touched, it's this security hole that makes phishing messages, e-mail that appear to be from a company you deal with that asks for personal information, the bane of naove users today.

So what you can do about it? Well, some have suggested that SMTP, which was written in an era when all computers were trusted, simply be dumped and replaced. That's an interesting notion but it hardly seems likely to happen since SMTP has displaced all other would-be popular Internet level mail protocols such as X.400. For better or worse, it's an SMTP world.

There have been also been attempts to modify SMTP. For example, there is already an Internet Engineering Task Force (IETF) SMTP over SSL/TLS protocol Request for Comment (RFC) - 2821, the standards for basic Internet protocols. However, using this, and other such methods require that servers, if not users, be authenticated as being legit by some third party directory service.

Other approaches, such as RFC-2015, would use MIME Security with Pretty Good Privacy (PGP), for authentication. Until recently, these ideas got more lip service than practice, but now major companies like Microsoft, Sendmail and Yahoo are moving in the authentication direction.

Sendmail, which claims that's its self-named e-mail server is used by seven out of the Fortune top ten companies, will work on developing and distributing sender authentication technologies. That doesn't mean however, Sendmail will be creating its own authentication scheme. Instead, Sendmail appears to be looking towards Yahoo's DomainKeys and Microsoft's "Caller ID."

DomainKeys would incorporate a public-key authentication system on top of SMTP. This would work by having each message digitally "signed" with a digital signature and public key for each domain. On the other side, the receiving e-mail system uses the public key to validate the signature. Since this signature is incorporated as a new header, and SMTP can already handle such headers, mail administrators would not have to update their mail servers.

They would, however, have to use a preprocessing program, or an add-on to their existing mail server to authenticate these signatures. In addition, this system would require a trusted third party directory system, like any public key encryption system, to ensure that the keys are authenticated. All this puts more of a load on the mail server. On the other hand, the overall load on the mail server and network should be reduced since it won't be sending on much bulker spam messages. Another plus for this method is it requires absolutely nothing from end-users.

Page 2: Microsoft's Caller ID