On Mon, 27 Sep 1999, Paul Makepeace wrote:
> I mentioned this before and I think it's even on the wishlist but having the
> ability to create MIME encapsulated bounce messages would be I think very
> useful.
Yes, it is on the Wish List. It is also one of the things that has
people arguing strongly both ways, so it would certainly be optional
(especially as I don't want it :-) .
> And that's not just because our (paying as opposed to email) client
> requires it or that it's on the IETF Standards Track. I'd ultimately like to
> see exim heading towards full Disposition Notification `a la RFC2298
> http://www.ietf.org/rfc/rfc2298.txt itself based on RFC1894 about DSNs ("A
> DSN can be used to notify the sender of a message of any of several
> conditions: failed delivery, delayed delivery, successful delivery, ...")
Aarrgghh. I've published my views on DSN before. They are in the FAQ.
Here's what it says:
I investigated the RFCs which describe the DSN (delivery status
notification) system, and there is even a bit of code in there (excluded
by #ifdef) for handling some of the data. However, I was unable to
specify any sensible way of actually doing anything with the data. There
were comments on the mailing list at the time; many people, including
me, conclude that DSN is in practice unworkable. The killer problem is
with forwarding and aliasing. Do you propagate the DSN data with the
generated addresses? Do you send back a "reached end of the DSN world"
or "expanded" message? Do you do this differently for different kinds of
aliasing/forwarding? For a user who has a .forward file with a single
address in, this might seem easy - just propagate the data. But what if
there are several forwardings? If you propagate the DSN data, the sender
may get back several DSN messages - and should the sender really know
about the detail of the receiver's forwarding arrangements? There isn't
really any way to distinguish between a .forward file that is forwarding
and one that is a mini mailing list. And so on, and so on. There are so
many questions that don't have obvious answers.
My feeling is that a lot of the things people want in this area should
be handled by MUAs, not MTAs. That gives more control to the end user as
well.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
