> On Mon, 20 Jul 1998, Nigel Metheringham wrote:
>
> > You should be able to support Return-Receipt-To: using a combination of
> > an exim filter and a specialised transport (probably a specially
> > configured autoreply transport).
> >
> > Alternatively, masochists could do the whole lot within a transport
> > filter or shadow transport.
>
> It is trivial to do it with a shadow transport. I did so some time ago as a
> test of shadow transports. Something like this:
>
> ...[example elided]...
>
> However, I don't myself like the idea.
Unfortunately, the result doesn't look like a bounce message; so
it can't be identified with the same filter that is used for the
Sendmail version. Making it look like a bounce message complicates
the configuration; and makes mistakes much more likely. And you'd
need to add the shadow_* options to all of your local delivery
directors. (Not a big deal for most sites; but when you start
throwing virtual domains and selective POP/IMAP delivery into the
mix it's just one more detail to be missed.)
> > I would strongly protest adding any explicit support for a badly thought
> > out and officially depreciated feature in exim - even sendmail doesn't
> > support Return-Receipt-To: now.
>
> Agreed. However, I have been reading the DSN RFCs, and IMHO it is far too
> complex and could also be categorised as "badly thought out".
I haven't read them; but I'm willing to believe your assessment.
I expect they were designed by a committee. (Or by MS-Windows
developers...)
(I'm also willing to argue that Return-Receipt-To: was NOT badly
thought out, given the intended purpose and the environment in which
it was invented. If it were a recent invention, it would certainly
qualify for that assessment.)
-Pat
--
*** Exim information can be found at
http://www.exim.org/ ***
