On Fri, 6 Dec 1996, Ian Jackson wrote:
> I have to agree very strongly with Piete on this one. A default that
> simply blackholes mail for certain error conditions is awful !
On Fri, 6 Dec 1996, Piete Brooks wrote:
> As iwj10 agrees (!) it is not a plausible default *IFF* you want people to use
> exim.
Well, at least I seem to have managed to do something that has Ian and
Piete in agreeement... :-)
Ever-receptive to the needs of my users, I'm prepared to change the
default setting of ignore_status if that's what most people want. Would
a few more people on the list care to cast a vote?
I've already said I'll think about an option to cause non-zero status to
alert postmaster.
On Fri, 6 Dec 1996, Ian Jackson wrote:
> In Smail there is often a `real-<user>' arrangement, whereby mailing
> real-<whoever> will deliver mail locally regardless.
You can do this in Exim too, but you have to configure it in. Exim
cannot assume that such a configuration will exist.
> If you arrange that when mail goes through a .forward file any errors
> are sent to the real-<whoever> rather than to the user in question
> then the mail will not be lost, but will instead pile up somewhere
> where the user will hopefully notice it.
The forwardfile director already has an "errors_to" option for
specifying where delivery errors are to be sent to. Setting this,
together with no_ignore_status would achieve exactly this.
> An option to make this happen would obviate the perceived need to
> ignore the exit status of pipes. It would be good for the option to
> specify indepdendently whether or not errors resulting from .forward
> files should be sent to (a) the original sender of the message (return
> path), (b) the local postmaster and (c) the `real user'.
You can do this already by one of
errors_to = (not set) => original sender (return-path, strictly)
errors_to = postmaster => local postmaster
errors_to = real-$local_part => "real user"
provided you unset ignore_status on the pipe. The third will work only
if a director for handling real-user is set up, of course.
> Perhaps the most general solution would be to have an option on the
> appropriate director (or a general option) to allow one to set the
> return path of a message as it goes through the director, and having
> expansion variables for the original sender and the real user in this
> context. (I haven't delved into the manual deeply enough to know
> whether this option or these expansion variables already exist.)
Yup, exists.
On Fri, 6 Dec 1996, Piete Brooks wrote:
On 7 Dec 1996, Brian Blackmore wrote:
> Maybe a better more generic solution would be an option on the appropriate
> director (or router) such that if its transport fails it would act as if
> the director had never matched in the first place.
Given the way Exim is written, that would be very hard to do, since it
does all the directing and routing, and *then* starts on the deliveries.
So passing something back to the directors in the middle of transporting
cuts across the normal flow of control. Nevertheless, it is an
interesting idea which I've noted down for further thought.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
