On Wed, Feb 18, 2009 at 09:44:25PM -0900, Melvyn Sopacua wrote:
> On Wednesday 18 February 2009 17:50:14 Noel Jones wrote:
>
> > A policy server won't really help here.
> > OP should read up on the "at" command.
>
> Yes it will. At/cron still means the php app needs to queue, then it gets
> passed to the postfix queue. Extra overhead, copied content, multiple points
> of failure in the queueing, having to write logging and debugging for the
> queue (logging and debugging is already available in postfix queues). A
> policy server is made for: implementing policies that fall outside of the
> realm of the mailserver.
> Delaying mail is one of those policies, as the nature of a mailserver is to
> deliver mail as fast as possible.
>
> --
> Melvyn Sopacua
I suppose I'll have to spell it out...
First, a policy server has no "DELAY" action, there are only
DEFER and OK (and several others, but not relevant here).
The delay you observe is the end result of a DEFER and the sender
retrying at a later time. To support DEFER, code would need to be
added in the application to recognize the deferral and retry later.
Secondly, most likely php is calling the sendmail(1) command to
submit mail - such mail is not subject to smtpd_*_restrictions
nor policy services.
While there are ways around the above problems, it just
makes the system increasingly and unnecessarily complex.
So a polcy server won't solve the OP's (Original Poster's) problem.
The at command can be used in the originating program to delay
submission of the mail until the desired time. This delay happens
outside the application, under the control of the cron system.
This is, in fact, a queue controlled by the OS. No special
programming considerations need be made other than calling the proper
command based on what the program already knows.
{mail to be submitted now}:
regular mail command
{mail to be delayed}:
at now + 2 hours << EOF
regular mail command
EOF
or something remarkably similar. This allows php to run the command
right away, no queuing or scanning in the application. Cron/at
takes care of submitting the mail to postfix after the specified
delay. If there is a failure, cron/at or postfix (depending on
what fails) will send an error report.
I've probably spent more time explaining this than it will take
to implement.
-- Noel Jones
