Hi Philip,
I consider DSN to be one of the most difficult feature extensions,
as well. And though I asked for features like SIZE and EHLO-
commands, I don't think it is really urgently required to support
DSN. However, I'd like to add my thoughts about this matter.
> Detail:
>
> 1. Send a message when a delivery fails. Easy. Exim does this already.
Right. But the advantage of DSN is the definition *how* this
response should look like. Once many mailers support this standart,
mail clients can interpret these repsonse, while the current
messages are "automatically generated by...", but intend for
a human reader.
> 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.
A transport should have a DSN-option like:
- Final This transport is the final delivery
(Example: append_file, pipe delivering e.g. to IMAP)
- Relay If this transport suceeds, a relay message
will be generated.
(Example: PIPEs for UUCP, other user-specific deliveries)
- Preserve This transport tries to pass the DSN-properties of
the mail
(Example: SMTP)
The user might either split up the pipes into different transports
with different DSN-options, or use the more general "Relay"-option.
This should nether be a violation of RFC1891.
>
> 4. The killer problem is with forwarding and aliasing. Do you propagate
> the DSN data with the generated addresses?
( I delete the parts from 1891 here):
6.2.7.2 single-recipient aliases
...
6.2.7.3 multiple-recipient aliases
...
So what whold be a strategy?
If an alias / forwarding is used:
- If just one E-Mail-address is returned, this would be something
like "Preserve DSN". If one E-Mail-Adress and e.g. something
like vacation or the major-domo-wrapper is returned: the same.
The DSN-data is propagated.
- If no or multiple E-Mail-adresses are returned, a
"Relayed"-DSN is issued. The DSN-data is not propagated
or
- If no E-Mail-adresses are returned (e.g. a wrapper like
majordomo), a "Delivered"-DSN is issued.
- If multiple E-Mail-adresses are returned, a
"Expanded"-DSN is issued. The DSN-data is propagated, without
the SUCESS-keyword.
> Do you send back a "reached end of the DSN world" or "expanded" message?
This is up to you. Both seems to be legal.
> 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?
Hmmh. If you wish to support the "secret of forwarding adress", things
get difficult already by now. If a delivery with Non-DSN SMTP will
get wrong, the sender will be informed by the mailer-daemon what
went wrong ("Your message to "phil.hazel@???"
was delayed"). The secret is only a secret as long nothing gets wrong -
not a very strong protection. Therefore I suppose this is neglectible.
> 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.
As stated above, I don't think DSN to be really important.
Greetings,
Georg
--
*** Exim information can be found at
http://www.exim.org/ ***
