You can now relate the use of the Send As function to the mailbox of the person who clicks Send. (However, if multiple users sent messages at the same time, you might have to perform a little detective work to see which user sent which message.) These diagnostic logging settings will cause an increase in the number of items written to the Application event log, so you might want to increase the log's maximum size. The advantages of this additional layer of accountability and tracking clearly outweigh the additional logging overhead. If your system is busy enough that these log entries threaten to overwhelm your logs such that you risk missing other more crucial log entries, I suggest you look at products such as Hewlett-Packard's (HP's) OpenView or NetIQ's AppManager. These applications can help you manage your event logs.
Verifying Message Authenticity
To ensure the integrity of messages that users send from an anonymous mailbox—or any mailbox, for that matter—you need a way to validate that a message originated from the identified sender and that the message wasn't modified in transit. An unfortunate side effect of SMTP's simple nature is that someone can easily spoof (i.e., impersonate) the sender of a message. This means that anyone can specify any address in the From field of a message header. When an Outlook user receives such a message, he or she might easily believe that a spoofed message is authentic. For example, Figure 6 shows a message sent to the All Staff distribution list (DL), which has the SMTP address all-users@demo.com. To generate this message, I used the Telnet utility to connect to my system's SMTP server and issue the following SMTP commands and data:
HELO mysystem.demo.com
MAIL FROM: mrbig@kaos.org
RCPT TO: all-users@demo.com
DATA
From: <vpo@demo.com> VP of Operations
To: All Staff
Subject: Early Dismissal
You are authorized to leave early (2 hours) because of the ice storm.
Kevin
Exchange accepted and delivered the message to the All Staff DL. Unless recipients examine the details of the message's SMTP header, they won't know that the message originated outside of the system and is a fake. (A typical user probably won't even know what to look for in a message header.) Depending on which Outlook version users are running, if they did take the time to double-click the Sender and look at the Properties, they might be even more convinced the message is authentic. Exchange and Outlook versions released before the release of Windows XP use the SMTP addresses provided on the To: and From: lines of the SMTP session to find the corresponding AD or Exchange Directory objects. After locating the objects, Outlook reads property information from the Directory and displays additional details such as the Address and Phone Number fields, adding to the illusion of authenticity.
Digital Signing Technology
Because Outlook uses the information on a displayed message's From field to determine the message's sender, you have few options for verifying a sender's identity, short of requiring every inbound connection to authenticate. A more realistic solution is to use digital signatures. Digital signatures use public-key and private-key certificate technology to ensure that the sender is uniquely identified and that the message wasn't altered in transit. Figure 7 shows the process of digitally signing and verifying a message. Digital signatures use an algorithm to create a digest or summary from the content of an email message. At the message's point of origin, the email client uses the sender's private key to encrypt the digest—the encrypted digest becomes the digital signature. The email client appends the digital signature to the message as a MIME-encoded attachment and sends the message to recipients. At each recipient machine, the email client decrypts the digital signature by using the sender's public key to produce a copy of the digest the sender generated. Next, the recipient's email client creates a version of the digest by using the message contents and the same digest algorithm that the sending client used. If the two copies of the digest match, the message wasn't altered in transit; the sender's identity is verified because only the sender's private key will correspond to the public key that the receiving client used to successfully decrypt the first digest.
Putting Digital Signatures in Place
Implementing digital signatures on a mailbox-by-mailbox basis is fairly easy, with only a few requirements. First, both the sender and recipient must have a mail client capable of generating and validating digital signatures. Outlook XP is configured out of the box to use digital signatures. Earlier versions of Outlook need a few configuration changes to properly process and validate digital signatures. The sidebar "Validating Digital Certificates in Outlook," page 10, explains in more detail how Outlook processes digital signatures. If you haven't yet deployed Outlook XP, the minimum version of Outlook I recommend you use is Outlook 2000 Service Release 1a (SR1a). The SR1a version fixes problems related to processing certificate revocation lists (CRLs—lists of certificates that have been canceled because of things such as lost or compromised private keys). Next, you need a digital certificate tied to the sender's email address. The digital certificate has two parts—a public key and a private key, as I described—and is issued by a Certificate Authority (CA). The CA can be the organization that maintains the email system or an outside organization that acts as a trusted and impartial third party. This impartial third party validates the identity of the sender (the first party) and issues a certificate to the sender and confirms to the recipient (the second party) that the sender is who he or she claims to be. The CA performs this function by making available the public-key portion of the certificate that identifies the organization as a CA. This certificate is called the root or intermediate CA certificate, depending on the CA type. When the CA issues a certificate for an individual email address, the CA uses the private-key portion of the CA certificate to sign the certificate. A recipient examines a sender's public-key certificate and uses the CA's signing data and public-key certificate to validate that the CA issued the sender's certificate. If the CA's signature is valid, the sender's certificate is implicitly trusted, forming what's called a trusted certificate chain.
Prev. page
1
[2]
3
next page 
