On Wed, 15 Jun 2005, Tim Wilde wrote:
> Has there been any discussion/thought about adding per-message retry semantics
> as an option to use instead of per-host retry semantics?
Not that I can recall.
> 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).
Exim was not designed for situations where hosts are offline. I designed
it for our environment, where most (more than 95%) of messages can
always be delivered immediately. That is why there are no elaborate
queuing mechanisms inside Exim. It isn't worth it when only a small
percentage of your messages need to be queued.
As a consequence of this, Exim does not perform well when its queue is
large. Even split_spool_directory only helps a bit. If you are in a
situation where you need to hold onto messages for long periods, it is
much better to get them off Exim's queue and keep them somewhere else.
There are certainly sites that do this. If their client's host is
offline, they deliver the messages in BSMTP format into local files,
either one file per host, or one file per host per day, or whatever.
This gets the messages off Exim's queue. It also means you can apply
rules such as deleting messages more than n days old, or allowing only
so much storage space per host, etc. A whole lot of management options
open up.
When the host comes online, the messages are passed back to Exim for
immediate delivery. The prod to do this can be via ETRN or otherwise.
The whole thing can be made reasonably automatic with some effort.
> 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.
In your environment, no doubt, yes. In the "always online" environment,
I beg to differ.
> 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.
As you no doubt realize, Exim doesn't work like that. Once the host has
been down for 10 days Exim will bounce everything almost immediately. I
argue that in an environment where you expect the host always to be up,
this is more useful behaviour because the sender gets the bounce more
quickly. ("It should be up; it's been down for 10 days; what is the
point of going on trying?")
> Is this something that others would find useful, and that we might be able to
> see added to Exim at some point?
What do other people think?
--
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
