Re: [EXIM] ETRN, -R and one_time...

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Dean Brooks
CC: exim-users
Subject: Re: [EXIM] ETRN, -R and one_time...
On Mon, 18 Jan 1999, Dean Brooks wrote:

> Well, everything except one thing. If email has been deferred to a
> member on a local mailing list (implemented through forwardfiles), and
> one of our ETRN clients is on this mailing list, the -R wont "flush"
> the mailing list message for that client.


No, because it matches the original recipient.

> >From reading the docs, it appears that the "one_time" option will cure
> this, as it will store the processed receipient in the retry files
> instead of the top-level address.


Should do.

> However, if I set one_time on our forwardfile director, it kills all
> piping and file storage.


The solution to that is perhaps to have two forwardfile directors. One
for the mailing lists, and one for other forwarding that might produces
pipe or files - or do your mailing lists contain pipes/files?

> Further, if we have customers with
> legitimate ".forward" files in their home directory that redirect to
> one of our ETRN clients, the -R still wont work without "one_time".
> Turning on one_time, though, will kill piping and file storage again.


True. That rather kills it.

> Is there anyway to have the benefits of one_time without the downside
> of eliminating piping?
>
> Or, is there a better way to do this?


I am coming more and more to the general conclusion that one shouldn't
try to mix general queues of mail that is waiting because of network
delays, down hosts, etc, with queues of mail for specific hosts that are
waiting for them to dial in and issue -R. For one thing, the -R-waiting
stuff can totally swamp the general queue, making it hard to spot
delivery problems that need attention. Furthermore, Exim keeps having to
wade through it (even if just skipping over it).

So, you don't want to be queueing mail for -R clients on the same Exim
that is doing the expansion, mailing lists, etc.

There are various ways you could split things. You could send off the -R
stuff to some other host. You could send it to a different incarnation
of Exim on the same host, via some private port other than 25 (of
course, the ETRN would be received on the main Exim, but you could
configure that to call any script you like and thereby kick the
subsidiary Exim). You could do what some ISPs do and deliver -R mail
into individual files in BSMTP format in some per-host directory, and
use an entirely different program to push them out when ETRN is
received. I expect there are other alternatives too...

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.



--
*** Exim information can be found at http://www.exim.org/ ***