DOCUMENT:Q272699  21-DEC-2000  [exchange]
TITLE   :XCON: Consequences of Non-Standard Class Message on X.400 Msgs.
PRODUCT :Microsoft Exchange
PROD/VER::5.5
OPER/SYS:
KEYWORDS:exc55

======================================================================
-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Exchange Server, version 5.5 
-------------------------------------------------------------------------------

SUMMARY
=======

This article describes the consequences of when you customize the Message Class
with a script. The Exchange Server computer receives X.400 messages that request
a read receipt from a foreign X.400 message transfer agent (MTA). These messages
are sent to a mailbox where a script (run by the Exchange Server Event Scripting
service) changes the incoming message class from IPM.NOTE to IPM.NOTE.XXXX.

When the recipient reads the incoming message, the read receipt that is generated
is not an X.400 IPN as expected but an X.400 IPM. The user that sends an e-mail
message with a read receipt from this foreign MTA then receives a normal message
and not a standard read receipt.

MORE INFORMATION
================

Avoid altering the message class, PR_MESSAGE_CLASS MAPI property; it is a very
sensitive property.

MSDN provides instructions for changing the message class (and other properties),
but all consequences must be checked because it means the usual behavior is
modified internally. For example:

 - If the original message is sent locally, there is no problem when reading it
   with the message class modified, as the originator receives a MAPI message.
   All tasks are performed in the information store, so there is no X.400
   translation done with the MTA.

 - If the original message is sent from another Exchange Server computer through
   an X.400 connector, reading it with the message class modified generates an
   IPM message instead of an IPN message. This IPM has the information "Read" in
   the Subject field and "REPORT.IPM.NOTE.XXXX.IPNRN" in the body part.
   Translation from MDBEF to X.400 in the XAPI part of the MTA causes this
   result.

 - If the original message is sent from a foreign X.400 MTA, reading it with the
   message class modified generates an IPM instead of an IPN.
   This IPM has the information "Read" in the Subject field but no body part,
   which is unusual but X.400-compliant (zero-length SEQUENCE OF--that is, no
   body--is strictly legal).
   Translation from MDBEF to X.400 in XAPI part of the MTA causes this result.

 - Many other cases occur with Reply, Forward and other actions on the modified
   message. If the recipient reads the message before the script changes the
   PR_MESSAGE_CLASS, we have a correct X.400 read receipt, and so on.


Additional query words:

======================================================================
Keywords          : exc55 
Technology        : kbExchangeSearch kbExchange550 kbZNotKeyword2
Version           : :5.5
Issue type        : kbinfo

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 2000.