ietf-822
[Top] [All Lists]

Re: Halloween/Message receipts

1998-11-20 02:39:00
In article 
<3657CB4E(_dot_)F2D8207D(_at_)to(_dot_)sel(_dot_)fujitsu(_dot_)co(_dot_)jp>, 
Antony Bowesman
<adb(_at_)to(_dot_)sel(_dot_)fujitsu(_dot_)co(_dot_)jp> writes
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.


Agreed, when we implemented MDNs for our MUA we immediately came across
this problem.  Also Outlook fails to observe the rule than an MDN should
not be sent automatically if the DSN address differs from the Return-
Path, this causes problems of multiple MDN flooding if a DSN is sent to
a mailing list.

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.

This was the solution we chose as being the most customer friendly.

* 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>

:)



When we came across this problem we raised it in some Microsoft
newsgroups and got a positive response from an MVP and believe that the
problem is being addressed.

Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

<Prev in Thread] Current Thread [Next in Thread>