On Mon, 16 Nov 1998, Nigel Metheringham wrote:
> It will probably come, but Philip was having trouble getting this
> implemented cleanly
I wouldn't hold your breath. Whenever I start to try to think about DSN
I get stuck, because the specification is such a mess. Carrying the data
round with the addresses is easy (and prototype code exists). It is
deciding what to do with it that is hard. 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.
Detail:
1. Send a message when a delivery fails. Easy. Exim does this already.
2. Send a message when a delivery is delayed. Easy. Exim does this
already.
3. Send a message after a "final delivery". Hmm. What is a "final
delivery"? Beginning to get messy here, though maybe each local
transport could have an option specifying "final delivery for DSN
purposes". But, for example, a single transport could run different
kinds of pipe, some of which were "final", and some of which were not.
4. 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 maybe that address is in some sense secret and
shouldn't be sent back? And so on, and so on. There are so many
questions that don't have obvious answers.
Coupled with the fact that I have a personal dislike of automatic
responses, these problems have caused me to go away and concentrate on
other things, of which there is no shortage.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
