Outlook operates in two different modes - Corporate or Internet. I can't
speak for the Internet support, I don't work on that team, but I CAN talk
about the corporate mode.
In the corporate mode, Outlook uses Exchange server to provide it's internet
native content, which is done internally in the message store, so Exchange
is responsible for creating read receipts, etc. Currently there is no
support in Exchange for MDNs, so it can't be faulted for not producing valid
MDNs. Please don't think this is a case of perverting the standard either.
The exchange support for read receipts predates MDN's by several years - we
cannot follow standards that do not exist. Instead, we implemented read
receipts/non read receipts in our TNEF encapsulation layer (also known as
application/ms-tnef). Exchange WILL correctly support MDNs in a future
release, it's just not in the current product.
It is certainly the case that TNEF isn't standard (although it IS
documented), but again, there was no standard (or proposed standard) for
transmitting rich text and embedded graphics in a message at the time it was
first deployed (1995).
Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 98 and
Exchange Server 5.5. Please notify the sender of any difficulties
-----Original Message-----
From: Antony Bowesman
[mailto:adb(_at_)to(_dot_)sel(_dot_)fujitsu(_dot_)co(_dot_)jp]
Sent: Sunday, November 22, 1998 12:29 AM
To: IETF-822; MIME
Subject: Halloween/Message receipts
Something that comes close to the accusations made about the recent
Halloween report is the Outlook 98 support for
Message-Disposition-Notification to MIME header.
It seems that a proprietary format message is returned
(application/ms-tnef) with along with well known 'winmail.dat' which of
course not many people can read and plenty has been written about on the
web. Does anyone know if Outlook can configured to produce
multipart/report MDNs?
Of all the possible implementations of MDN available it does seem that
the most 'hard-for-other' was chosen.
Now there is a choice for gateways/non ms mailers.
* Write something to understand ms-tnef winmail.dat and
decode/understand whatever the content happens to be.
* Discard all application/ms-tnef bodies with appripriately
labelled subjects
* Explain to the support organisation how to answer support
calls saying they can't read their mail item.
None of the above are particularly satisfactory. MS have plenty of X-
headers to indicate the originating mailer is an MS product so it's
surprising, to say the least, that they return tnef receipts in the
obvious knowledge that they will be meaningless to the receiver.
I suppose there is a fourth option.
MAIL FROM: <>
RCPT TO: <support(_at_)microsoft(_dot_)com>
:)
Rgds
--
Antony Bowesman
adb(_at_)to(_dot_)sel(_dot_)fujitsu(_dot_)co(_dot_)jp