jeffs wrote:
Sahil Tandon wrote:
On Wed, 18 Feb 2009, jeffs wrote:
Thank you for your prompt reply.
No problem, but please do not top-post; place all future replies *below*
quoted text. Thanks.
I am working on a project in which -- depending on the level of the
users subscription -- either their mail is delayed for at least 2 hours
or it is sent out immediately. Actually, I could use some advice on the
best way to implement this. Because of the application in use all email
whether or not it belongs to one group or another, originates from the
same domain. It is an application sitting on the smtp server which
processes mail for the application. The users fill in a form and
depending on their level of subscription, the values from the form are
converted into an email message, go out right away or are delayed. So,
as far as the smtp server is concerned , all mail originates from the
same user but in fact gets destined for different recipients. The
application can ad tags or codes to the individual messages to indicate
which group they are in so perhaps if postfix can look inside the
message or something and see the tag or code, it can then decide if it
should delay or deliver immediately the message.
I hope I'm making myself clear and please ask if you need clarification.
Why not configure your application to inspect the mail and, depending on
your criteria, submit to Postfix immediately or after a two hour delay?
You raise an interesting twist. The mail is sent out via php -- I
really don't know how to make it delay the submitting of the mail to
postfix unless you might have some ideas on that one. I'm very good
with cron jobs and I was thinking if I could only get one group of
messages into a queue or delayed queue then I could fire off the cron
job every few hours, but I'm at a loss as to what queue and how to get
it into that without postfix gobbling it up and sending it out right away.
I won't make any claims as to the correctness or efficiency of this
approach, but one way that I've seen this done is to store a record in
the database immediately, and then have a (cron) PHP script running
every 5 minutes or so to process any "ripe" messages.
The script would execute the following pseudo-SQL, "SELECT * FROM
pending_messages WHERE subscription_level=cheap_bastard AND (now -
time_submitted) >= 2 hours". You would then loop through the results,
sending them off to mail() or whatever one at a time.
The benefit of using PHP, I suppose, is that you can use your existing
application code to do most of that work. It's also slightly more robust
in that you don't need to control the outgoing mail server for the
application to function properly.
I did look at defer_transports and that looks promising. Would I simple
put defer_transports = smtp in the main.cf or do I have to fiddle with
other settings someplace too? I'd prefer something a little more
elegant than defer_transports unless I can, again, specify somehow which
mails are to be delayed.
Thanks again.
