Autor: Phil Pennock Data: Para: Volker Schmelich CC: exim-users Asunto: Re: [exim] Scheduling / Delaying of messages with Exim possible?
On 2010-08-22 at 03:03 -0500, Volker Schmelich wrote: > I wonder if there are any out-of-the-box configuration options or rules
> available to accomplish scheduling/delaying of messages in Exim. Or if
> there is any script or ready-to-use program on top of Exim which can
> provide this functionality.
>
> My ideal workflow would be:
> 1) External system generates emails with a specific header (e.g.
> X-Scheduled-For: 2010-08-19 08:57:00 GMT) and connects to Exim 10 hours
> before the scheduled date/time.
> 2) Exim parses all received mails for the X-Scheduled-For header. Emails
> with a scheduled date in the future are kept in a queue and are released
> when the specified date/time is reached. Other emails are sent
> immediately.
>
> Is it possible to accomplish this by configuration?
>
> Any ideas how to do this in a resource-friendly way?
You're better off submitting the mails at the right time, with the -odq
flag so that the mails are queued but not delivered, then invoking a
queue-runner to do the deliveries. This way, mails which can go down
the same connection will do so.
If you do this, then you will perhaps want to look at
split_spool_directory and invoking parallel queue-runners, to avoid
having all emails stuck behind one slow host.
Otherwise, you're looking at using "control = freeze" in the DATA ACL,
based on ${if def:h_x_scheduled_for:} and the timestamp in that being
sufficiently in the future and doing something to shove the message-id
and target id into a database; then have a separate script invoked by
cron which looks for all messages in the DB with a time of "now or
before now" and then uses { exim -Mt <message-ids> } and a queue-runner
to allow delivery. The ACL which adds the entries to the database for
items sufficiently in the future should also clean the DB for items
which have been thawed.
This is somewhat abusing the intention of freeze/thaw, but should work.
The only reason that this would reduce load would be if the source of
your load is some scanner you're invoking on new mails; you might want
to consider specifying a custom pseudo-protocol with -oMr for inserting
these mails and skipping the scanning for these known-good mails; I
suspect that this will help somewhat more.
