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 released service packs.

  • Windows 2000 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

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 the Windows Server operating system package. 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 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 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 treat the CompressionVersionCaller field of such frame as if it were set to DRS_COMP_ALG_NONE.

<5> Section 2.2.3: Windows 2000 systems set the cbDataOffset field to 0 in a V1 frame. Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 systems set the cbDataOffset field to 32 in a V1 frame. However, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 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 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 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 use the RP and RQ bits of the dwMsgType field to determine the message version using the following logic.

<7> Section 2.3: A DC running Windows 2000 Server operating system 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 can process messages sent to it that use either type of certificate. When sending requests, a DC running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 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. As specified below, 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 Windows Server will use Domain Controller Replication certificates that contain the following X.509v3 extensions specific to Windows.

For more information about certificate template names and certificate templates, see [MSFT-TEMPLATES].

<9> Section 2.3.2: A computer running Windows Server 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 or Windows Server 2003. Windows 2000 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 or Windows Server 2003. Windows 2000 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.209.

"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 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 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 treat 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 or Windows Server 2003. Windows 2000 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 or Windows Server 2003. Windows 2000 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 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 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 use 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 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 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.

Show: