|Secure E-Mail: Problems, Standards, and Prospects
by Marshall T. Rose and David Strom
As we spend more and more time using e-mail, most of us eventually find that we need to be able to prove our identity to our correspondents and secure the contents of our messages so that others can't view them readily. Proving your identity is called authentication. In the physical world, this is accomplished by photo identification, such as a driver's license, passport, or corporate identity card. When the time comes to prove who you are (for example, before a major purchase), you show your card. Your appearance and signature match the photo and signature on your card, and the purchase is made.
On the Internet, however, the process isn't as easy. Does e-mail from email@example.com really originate from our friend Sidney at the Example Corporation? Maybe it's from someone else, who just happens to be using Sidney's machine when he is out to lunch. Or, worse, someone trying to impersonate Sidney illicitly. And even if the message actually is from the "real" Sidney, how can we be sure: Is there an electronic analog to a signature?
Most of us are trusting individuals; we tend to believe that people are who they say they are unless we have particular reasons to doubt their identity. But on the Internet, we have to look beyond face value. And proving that someone indeed did send a particular message is a very difficult problem.
This may be one of the main reasons why corporations employ Lotus Notes and other Internet-based messaging systems that are not 100 percent pure. They want to ensure that all messages carry the appropriate authentication with them at all times. In order for new users of Notes to start using the software, they must first obtain an electronic certificate that authenticates them to the system. The certificate is created by the Notes system administrator, who works in conjunction with that particular Notes server owned by that particular corporation.
Securing the message contents is also a challenge: all e-mail sent over the Internet, unless otherwise protected, is sent in clear ASCII text. If you have the tools, the time, and the technical expertise, you can capture this traffic and read anyone's correspondence. It isn't simple, but it is quite possible.
Besides being sent as clear text, e-mail can also be intercepted and its contents changed between the time the sender composes the message and the recipient reads it. Again, this task is neither likely nor simple, but it can be accomplished if someone is determined enough to do it. Therefore, senders can neither prove nor deny that they sent a particular message to you; it could be real or a forgery, and you have no way of knowing which.
It would be great if we could say that the future for secure e-mail is bright, and that there will be standards in place that will help. However, the state of secure e-mail standards for the Internet is best described as a "terrible mess"! (Ed.: a less charitable phrase is used in the book from which this material is adopted.) Think that characterization is unprofessional? It is actually quite detached, considering the amount of culpability enjoyed by the principals of the Internet's secure e-mail debacle. We would love to write an article describing the high crimes and misdemeanors of these scoundrels, but that would only publicize the guilty, not punish them. So, instead we'll survey the horizon and try to make sense of what little terrain there is.  In brief, no technologies for secure e-mail in the Internet meet all of the following criteria:
There are two competing technologies, each of which satisfies at most one of these criteria. However, for any 100 percent pure Internet solution to succeed, we feel it must be based on technologies that satisfy all three.
- Approved or endorsed by the Internet's standardization body
In order to understand secure e-mail, you need to know only three concepts:
- Data encryption (privacy)
- Message integrity (authentication)
- Key management
Everything else is a matter of data formats.
When the contents of a message are to be protected from third party disclosure, it is necessary to agree upon an encryption algorithm. Because cryptographic algorithms are constantly being scrutinized, a secure e-mail standard must be extensible with respect to the algorithms that it allows.
Historically, symmetric encryption algorithms are used for this purpose. A symmetric algorithm is one in which the same key is used to both encrypt and decrypt the data. Symmetric algorithms are chosen because they are computationally less burdensome (in other words, faster to execute) than asymmetric algorithms.
As such, each time a message is to be encrypted, a new session key is generated for that purpose. Although one could send the session key via some secure path, it is easier to include the session key along with the message, but encrypted so that only the intended recipient can decipher it. Upon deciphering the session key, the recipient can apply the encryption algorithm and retrieve the original contents.
For example, Network Associates' Pretty Good Privacy (PGP), one of the two technologies we'll examine, uses an asymmetric algorithm to encrypt the session key and a symmetric algorithm to encrypt the user's data.
When the contents of a message are to be verified as authored by a particular user and unaltered by any other user, it is necessary to agree upon a signature and hash algorithm. The former is used to verify the authenticity of the message, and the latter is used to verify the integrity of the message. Again, any secure e-mail standard must be extensible with respect to the algorithms that it uses for these purposes.
For signature algorithms, asymmetric algorithms are typically used. These algorithms utilize a public key and a secret key. A signature algorithm combined with a secret key allows someone to generate a digital signature for the contents of a message. A signature algorithm combined with a public key allows someone to verify the digital signature for a message. As you might expect, signature algorithms are one way functions: You can't reconstruct the input to a signature function by looking at its output.
Hash algorithms are often called message digest algorithms. They simply compute a checksum on their input; no keys are involved. Hash algorithms are also one way functions, and a good hash algorithm is one in which very similar inputs produce dramatically different outputs. Hence, if even a single bit is altered or corrupted in transit, the hash value will be different.
All discussion now hinges on how keys are used for asymmetric algorithms. Specifically, how do you trust the identity of the secret key used to make a digital signature? To start, we have to introduce the notion of a public key certificate. Although the actual formats vary, at its heart a certificate contains three things:
- The identity of the "owner" of the certificate
- A public key
- Zero or more guarantees to the validity of the binding between the identity contained in the key and the owner in the "real world"
So, the next step is to ask what these identities and guarantees look like. Unfortunately, we now enter the realm of sociology rather than technology. The only theoretical limitation on an identity is that you have to be able to represent it digitally. It could be a name (for example, "Jim Bidzos") or an e-mail address (for example, firstname.lastname@example.org) or a key in some database (for example, the name of an object in a directory). More interesting examples could include a series of assertions (for example, your driver's license number is this, your passport number is that, and so on).
Fortunately, the guarantees are a bit simpler to describe they are digital signatures from other public keys that vouch for the veracity of the binding. For example, if you encountered a public key certificate in which the identity was someone's passport number, it would be natural to expect that the certificate contains a digital signature from the government entity (or its agent) that issued the passport. However, this begs another question: Why should you trust the entities that have signed someone's public key? It turns out that our two contending technologies have different answers to that question.
As you might expect, certificates have some additional properties, such as a date the certificate becomes valid, the date the certificate expires, and a "fingerprint." The fingerprint is simply a hash of the identity and public key so you can tell if it has been altered in transit. Finally, certificate revocation lists identify certificates that are no longer valid. For example, if the secret key associated with a certificate is accidentally disclosed, then the corresponding certificate is revoked.
Pretty Good Privacy: The Web of Trust
Pretty Good Privacy (PGP) is encryption for the masses. Despite the fact that it required a couple of complete rewrites in order to achieve stability, it gets the job done.
An effort is under way to provide a "standards-based" version of the PGP technology, termed OpenPGP. The "prestandards" version of PGP uses the RSA algorithm for signatures and the IDEA algorithm for encryption. The version being developed is more flexible with respect to the algorithms it supports.
The most remarkable thing about PGP is its trust model. Remember the earlier question: How do you know whether you should believe the identity in a public key certificate? To answer this in the context of PGP, each user assigns two attributes to the PGP certificates that they encounter: trust and validity. Trust is a measure as to how accurate the certificate's owner is with respect to signing other certificates. Validity indicates whether or not you think the identity in the certificate refers to the certificate's owner.
So, initially your local collection of certificates starts out with one your own PGP certificate. You then sign your friend's certificate and he or she signs yours. Because you trust yourself when signing those certificates, your friend's certificates are automatically considered valid. Then, based on your judgment of your friend's abilities to sign other certificates accurately, you assign a level of trust to his or her PGP certificates. As you receive messages containing other people's certificates, if they are signed by you, or any of your trustworthy friends, they are automatically deemed valid. This organic, highly decentralized approach toward validating public key certificates is termed the web of trust.
Key servers are also available that are repositories of PGP certificates. If you need to send e-mail to someone, but don't have his or her certificate, you can query a server to see if a copy is there. Of course, the usual rules apply with respect to assigning trust and validity it's up to you! Key servers also help when you receive e-mail from someone new. Although the message will contain a copy of someone's PGP certificate, you may not know about any of the signatories. So, you can go to a key server and fetch the certificates for the signatories; you might decide to trust them after seeing who signed their certificates.
We've simplified the web of trust in that validity isn't "all or nothing," as we implied previously. Rather, PGP offers a flexibility spectrum of possibilities; for example, requiring two trustworthy signatories before considering a certificate to be valid. But the one thing that should be clear is that trust and validity are different. You will probably have many keys in your local collection of certificates that are considered valid, but probably only a few of those will be considered authorized to vouch for others.
Secure MIME: The Hierarchy of Trust
There is an interesting concept in advertising called "ambush marketing." The basic idea is that your advertising campaign leverages off the brand and promotion of a competitor. Secure Multipurpose Internet Mail Extensions, or S/MIME, is an example of ambush marketing in the Internet. Although MIME is an Internet standard, which has been implemented by hundreds of vendors and provisioned in tens of thousands of networks, S/MIME is the product of a closed vendor consortium.
S/MIME has two versions: version 2 and version 3. As of this writing, products that claim to implement S/MIME implement version 2. They use the RSA algorithm for signatures and a weak algorithm for encryption (RC2 with 40-bit keys). An effort is under way to provide a "standards-based" version of the S/MIME technology version 3. The version being developed is more flexible with respect to the algorithms it supports. S/MIME uses a hierarchical model for establishing trust. For example, if your employer assigns you an S/MIME certificate, he will act as a certification authority and sign that certificate. As a consequence, trust is established on the basis of a hierarchical relationship between the subject of a certificate (the identity) and the issuer (the signatory).
This model has some strengths: users rely on the certification authorities implicitly. However, a bootstrapping problem still exists: How do you know to trust the issuer? The answer is that your local collection of certificates also has some "top-level" certificate authorities, and it is these authorities that sign the public key certificates of the issuers. If the hierarchy of trust can be kept to one or two levels, this is manageable in practice.
The web and hierarchical models of trust share many attributes in common. For example, when you receive a message, it contains a copy of the certificate that was used to make the digital signature. If you aren't familiar with the signatories, you can look in a remote repository of keys. The only difference between the two models here is that the hierarchical model needs key servers to make its key infrastructure work. Because of this, keys are usually stored in a directory service accessed via the Lightweight Directory Access Protocol (LDAP).
The multipart/encrypted and multipart/signed contents are used to convey secure e-mail. Fortunately, they are both very simple content types.
A multipart/signed content has two subordinate body parts. The first contains the data that is being authenticated and can be any MIME content type (text/HTML, multipart/mixed, and so on). The second contains the digital signature used to authenticate the content. The multipart/signed content has two mandatory parameters. The protocol parameter defines the technology used to generate the digital signature, and the micalg (for "MIC algorithm") parameter defines the hashing algorithm used (for "MIC" read: message integrity check). The value of the protocol parameter is also the content type used for the second body part. The only tricky part is that the digital signature is calculated on the data before a transfer encoding, if any, is applied.
Let's make this a little more concrete. If we assume that the OpenPGP effort produces an Internet standard based on the current draft (a reasonable assumption at 50,000 feet), then the structure of a multipart/ signed message created using PGP technology would look like the following:
The second body part, a data structure defined by the OpenPGP document, contains the digital signature along with any supporting material (for example, a copy of the sender's PGP certificate).
- The protocol parameter would be application/pgp-signature
- The micalg parameter would be pgp-md5
- The first body part would be labeled as whatever you wanted to sign
- The second body part would labeled as application/pgp- signature
Note that you don't encrypt the first body part in a multipart/signed content. In this way, if only some of your recipients have secure e-mail, but you still want to sign it for those who do, everyone can still read the first body part.
A multipart/encrypted content has two subordinate body parts. The first contains the information needed to decipher the encrypted data (for example, the encrypted session key along with an indication as to the certificate needed to decipher the session key). The second contains the encrypted data, labeled as application/octet-stream. The multi part/encrypted content has one mandatory parameter, protocol, which defines the technology used to encrypt the data. The value of the protocol parameter is also the content type used for the first body part. To further define this concept, if we use OpenPGP as the basis for a hypothetical example, then the structure of a multipart/encrypted would look like the following:
- The protocol parameter would be application/pgp-encrypted
- The first body part would be labeled as application/pgp-encrypted
- The second body part would labeled as application/octet-stream
In practice, the input to the encryption algorithm would be multipart/ signed. Finally, one or more MIME content types might be defined for sending certificates, certificate revocation lists, and so on. These are all specific to the particular secure e-mail technology being used.
Encrypting Your Messages
If we look at popular commercial e-mail products, many of them include support for some kind of encryption. Both Microsoft's Outlook Express and Netscape Messenger include support for S/MIME, although we'll see in a moment that the two have radically different capabilities. And Qualcomm's Eudora Pro package comes with an add on module for supporting PGP, which you may or may not have installed when you installed the software. In order to encrypt a message, you need to go through the following process:
- Choose which of the two competing technologies (and specific e-mail software) you wish to use for your encrypted correspondence. Both methods have advantages and disadvantages.
- Choose whether you want to just digitally sign your messages or encrypt their entire contents, or both.
- Either choose an enterprise certificate authority and set up the appropriate server software, or obtain a certificate from a public authority. Again, both methods have advantages and disadvantages.
- Enroll with this certificate authority and obtain an encryption certificate or key for a particular machine and a single e-mail address.
- Exchange keys with your correspondents, and manage where these keys are stored on your machine.
- Encrypt and decrypt messages.
If this process seems rather involved and complex, it is. The process is not nearly where it should be to enable encryption to be useful by most e-mail users, and won't be for some time. If all of this seems overwhelming to you, we certainly understand.  It is to us, too! But let's go through these six steps in more detail.
PGP vs. S/MIME
Our discussion in the standards section might have convinced you that encryption technology is still very much a work in progress, and after you begin to use the encryption features of your own e-mail software, you'll be further convinced. Nevertheless, unless you plan to test lots of different software products, you should first decide on which product and which encryption technology you intend to use. You definitely want to limit yourself to as small a universe as possible, because running more than one e-mail software product will only make your encryption life miserable. So which to choose?
PGP is everyman's product. It was designed for single individuals to use and still remains the easiest method to set up and get going, although it is far from simple. The version of PGP that comes with the Eudora Pro box is the individual version; a separate and more capable version is available for workgroups or businesses, called PGP for Business Security. This business version is the one we recommend, even if you are the only person in your corporation that will use encryption. You'll find that after you start, others will follow, and you might as well start off with the more capable version.
If you want to use PGP, you will need to run a separate piece of software to encrypt and decrypt your messages. If you already use software such as Messenger or Outlook Express, that is certainly more cumbersome than using the built in S/MIME features of those two products.
In 1999, PGP is more capable than S/MIME when it comes to setting up an enterprise encryption policy and putting it into practice on a daily basis. For example, with PGP you could establish that all outgoing and incoming encrypted messages are first copied to a special archive, and that all outgoing messages are encrypted with a special administrator's key that can be used in an emergency to read the message if the sender forgets his key or leaves the company. S/MIME doesn't have this ability yet, although this feature is being developed for the future.
PGP is a single vendor solution: All your software must eventually come from Network Associates to run the various certificate servers and encryption modules. With S/MIME, you'll have some degree of choice, although we found that in practice you probably want to make use of the same e-mail product when exchanging encrypted messages if you want them to be read with a minimum of difficulty. Not all S/MIME packages can exchange encrypted messages with each other because of differences in their implementations. When Dan Backman of Network Computing magazine tested five different products, he found several that couldn't read messages sent by others.  Part of the problem with S/MIME is the various choices of "strength" of cryptographic algorithms that are in use in today's browsers and e-mail software. This debate is more about politics than technology, because the U.S. government places restrictions on various algorithms, as mentioned earlier. Two different parameters are of interest: the length of the key itself used in any certificate and the type of encryption technology used. Netscape software supports key lengths ranging from 512 to 1024 bits, for example. In addition, several choices are available for encryption technology; they are labeled RC2 (which can either be 40-bit encryption, the only one allowed for export by the U.S. government, or more complex encryption of 64, 128, or even 255 bits), and Data Encryption Standard (DES). RSA, Inc., developed RC2. On the other hand, the U.S. government developed DES. Debate abounds as to which is the better or more or less proprietary technology. These details are outside the scope of this article, but you should know that the larger the key size and encryption algorithm, the more difficult it is for someone to decode an intercepted message. Digital Signature Required? Your next choice is to consider whether to just make use of a digital signature, to encrypt the entire message, or to make use of both technologies. All encryption products can do both, but in somewhat different ways.
Digital signatures guarantee that your recipients have received your message without any tampering and that they can trust that the message came from you. The actual message body, and any attachments, arrive without any encryption, meaning that someone could still capture this traffic and read your correspondence. You might want to use a digital signature without encrypting the message, if you care that your message was received intact and that your correspondents can know that you sent it.
There are two different types of signed messages: clear and opaque. With clear signed messages, you can still read the message text, even if you don't have any encryption functions in your e-mail software. The signature is carried along with the message in a separate MIME portion of the message from the message body, which remains untouched and still readable. This feature can be handy, especially if you correspond with many people and they probably haven't adopted any particular encryption product, or if they are using older versions of e-mail software that don't support encryption.
Clear signing is also useful in circumstances where your encryption technology isn't compatible with your correspondents' technology. PGP supports only clear signing in its products. One problem with clear signing is e-mail gateways. They often will break the encryption of the signature, because they will either add or remove characters from the message, and that sloppiness could invalidate the signature block. After all, part of the role of the signature is to ensure that the message was delivered intact and unaltered! Opaque signing means that your recipients will get a blank message if they aren't running any encryption software, or if their encryption software doesn't work with yours. Opaque signing wraps the entire message in a Base64 encoding, which is usually left alone by most e-mail gate ways. This encoded message then gets transmitted and then decoded by the S/MIME recipient. PGP places its signature inside the encrypted envelope when it sends messages, making it difficult to determine the signature of such a message until you first decrypt it. The PGP producers claim that this feature offers extra protection in case the message is compromised or copied en route. Newer versions of PGP offer a MIME option that places the signature outside the encrypted envelope. This is how S/MIME products work, making it easier to determine who sent it.
Choose Your Certificate Authority
Now you have another decision to face, and that is how to set up what is called the certificate authority (CA) for your enterprise. This software runs on a UNIX or NT server and manages the keys or certificates of everyone in your corporation. It serves as a central place of trust and signs all of your users' certificates. If you trust your CA, in theory you should be able to trust the certificates that are signed by the CA, called inherited trust.
The problem is that there isn't any "central" CA for the entire universe of e-mail users. Although there are several public CAs that anyone can use, either for free or for a fee, they don't necessarily trust each other, nor should they. What happens if an employee of VeriSign becomes disgruntled and starts issuing bad certificates? There should be checks and audits to ensure that these types of problems can't undermine the entire CA system, just as there are checks and audits to prevent rogue banking employees from crediting their own accounts.
Setting up a CA is the beginning of setting up a very complex security infrastructure for your enterprise. Your CA needs to establish a link of trust from all your users to the administrator or operator of the CA itself, and from your CA to other CAs with which you communicate.
There are two different kinds of CAs: One uses software that you install on your own server inside your enterprise and you maintain; the other is public servers. Having your own server places the burden on creating and revoking certificates on your security administrator, or whoever is going to operate the CA server. In many cases, these products can be administered from a Web browser after they are installed, and the servers can handle certificates from a wide variety of S/MIME products, one of the few shining spots on the interoperability scene at the moment. PGP for Business comes with its own version of a certificate server. It runs on a Windows desktop machine and typically is used by the administrator of the entire security apparatus to handle certificates. It can handle only PGP certificates.
Some popular software products that function as certificate servers are listed below.
Vendor URL Product Enterprise CAs: Netscape Xcert www.netscape.com www.xcert.com Certificate Server Sentry CA Public CAs: VeriSign Thawte www.verisign.com www.thawte.com Secure Server ID Public CA
Enroll and Acquire Your Certificate
When you have your certificate authority either in mind or installed, you next have to set up how you want to acquire your own certificate.
You have two broad methods: by Web or by e-mail. Actually, you don't have any choice: If you have picked your e-mail product and CA at this point in the process, you have to use whatever method comes with that choice. Netscape Messenger and Microsoft's Outlook Express, among others, make use of their related Web browsers to enroll certificates, as you might suspect. And other products make use of e-mail to send and enroll certificates. For example, Xcert's Sentry CA sends you a message telling you that your certificate has been granted, but in the e-mail it has URLs for both Communicator and Internet Explorer where you can download the certificate and place it inside the appropriate software. Why two different links? Because each product supports a different way of acquiring certificates, of course. So much for standards.
Exchange and Manage Certificates Now comes the hard part dealing with the certificates of your correspondents, and managing both theirs as well as other certificates around your corporation. As we mentioned in our standards section, you need to exchange certificates with your correspondents before you can begin to exchange encrypted e-mail. And that means sending your public key to them, and getting their public keys from them, before you can exchange actual encrypted messages. If you are corresponding with someone who doesn't have the same CA in common, you'll first need to establish a trust relationship and exchange root CA certificates before you can exchange the individual certificates. This is somewhat painful, but when you get the hang of it, it isn't that difficult. After you begin to exchange more than a few of these certificates, you might think that this is a job for a directory server, and, thankfully, the vendors are already there. The CA server can set up entries in an LDAP directory to keep track of who is issued a certificate, and you can query this LDAP server to find who has them. That is the good news, and indeed the PGP product makes use of its own LDAP server to keep track of its certificates. However, the LDAP server is only used by PGP; if you want a general purpose LDAP server to keep track of your users, you'll have to install something else.
As a challenge for open systems and interoperability, we installed the Xcert Sentry CA and Netscape's Directory Server on a test network. The Xcert was used to create and manage our certificates for our test corporation, and the entries were placed in the Netscape LDAP directory. We created the certificates using the Netscape browser and stored the information in our Messenger e-mail software. After going through the process described previously, we had a valid certificate and could see it in the Security|Messenger settings. Although the Sentry CA couldn't automatically deposit a certificate in the Netscape LDAP server, we (operating as the security administrator) could do so with a few simple Web forms and keystrokes. So far, so good.
The challenge was trying to pry these certificates loose using other products, such as Outlook Express. There we ran into trouble, mainly because the Netscape software creates the certificate in a nonstandard place in the LDAP directory. According to the standards documents, the certificate should be placed in a particular spot in the LDAP directory schema, called usercertificate. Netscape, for whatever reason, places them at a location called usersmimecertificate. This meant that non Netscape products couldn't view the certificates in our directory, because they were looking in the wrong place.
This brings up a very good point: The connection between a user and his or her certificate is tenuous at best. Just because you know that email@example.com is the e-mail address of David Strom and you have his certificate, it doesn't mean that any of your expensive software tools can make this connection. This situation will create all sorts of headaches for your security administrators, and it means that you need to maintain at least two directories on your own machine one for users and one for certificates. It would be nice if the address books of our e-mail software could handle this automatically, but they don't. That's not the only issue with managing certificates. What if someone leaves the company? Or changes his or her e-mail address? Or if you want to use the same certificate, but on several different machines? Most certificates are tied to a particular machine and a particular e-mail address, meaning that any new address will require a new certificate. Again, we find this situation unacceptable.
Encrypt and Decrypt Messages
Now you can finally go and encrypt your messages. Various options are available in your e-mail software to do this, and you can choose to sign a message as well as to encrypt it.
That is the encryption portion. What about the decryption side? If you have done your homework and exchanged certificates as we discussed earlier, then when you receive your encrypted message, it should automatically decrypt and display in plain text. You shouldn't have to do anything else unless the encryption system is broken by a gateway or product incompatibility.
The obvious question is whether the Internet needs two standards for secure e-mail.
Proponents for both sides can make superficially compelling arguments. PGP proponents point to a grassroots constituency and a huge installed base of legacy systems. PGP emphasizes privacy for individuals. S/MIME proponents, on the other hand, point to some major vendors and an emphasis on nonrepudiation.
If history is any judge, the PGP side will win because less infrastructure is required to make it work. S/MIME has to solve all the problems that PGP has to solve, plus a few more. However, these things aren't decided overnight. So, our prediction is rather straightforward: The two sides will compete in the Internet marketplace for a couple of years, but ultimately the game is PGP's to lose. It requires less infrastructure and fewer broad agreements to achieve ubiquity.
 Our thanks to Dan Backman of Network Computing magazine for his help in sharing his lab and providing many valuable insights in the preparation of this article. This article is based, in part, on Internet Messaging: From the Desktop to the Enterprise, ISBN 0-13-9786100-4 Prentice-Hall, 1998.  See http://strom.com/places/smime.html for details regarding product interoperability testing for encrypted e-mail packages.  There is an alternative to this process. The United Parcel Service has produced a file transfer utility called NetDox, available at www.netdox.com. It requires special software to be installed on each computer, and it simplifies the certificate and encryption process somewhat. But this is yet another proprietary solution to the encrypted e-mail problem something we think goes in the wrong direction.  The article has more in depth examination of testing MIME interoperability and features of Messenger, Outlook Express, Baltimore's MailSecure, OpenSoft's ExpressMail, and two Worldtalk plugins for Eudora and Outlook Express. See "Secure E-Mail Clients: Not Quite Ready for S/MIME Prime Time. Stay Tuned." Network Computing, February 1, 1998, techweb.cmp.com/nc/902/902r2.html.
MARSHALL T. ROSE is Chief Technology Officer of MessageMedia Inc. (formerly First Virtual Holdings, Inc.). He is responsible for the design, specification, and implementation of several Internet standard technologies and is an author of over 60 of the Internet's RFCs, and several books on Internet technologies. He can be reached at firstname.lastname@example.org
DAVID STROM is an independent consultant and frequent speaker at NetWorld+Interop shows around the world, where he teaches a class on e-commerce and Web storefronts. He was founding editor in chief of Network Computing magazine and has written over a thousand articles for various computer trade publications. He is also publisher of the e-mail newsletter Web Informant, an almost weekly series of essays on Web marketing, technology, and culture. He can be reached at email@example.com