Philip et al,
Has there been any discussion/thought about adding per-message retry
semantics as an option to use instead of per-host retry semantics? Let me
explain...
We're providing Backup MX services, including for customers who sometimes
have their servers offline for quite some time. We want to hold onto
messages for 10 days after they're received, no matter how long the
host has been offline for. That is, if a host has been offline for 12
days, only messages received on days 1 and 2 would have been bounced at
this point, and new messages would be accepted and re-tried for up to 10
days (22 days total outage).
With Exim as it stands now, I can't see any way to achieve this behavior,
but it is pretty much the standard behavior elsewhere (at least, with
Sendmail, I'm not 100% sure about other MTAs) and it seems to be what our
customers are expecting. It's also what "makes sense" the most to me.
My thinking is that this would be easiest to apply ONLY to the final
cutoff, and that would fit fine with my expectation of how it would work.
That is, if I have a retry rule of:
F,24h,15m; F,5d,1h; F,10d,2h
I would expect a message that comes in on day 12 of the host being down to
be retried every 2 hours until day 22 of the host being down. It wouldn't
get the 15 minute or 1 hour retries. That way, no extra data has to be
stored with the host's retry hints, the final cutoff code just has to look
at the time the message entered the queue, rather than the time the host
went down, when deciding when to bounce it.
Is this something that others would find useful, and that we might be able
to see added to Exim at some point?
Thanks,
Tim Wilde
--
Tim Wilde
twilde@???
Systems Administrator
Dynamic Network Services, Inc.
http://www.dyndns.org/
