Re: [exim-dev] Per-Message Retry Semantics?

Pàgina inicial
Delete this message
Reply to this message
Autor: Marc Sherman
Data:  
A: Tim Wilde
CC: exim-dev
Assumpte: Re: [exim-dev] Per-Message Retry Semantics?
Tim Wilde wrote:
>
> 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.


This is certainly a big hack, but here's a suggestion that might work to
fake the behaviour you're looking for. With a retry limit of 10d, run a
nightly cron job that executes:

exim_tidydb -t 9d /var/spool/exim retry
exipick -i 'message_age >= 10d' > xargs exim -Mrm

The first command gets rid of any retry info older than 9d, so exim will
effectively keep retrying infinitely (though at the slowed down 9d rate,
not the initial rate), and the second command deletes any message that's
been on the queue for 10d or longer.

Note that's completely untested, YMMV.

- Marc