If anybody is slightly interested, I have a patch for Exim that handles DSN
support for remote deliveries. It can even support unseen routers by
allowing you to state which router the DSN should go down. (We have patched
up to 4.24 - 4.41 with it, and I'm just working on the 4.51 version of the
patch)
It lacks 2 things :-
It doesn't produce a DSN if you didn't give it any routers to go down, and
it doesn’t produce a DSN if it's a local delivery (For the complexities that
Phillip states - though it is something I will be adding).
There is a sourceforge project for it though I have not put any code (or
anything else for that matter) up there yet.
The patch is on our system that handles ~250k emails per day (where a
reasonable proportion actually use it) so we consider it to be well tested.
-Andy-
> -----Original Message-----
> From: Philip Hazel [mailto:ph10@cus.cam.ac.uk]
> Sent: Monday, July 04, 2005 3:17 PM
> To: pimplebutt
> Cc: exim-users@???
> Subject: Re: [exim] RFC3461
>
> On Mon, 4 Jul 2005, pimplebutt wrote:
>
> > On 7/4/05, Tony Finch <dot@???> wrote:
> > > On Mon, 4 Jul 2005, pimplebutt wrote:
> > > > Does Exim implement support for RFC3461?
> > > It does not.
> >
> > That's unfortunate. :-\ Would like to wishlist this if no-one has
> > wishlisted it already.
>
> It's been on the Wish List (as a reference to RFC 1891) for
> seven years.
> Nobody has had enough enthusiasm to tackle it. I myself have
> never been at all keen.
>
> I haven't read 3461, so things may be different, but this is
> what is in the Wish List:
>
> --------------------------------------------------------------
> ----------------
>
> (11) 17-Jul-98 G support for DSN
>
> It is unclear to me how this should work in the presence of
> aliases and forwarding. Local deliveries would have to
> explicitly configured as deliveries or relaying or whatever.
> A substantial amount of code is probably needed.
>
> An Exim user commented:
> I have nothing to add except to say that for many of the
> reasons you've stated, I don't think that DSN is coherent
> enough to be worth the effort to implement.
>
> Another comment:
>
> I thought the RFC was pretty clear on this. In a nutshell, if the
> delivery rewrites the envelope from address, it's considered a
> terminal delivery (i.e. delivery to a mailing list
> exploder), otherwise
> treat it as a forwarding operation (the /etc/aliases case). I would
> treat a .forward expansion as a final delivery event (it got to the
> user as far as the MTA is concerned).
>
> Yes, we need the DSN syntax. We also require the complete
> semantics of
> NOTIFY=SUCCESS,FAILURE for our application to work.
>
> Electronic Bill Presentment is really going to push the need for
> DSN support in MTAs. We just don't want to get stuck in a situation
> where we're faced with a non-DSN-aware MTA when we go to install
> our bill/statement engine, thus our interest in what the MTA vendors
> are planning to do about DSN.
> --------------------------------------------------------------
> ----------------
>
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
> Get the Exim 4 book: http://www.uit.co.uk/exim-book
>
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.9/42 - Release Date: 06/07/2005
