The following is tip #17 from "20 Tips on securing Outlook in 20 minutes," excerpted from a chapter in Paul Robichaux's...
book, Secure Messaging with Microsoft Exchange Server 2003 © 2004, published by Microsoft Press. Return to the main page for more tips on this topic.
Table 2: Policy Settings for Outlook Cryptographic Features
|Value Name||Data Type||Supported Values||Notes|
|AlwaysEncrypt||DWORD||1: All outgoing messages are encrypted. 0: Default; outbound messages are only encrypted by user request.||If Outlook cannot find a certificate for a recipient, you'll see an error dialog box like the one shown in Figure 13-11.|
|AlwaysSign||DWORD||1: All outgoing messages are signed.
0: Default; outbound messages are only signed by user request.
|ClearSign||DWORD||1: All outbound messages include the message in cleartext, with a separate signature part.
0: Messages are signed with a combined signature/message block; the message is not present in cleartext.
|Clear-signed messages allow recipients who aren't using S/MIME-capable clients to read the message, even though they cannot verify the signature.|
|RequestSecureReceipt||DWORD||1: All outbound messages contain a signed receipt request; compliant clients will automatically return signed receipts when the message is opened.
0: Receipts must be individually requested.
|S/MIME receipts are digitally signed, as is the request. The S/MIME specification requires compliant clients to honor receipt requests, without including an option to suppress receipts like Outlook does for ordinary messages.|
|ForceSecurityLabel||DWORD||1: Every outbound message must be given a security label before it's sent.
0: Unlabeled messages can be sent.
|This option is only useful if you're using a security labeling policy module.|
|ForceSecurityLabelX||Binary||All messages sent automatically include this administrator-defined label.||Label must be stored as an ASN.1-encoded string. If you don't know what that means, you probably won't benefit from this feature.|
|SigStatusNoCRL||DWORD||1: If the certificate revocation list (CRL) for a signing certificate cannot be found, treat it as an error.
0: Treat the missing CRL as a warning.
|This option gives you control over whether users can accept messages with missing CRLs as valid or not.|
|SigStatusNoTrustDecision||DWORD||2: "No trust" decisions are treated as errors.
1: "No trust" decisions are treated as warnings.
0: "No trust" decisions are allowed.
|This value controls what Outlook does when the signatures and certificates on a message don't chain upward to a trusted root. Setting this value to zero can lead to malicious spoofing if you are not careful. See the Microsoft white paper at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prod technol/WinXPPro/support/tshtcrl.asp.|
|PromoteErrorsAsWarnings||DWORD||1: Treat level 2 errors as warnings
0: Treat level 2 errors as errors
|Level 2 errors occur when the message signature appears to be valid, but something else is wrong (for example, no CRL can be found, the CRL or certificate trust list [CTL] is out of date, or the issuer certificate is missing).|
|PublishToGALDisabled||DWORD||1: Disables the Publish To GAL button.
0: Button functions normally.
|FIPSMode||DWORD||1: Force Outlook to FIPS 140-1 compliance mode.
0: Outlook is not forced to FIPS 140-1 mode.
|As described in Chapter 2, FIPS 140 is the U.S. government standard for cryptographic algorithm performance and security. When Outlook is in FIPS 140-1 mode, the set of signing and encryption algorithms it can use is somewhat restricted.|
|WarnAboutInvalid||DWORD||2: Never give users warnings when invalid or improper certificates or signatures are found.
1: Always show the Secure E-Mail Problem dialog box when a problem occurs.
0: Ask the user each time whether a particular warning should be displayed.
|By default, Outlook will warn users when a problem occurs in a secured message, along with displaying a Show And Ask check box that lets users ignore the problem and see the message anyway. This value controls whether users are given that choice when a problem message is encountered.|
|DisableContinueEncryption||DWORD||1: Hide the Continue Encryption button.
0: Show the button.
|When you send a message to multiple recipients, if for some reason you can't send to a particular recipient, Outlook displays a button that lets you continue encrypting the message to the remaining recipients. If you want to prevent users from sending unencrypted messages, you'll have to turn this off.|
|RespondToReceiptRequest||DWORD||0: Always send signed receipts when requested; only prompt for a password if it's needed.
1: Always send signed receipts; always prompt for the password.
2: Never send signed receipts.
3: Force receipts to be sent.
|Because signed receipts have to be signed, you'll have to enter your credentials to sign the receipt. If you cancel instead, the receipt won't be sent. Tweaking this value lets you control whether the receipt is sent or not.|
|NeedEncryptionString||REG_SZ||String that is displayed when the user tries to open an encrypted message for which he or she doesn't have an appropriate certificate.||This message can be used to tell users where or how to get their certificates.|
|Options||DWORD||1: Don't warn users when they try to open a signed message with an invalid||x|
|MinEncKey||DWORD||Set to the minimum key length to be used when sending encrypted messages.||Set this value to the key length you want to use: 40, 64, 128, or 168 bits. (Note that 40- and 64-bit encryption are too weak for most commercial applications.)|
|requiredCA||REG_SZ||Gives the name of the required CA; when this is set, Outlook won't sign or encrypt mail with certificates issued by any other CA.||x|
|EnrollPageURL||REG_SZ||URL for the page that users should be sent to when they click Get A Digital ID.||This string can contain three expansion variables: %1 is replaced with the user's display name, %2 is replaced with the user's SMTP address, and %3 is the code page ID for the user's preferred language.|
Get more "20 Tips on securing Outlook in 20 minutes!" Return to the main page.
About the author: Paul Robichaux is a partner at 3sharp LLC, author of several books on Exchange, Windows, and security, a Microsoft MVP for Exchange Server, and a frequent speaker and presenter at IT industry conferences. He's written software for everyone from the U.S. National Security Agency to scientists flying their experiments aboard the Space Shuttle, fixed helicopters in the desert and spent way too much time playing video games.