6 Appendix A: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
Windows 2000 Server operating system
Windows Server 2003 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Windows Server 2012 R2 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.5: The Windows implementation uses the Microsoft SMTP service (SMTPSVC) as the delivery agent. SMTPSVC is an optional component in applicable Windows Server releases. The SMTP service is independent of Microsoft Exchange; it is a stand-alone service with functionality similar to Sendmail.
<2> Section 2.1: DCs that are running Windows automatically initialize the mailAddress field. DCs that are running Windows set the local-part of the mail address to the mail recipient named "_IsmService". DCs that are running Windows register a secondary domain for themselves in DNS by using the GUID of their NTDSA object (as specified in [MS-ADTS]) as the most specific label. The format of the GUID-based DNS name for a DC is as specified in [MS-ADTS]. DCs that are running Windows use this GUID-format DNS alias in the domain portion in their mailAddress.
<3> Section 2.1: A DC that is running Windows logs SMTP delivery status notifications (DSNs) for DRS Protocol Extensions for SMTP messages in the Windows Event Log.
<4> Section 2.2.3: As a sender, Windows 2000 Server can set the CompressionVersionCaller field to DRS_COMP_ALG_MSZIP in a V1 frame with a non-compressed payload. As a receiver, if the CP bit of the dwMsgType header field is 0 in a V1 frame, then Windows treats the CompressionVersionCaller field of such frame as if it were set to DRS_COMP_ALG_NONE.
<5> Section 2.2.3: Windows 2000 Server systems set the cbDataOffset field to 0 in a V1 frame. Windows Server 2003 and later systems set the cbDataOffset field to 32 in a V1 frame. However, Windows Server 2003 and later systems accept V1 frames with cbDataOffset equal to 0 or with cbDataOffset equal to 32.
<6> Section 2.2.3: As a sender, Windows 2000 Server can set the dwMsgVersion field of a V1 frame to 0x00000000. Upon reception of a V1 frame with the cbDataOffset field set to 0, Windows uses the RP and RQ bits of the dwMsgType field to determine the message version using the following logic.
If the RP bit in the dwMsgType field is 1, then the payload is a DRS_MSG_GETCHGREPLY_V1 message.
If the RQ bit in the dwMsgType field is 1, then the payload is a DRS_MSG_GETCHGREQ_V4 message.
<7> Section 2.3: A DC running Windows 2000 Server can process messages sent to it that use either type of certificate (Domain Controller Replication or Directory Email Replication); however, it will send only requests that use a Domain Controller Replication certificate. A DC that is running Windows Server 2003 and later can process messages sent to it that use either type of certificate. When sending requests, a DC running Windows Server 2003 and later prefers the Directory Email Replication certificates over the DC Replication certificates, if both are available. The type of certificate that is used when sending a request does not depend on the operating system of the receiving DC. The certificate that is used to sign the request is sent by the client as part of the request, and is used by the server to encrypt the response.
<8> Section 2.3.1: A computer running applicable Windows Server releases will use Domain Controller Replication certificates that contain the following X.509v3 extensions specific to Windows.
Certificate template name
OID = 1.3.6.1.4.1.311.21.6.
The certificate has the template name extension with the value "DomainController" encoded in BMPSTRING format, as specified in [MS-WCCE] and [UNICODE4.0].
For more information about certificate template names and certificate templates, see [MSFT-TEMPLATES].
<9> Section 2.3.2: A computer running applicable Windows Server releases will use Directory Email Replication certificates that contain the following X.509v3 extensions specific to Windows.
Application Policies (Policy Identifier = Directory Email Replication Agent)
Certificate template information
Template = Directory email Replication(1.3.6.1.4.1.311.21.8.3692315854.1256661383.1690418588.4201632533.1.29)
Major version number
Minor version number
<10> Section 2.4.3: The Windows implementation registers in the DNS a secondary host name for the DC that is based on the GUID of its nTDSDSA object. This alias is the GUID-based DNS name. The Windows implementation uses the GUID-based DNS name in the domain field of its mailAddress.
<11> Section 3.1.3: The Windows implementation adds dictionary entries for partner DCs dynamically during operation.
<12> Section 3.2.4.2: In the Windows implementation, if the size of the Send-Message-Serialized-Data byte stream is less than 1024 bytes, the message is not compressed.
<13> Section 3.2.4.3: For encryption, by default, Windows Server 2008 uses the AES128 encryption algorithm, but it can be configured to use the RSA RC4 encryption algorithm. The configuration mechanism is outside the scope of the protocol.
For decryption, Windows Server 2008 uses the algorithm from the messages as specified in "PKCS #7 format" [RFC2315] and is able to decrypt messages sent by Windows 2000 Server or Windows Server 2003. Windows 2000 Server and Windows Server 2003 use the RSA RC4 encryption algorithm and are only able to decrypt messages encrypted using the RSA RC4 encryption algorithm, so if the format in "PKCS #7" is set to AES128 encryption, the messages cannot be decrypted.
<14> Section 3.2.4.3: For signing, by default, Windows Server 2008 uses the SHA256 hashing algorithm, but it can be configured to use the MD5 hashing algorithm. The configuration mechanism is outside the scope of the protocol.
For signature verification, Windows Server 2008 uses the algorithm from the messages as specified in "PKCS #7 format" [RFC2315] and is able to verify the signature sent by Windows 2000 Server or Windows Server 2003. Windows 2000 Server and Windows Server 2003 use the MD5 hashing algorithm for signing and are only able to verify the signatures in messages that use the MD5 hashing algorithm for signing, so if the format in "PKCS #7" is set to SHA256, they will fail verification.
<15> Section 3.2.4.5: Domain controllers running Windows use the following strings as the format for the Send-Commentary field: The DRS layer fills the field "%ws" with the Unicode name of the NC replica, and fills the "%I64d" fields with the unsigned 64-bit quantities taken from USN_VECTOR, as specified in [MS-DRSR] 5.210.
"Get changes request for NC %ws from USNs <%I64d/OU, %I64d/PU> with flags 0x%x".
"Get changes reply for NC %ws from USNs <%I64d/OU, %I64d/PU> to USNs <%I64d/OU, %I64d/PU>".
<16> Section 3.2.5: The Windows SMTPSVC component returns DSNs. DSNs that indicate a failure are logged.
<17> Section 3.3.5.1: A DC running Windows logs SMTP DSNs for DRS Protocol Extensions for SMTP Transport messages in the Windows Event Log.
<18> Section 3.3.5.2: As a sender, Windows 2000 Server can set the CompressionVersionCaller field to DRS_COMP_ALG_MSZIP in a V1 frame with a non-compressed payload. As a receiver, if the CP bit of the dwMsgType header field is 0 in a V1 frame, then Windows treats the CompressionVersionCaller field of such frame as if it were set to DRS_COMP_ALG_NONE.
<19> Section 3.3.5.3: For signing, by default, Windows Server 2008 uses the SHA256 hashing algorithm, but it can be configured to use the MD5 hashing algorithm. The configuration mechanism is outside the scope of the protocol.
For signature verification, Windows Server 2008 uses the algorithm from the messages as specified in "PKCS #7 format" [RFC2315] and is able to verify the signature sent by Windows 2000 Server or Windows Server 2003. Windows 2000 Server and Windows Server 2003 use the MD5 hashing algorithm for signing and are only able to verify the signatures in messages that use the MD5 hashing algorithm for signing, so if the format in "PKCS #7" is set to SHA256, they will fail verification.
<20> Section 3.3.5.3: For encryption, by default, Windows Server 2008 uses the AES128 encryption algorithm, but it can be configured to use the RSA RC4 encryption algorithm. The configuration mechanism is outside the scope of the protocol.
For decryption, Windows Server 2008 uses the algorithm from the messages as specified in "PKCS #7 format" [RFC2315] and is able to decrypt messages sent by a Windows 2000 Server or Windows Server 2003. Windows 2000 Server and Windows Server 2003 use the RSA RC4 encryption algorithm and are only able to decrypt messages encrypted using the RSA RC4 encryption algorithm, so if the format in "PKCS #7" is set to AES128 encryption, the messages cannot be decrypted.
<21> Section 3.3.5.3: In the case of a Response, the Windows implementation does not add the sender's certificate to the map.
<22> Section 3.3.5.6: As a sender, Windows 2000 Server can set the dwMsgVersion field of a V1 frame to 0x00000000. Upon reception of a V1 frame with the cbDataOffset field set to 0, Windows uses the RP and RQ bits of the dwMsgType field to determine the message version using the following logic:
If the RP bit in the dwMsgType field is 1, then the payload is a DRS_MSG_GETCHGREPLY_V1 message.
If the RQ bit in the dwMsgType field is 1, then the payload is a DRS_MSG_GETCHGREQ_V4 message.
<23> Section 3.3.5.7: The Windows implementation uses the value of the serverReferenceBl attribute of the Server object in the configuration NC to establish this correspondence.
<24> Section 5.1: The Microsoft implementation validates the fields in the DRS Protocol Extensions for SMTP headers, but these fields are used only until the DRS message is authenticated, decrypted, and unmarshaled. After that, the data in the headers of the DRS Protocol Extensions for SMTP is no longer needed and is ignored.
<25> Section 5.1: All request messages sent by DCs that are running Windows 2000 Server include a Domain Controller Replication certificate; therefore, the response will be encrypted with a 56-bit key. Response data to a DC that is running Windows Server 2003 and later will be encrypted with either a 56-bit or a 128-bit key, depending on whether the DC has been configured with a Domain Controller Email certificate or Domain Controller Replication certificate.