Exchange 2010 value name and type

CheckCRLOnSend (DWORD)

Exchange 2007 value name and type

CheckCRLOnSend (DWORD)

Exchange 2003 value name and type

CheckCRL (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

By default, if a certificate revocation list (CRL) distribution point in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web App will not display a warning notifying the sender that the certificate cannot be verified. Instead, it allows the e-mail to be sent.

When CheckCRLonSend is set to true, if a CRL distribution point in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web App will indicate a failure and prevent the e-mail message from being sent.

Exchange 2010 value name and type

DLExpansionTimeout (DWORD)

Exchange 2007 value name and type

DLExpansionTimeout (DWORD)

Exchange 2003 value name and type

DLExpansionTimeout (DWORD)

Values and defaults

Distribution List Expansion Timeout represents the time that it will take, in milliseconds, before a request to expand a distribution list will time out. The default value is 60000 (60 seconds). The minimum value is 0. Setting DLExpansionTimeout to 0 disables the ability to send encrypted e-mail to distribution lists. The maximum value is 2147483647. When DLExpansionTimeout is set to the maximum value, there is no distribution list expansion time-out and Outlook Web App will wait until the distribution list is expanded, regardless of how long expansion takes.

Explanation

This attribute controls how long Outlook Web App will wait, in milliseconds, for a distribution list in Active Directory to expand when sending encrypted e-mail before the operation fails.

When sending encrypted e-mail to a distribution list, Outlook Web App must expand the distribution list to retrieve the encryption certificate of each recipient for use in the encryption operation. The time this operation takes varies depending on the size of the distribution list and the performance of the underlying Active Directory infrastructure. While the distribution list is being expanded, the sender will receive no response from Outlook Web App. This attribute specifies how long Outlook Web App should wait for the full distribution list to be expanded. If the operation has not completed in the time specified by this value, the operation will fail and the mail will not be sent. The sender will be returned to the compose form, which will include an InfoBar that includes the following error message:

The action could not be completed. Please try again. If the problem continues, contact technical support for your organization.

Exchange 2010 value name and type

UseSecondaryProxiesWhenFindingCertificates (DWORD)

Exchange 2007 value name and type

UseSecondaryProxiesWhenFindingCertificates (DWORD)

Exchange 2003 value name and type

CertMatchingDoNotUseProxies (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

Outlook Web App tries to find the correct certificate in Active Directory for a recipient when sending encrypted e-mail. The certificate subject or subject alternative name values can contain an SMTP address as one of its values. Because a recipient can have multiple SMTP proxy addresses in the directory, the subject or subject alternative name of the certificate may not match the primary SMTP address. Instead it may match one of the proxy addresses.

If UseSecondaryProxiesWhenFindingCertificates is set to true, Outlook Web App will accept certificates that do not match the primary SMTP address of the recipient as valid. If UseSecondaryProxiesWhenFindingCertificates is set to false, Outlook Web App will accept as valid only certificates that match the primary SMTP address of the recipient.

Exchange 2010 value name and type

CRLConnectionTimeout (DWORD)

Exchange 2007 value name and type

CRLConnectionTimeout (DWORD)

Exchange 2003 value name and type

RevocationURLRetrievalTimeout (DWORD)

Values and defaults

CRL Connection Timeout represents the time it will take, in milliseconds, before a CRL connection request will time out. The default value is 60000 (60 seconds). The minimum value is 5000 (5 seconds). A maximum value of 2147483647 can be specified. If CRLConnectionTimeout is set to the maximum value, the connection will not time out.

Explanation

CRL Connection Timeout specifies the time, in milliseconds, that Outlook Web App will wait while connecting to retrieve a single CRL as part of a certificate validation operation.

Validating a certificate requires retrieving the certification authority's CRL from the CRL distribution point that is specified within the certificate. This operation must be performed for each certificate in the complete certificate chain.

When multiple CRLs must be retrieved, this key will apply to each connection. For example, if three CRLs must be retrieved and CRLConnectionTimeout is set to 60 seconds, each CRL retrieval operation will have a time-out limit of 60 seconds. If the CRL is not retrieved before the time-out limit that is specified, the operation fails. If CRLConnectionTimeout is set to less than 5000, the default value (60000) will be used. If CRLConnectionTimeout is set to the maximum, 2147483647, the connection will not time out.

Exchange 2010 value name and type

CRLRetrievalTimeout (DWORD)

Exchange 2007 value name and type

CRLRetrievalTimeout (DWORD)

Exchange 2003 value name and type

CertURLRetrievalTimeout (DWORD)

Values and defaults

CRL Retrieval Timeout specifies the time, in milliseconds, that Outlook Web App will wait while connecting to complete all of the CRL retrievals for a single message. The default value is 10000 (10 seconds). The minimum value is 0. The maximum value is 2147483647.

Explanation

This attribute resembles CRL Connection Timeout, however it specifies the time, in milliseconds, that Outlook Web App will wait to retrieve all CRLs when validating a certificate. If all CRLs are not retrieved before the time-out limit that is specified, the operation will fail.

When you set this value, it is important to remember that, in a certificate validation operation, CRL Connection Timeout is applied to each CRL retrieval and to the overall operation of all CRL retrievals. For example, if three CRLs must be retrieved and CRLConnectionTimeout is set to 60 seconds, and CRLRetrievalTimeout is set to 120 seconds, each CRL retrieval operation will have a time-out of 60 seconds and the overall operation will have a time-out of 120 seconds. In this example, if any individual CRL retrieval takes more than 60 seconds, the operation will fail. Also, if all the CRL retrievals take more than 120 seconds, the operation will fail.

Exchange 2010 value name and type

DisableCRLCheck (DWORD)

Exchange 2007 value name and type

DisableCRLCheck (DWORD)

Exchange 2003 value name and type

DisableCRLCheck (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, DisableCRLCheck prevents CRLs from being checked while certificates are being validated. Disabling CRL checking can increase the time it takes to validate the signatures of signed e-mail. However, it will also show revoked e-mail signed with revoked certificates as valid instead of not valid.

Exchange 2010 value name and type

AllowUserChoiceOfSigningCertificate (DWORD)

Exchange 2007 value name and type

AllowUserChoiceOfSigningCertificate (DWORD)

Exchange 2003 value name and type

Not available. This was a new feature in Exchange 2007.

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, AllowUserChoiceOfSigningCertificate lets users select which signing certificate to use to digitally sign e-mail when they use Outlook Web App with the S/MIME control. This is controlled only from the S/MIME options tab.

Exchange 2010 value name and type

AlwaysSign (DWORD)

Exchange 2007 value name and type

AlwaysSign (DWORD)

Exchange 2003 value name and type

AlwaysSign (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, AlwaysSign will force users to digitally sign e-mail when they use Outlook Web App with the S/MIME control. Also, the Options page and the Message Options dialog box will show the "Send signed e-mail" option as selected.

Exchange 2010 value name and type

AlwaysEncrypt (DWORD)

Exchange 2007 value name and type

AlwaysEncrypt (DWORD)

Exchange 2003 value name and type

AlwaysEncrypt (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, AlwaysEncrypt will force users to encrypt e-mail when they use Outlook Web App with the S/MIME control. Also, the Options page and the Message Options dialog box will display the "Send encrypted e-mail" option as selected.

Exchange 2010 value name and type

ClearSign (DWORD)

Exchange 2007 value name and type

ClearSign (DWORD)

Exchange 2003 value name and type

ClearSign (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

When set to true, ClearSign forces any digitally signed e-mail message that is sent from Outlook Web App to be clear-signed. The default setting for this attribute is true. Setting this value to false will cause Outlook Web App to use an opaque signature. Clear-signed e-mail messages are larger than opaque-signed signatures, but they can be opened and read with most e-mail clients, including clients that do not support S/MIME.

Exchange 2010 value name and type

IncludeCertificateChainWithoutRootCertificate (DWORD)

Exchange 2007 value name and type

IncludeCertificateChainWithoutRootCertificate (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x001)

Values and defaults

1=True, 0=False (default)

Explanation

The default behavior of Outlook Web App is to include only the signing and encrypting certificates, not their corresponding certificate chains, when sending signed or encrypted e-mail. This option may be necessary for interoperating with other clients, or in environments where intermediate certification authorities (CAs) cannot be reached by using the Authority Information Access attribute or by having the intermediate CA trusted in the Computer account of the Exchange 2010 mailbox server. When IncludeCertificateChainWithoutRootCertificate is set to true, signed or encrypted e-mail will include the full certificate chain, except for the root certificate.

This setting increases the size of signed and encrypted messages.

Exchange 2010 value name and type

IncludeCertificateChainAndRootCertificate (DWORD)

Exchange 2007 value name and type

IncludeCertificateChainAndRootCertificate (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x002)

Values and defaults

1=True, 0=False (default)

Explanation

Include Certificate Chain and Root resembles Include Certificate Chain Without Root Certificate, but, when it is set to true, it includes the root certificate and the full certificate chain.

When set to true, IncludeCertificateChainAndRootCertificate increases the size of signed and encrypted messages more than IncludeCertificateChainWithoutRootCertificate.

Exchange 2010 value name and type

EncryptTemporaryBuffers (DWORD)

Exchange 2007 value name and type

EncryptTemporaryBuffers (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x004)

Values and defaults

1=True (default), 0=False

Explanation

By default, all client-side temporary buffers that are used to store message data are encrypted by using an ephemeral key and the 3DES algorithm. This setting can be used to enable or disable encrypting the temporary buffers. Disabling encryption of the buffers can increase performance of the Outlook Web App client. However, it leaves information unencrypted in the buffer of the local system. Before you disable this feature, see your organization's security policy.

Exchange 2010 value name and type

SignedEmailCertificateInclusion (DWORD)

Exchange 2007 value name and type

SignedEmailCertificateInclusion (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x008)

Values and defaults

1=True (default), 0=False

Explanation

By default Outlook Web App with the S/MIME control installed includes both signing and encrypting certificates with signed e-mail. When you disable this setting by setting SignedEmailCertificateInclusion to false, the size of messages that are sent from Outlook Web App with the S/MIME control will decrease. However, recipients will not have access to the sender's encryption certificate in the received message. They will have to obtain that certificate another way, either by retrieving it from a directory or obtaining it from the sender.

Exchange 2010 value name and type

BccEncryptedEmailForking (DWORD)

Exchange 2007 value name and type

BccEncryptedEmailForking (DWORD)

Exchange 2003 value name and type

SecurityFlags (values 0x040, 0x080)

Values and defaults

0=One encrypted message per Bcc recipient (default)

1=One single encrypted message for all Bcc recipients

2=One encrypted message without Bc forking

Explanation

By default, Outlook Web App will submit a separate encrypted message for each recipient on the Bcc line of an encrypted message. This option provides the most security for Bcc recipients of an encrypted message. By changing the value of BccEncryptedEmailForking, you can require Outlook Web App to create a single encrypted message for all Bcc recipients or one encrypted message without a separate message for each Bcc recipient.

Exchange 2010 value name and type

IncludeSMIMECapabilitiesInMessage (DWORD)

Exchange 2007 value name and type

IncludeSMIMECapabilitiesInMessage (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x100)

Values and defaults

1=True, 0=False (default)

Explanation

When IncludeSMIMECapabilitiesInMessage is set to true, Outlook Web App will add attributes to outgoing signed and encrypted messages that indicate which encryption and signing algorithms and key lengths are supported.

Enabling this attribute will increase the size of messages. However, enabling it can make it easier for some e-mail clients to interoperate with Outlook Web App.

Exchange 2010 value name and type

CopyRecipientHeaders (DWORD)

Exchange 2007 value name and type

CopyRecipientHeaders (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x200)

Values and defaults

1=True, 0=False (default)

Explanation

When it is set to true, CopyRecipientHeaders puts a copy of the From, To, and Cc recipient headers in the signed part of the message. This allows the recipient to verify that these headers were not tampered with while the message was in transit. Enabling this feature increases the message size.

Exchange 2010 value name and type

OnlyUseSmartCard (DWORD)

Exchange 2007 value name and type

OnlyUseSmartCard (DWORD)

Exchange 2003 value name and type

SmartCardOnly (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When it is set to true, OnlyUseSmartCard forces the use of smart card-based certificates for signing and decryption when you use Outlook Web App together with the S/MIME control. Users cannot use certificates not on a smartcard.

Exchange 2010 value name and type

TripleWrapSignedEncryptedMail (DWORD)

Exchange 2007 value name and type

TripleWrapSignedEncryptedMail (DWORD)

Exchange 2003 value name and type

TripleWrap (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

When TripleWrapSignedEncryptedMail is set to true, encrypted e-mail messages that are digitally signed are triple-wrapped. When a message is tripled-wrapped, the digitally-signed message is encrypted, and then the encrypted message is digitally signed. When set to false, the digitally signed message is only encrypted, there is no additional digital signing of the encrypted message. By default, this attribute is set to true. Triple-wrapped messages afford the most security for digitally-signed and encrypted e-mail under the S/MIME standard, but they are larger than messages that are not triple-wrapped.

Exchange 2010 value name and type

UseKeyIdentifier (DWORD)

Exchange 2007 value name and type

UseKeyIdentifier (DWORD)

Exchange 2003 value name and type

UseKeyIdentifier (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

By default, when encrypting e-mail, Outlook Web App will encode the lockbox where the asymmetrically-encrypted token that is required to decrypt the rest of the message is stored. It encodes the lockbox by indicating the issuer and serial number of each recipient's certificate. This can then be used to locate the certificate and private key for decrypting the message.

An alternative way to locate the certificate and private key for decrypting the message is to use a certificate's key identifier by setting UseKeyIdentifier to true. Because a key pair can be reused in new certificates, using the key identifier for encrypted e-mail enables users to keep only the most recent certificate and the associated private key, instead of all old certificates, which can only be matched by issuer and serial number.

By default, because some e-mail clients do not support finding certificates with a key identifier, Outlook Web App uses the issuer and serial number of each recipient's certificate. However, enabling this feature can make it easier to manage encrypted messages by eliminating the need for users to keep old, expired certificates on their system.

Exchange 2010 value name and type

EncryptionAlgorithms (Reg-SZ)

Exchange 2007 value name and type

EncryptionAlgorithms (Reg-SZ)

Exchange 2003 value name and type

EncryptionAlgorithms (Reg_SZ)

Values and defaults

This key is a semicolon-separated list that represents the symmetric encryption algorithms to use when encrypting messages when using Outlook Web App together with the S/MIME control.

List format: {Well-known algorithm ID}[:key length to use]|[,Custom replacement algorithm OID]; {Well-known algorithm ID}[:key length to use]|[,Custom replacement algorithm OID]; …

Supported algorithms and their ALG_IDs:

• DES6601
  
  
• 3DES6603
  
  
• RC26602
  
  
• AES128660E
  
  
• AES192660F
  
  
• AES2566610
  
  

Key length is only applicable to variable-key length algorithms when the key length is not encoded into the algorithm ID itself. RC2 is the only such algorithm in the previous list.

Custom replacement algorithm OID   You can supply your own algorithm by implementing it within a cryptographic service provider (CSP), assigning it a custom object ID, and specifying the OID by using the EncryptionAlgorithms key. An OID must be specified together with a well-known algorithm ID. Outlook Web App needs a well-known algorithm ID so that it can infer how the algorithm should be used. For example, to provide a custom replacement for the 3DES algorithm, you would specify the ALG_ID of 3DES (0x6603) and the custom OID of the replacement algorithm.

The values of the registry key should be listed from the longest key length to the shortest because the order reflects priority of use. For example, to list 3DES, RC2-128, RC2-64, DES, RC2-56, and RC2-40, type the value in the following way:

6603;6602:128;6602:64;6601;6602:56;6602:40

If the registry key is present, algorithms that are specified in the key will always be used. If the key is not present, Outlook Web App will fall back to its default internal list. This list begins with AES256 in computers that are running Windows Vista and with 3DES in computers that are running Windows XP.

The AES algorithms are only used if the user's computer supports them. AES is not supported on Windows XP and messages that are encrypted by using AES cannot be read on computers that are running Windows XP.

Explanation

Outlook Web App will try to use the strongest algorithm with the longest available key length on the user's computer. If the encryption algorithm or minimum key length is not available on the user's computer, Outlook Web App will not allow encryption.

Exchange 2010 value name and type

SigningAlgorithms (Reg_SZ)

Exchange 2007 value name and type

SigningAlgorithms (Reg_SZ)

Exchange 2003 value name and type

DefaultSigningAlgorithm (reg_SZ)

Values and defaults

The SigningAlgorithms key specifies the list of signing algorithms to use when signing messages using Outlook Web App with the S/MIME control installed. The following table enumerates the signing algorithms, their algorithm IDs, and the supported key lengths for each.

Format: {Well-known algorithm ID}

Well-known algorithm IDs, and key lengths

• CALG_SHA_512800E
  
  
• CALG_SHA_384800D
  
  
• CALG_SHA_256800C
  
  
• SHA10x8004
  
  
• MD50x8003
  
  

If the registry key is present, the algorithm that is specified in the key will always be used. If the key is not present, Outlook Web App will fall back to its internal default list. This list begins with SHA-1.

Messages that are digitally signed by using CALG_SHA_256 cannot be verified on computers that are running Windows XP.

Explanation

This attribute specifies the digital signing algorithm to use when digitally signing messages by using Outlook Web App together with the S/MIME control.

Exchange 2010 value name and type

ForceSMIMEClientUpgrade (DWORD)

Exchange 2007 value name and type

ForceSMIMEClientUpgrade (DWORD)

Exchange 2003 value name and type

Not available. This was a new feature in Exchange 2007.

Values and defaults

1=True (default), 0=False

Explanation

When ForceSMIMEClientUpgrade is set to true, if the client control version on the user's computer is older than the version on the server, the user must download and install the new control before they can continue to use any S/MIME Read or Compose forms. If this value is set to false, the user will receive a warning if the S/MIME control on their computer is older than the version on the server. However, they will be able to use S/MIME without updating the control.