2

I'm in the process of upgrading an old document management system. Part of the existing functionality sends emails to some or all users when certain events happen to documents on the system.

Currently, the code generates an inordinate number of emails in response to these events which it then despatches using PHP's mail() function while the user sits and waits...

...and sometimes waits, and waits and... you get the picture.

I'm looking for some sort of library that will:

  • queue these emails quickly somehow
  • despatches them over time using some sort of background script driven by cron or another scheduler.
  • is able to throttle outbound mail and 'jump the queue' for urgent mail.
  • MySQL storage would be good, other non-database solutions might work
  • It would be great if it has some sort of delivery failure processing, but this is not essential.
  • Free would be very nice

I've used PHPMailer - no background processing - and SwiftMail - same problem AFAIK.

|improve this question|||||
  • What's the underlying OS on that machine (though Cron is pointing to a *nix system, better let's be sure ;)? Is there a SMTP server running on it? If so, which? If not, would installing one be an option? Please edit your post to include those details. Thanks! – Izzy♦ Nov 25 '14 at 11:58
  • @Izzy This is to work with a PHP system (see title & tag), so the target OS will probably be *nix, but could also be Windows. Since this presently can run on a shared hosting system, installing additional software may not be an option, but an SMTP server could be available elsewhere. – user8986 Nov 25 '14 at 13:54
  • To give you some background of what I had in mind: instead of using PHP's mail() function, you could place the "ready-to-deliver" .msg files directly into the spool directory, and have the management done by the MTA. Some of them support this, I've once done things this way. But OK, I see this might not be an option here. – Izzy♦ Nov 25 '14 at 14:37
  • 1
    @Izzy Thanks for the comment. I hadn't considered dropping a 'ready to deliver' message somewhere, but it's not really an option. To give you an idea - I have a couple of these systems with 100+ users. The system can generate an notification email whenever a new document is added. Adding a batch of, say, 10 documents could potentially generate 1000+ emails (1 email per document per user). I need to be able to spread sending these over a few hours to avoid spamming limits at the ISPs. I'm looking at implementing digests and other mail reduction strategies, but the underlying problem remains. – user8986 Nov 25 '14 at 14:59
  • A little off-topic here, but have you considered grouping those mails, to only generate "one mail per (changed) document" to all "interested parties" – using the BCC list for the "real recipients" (and a dummy "TO" to meet the rules)? – Izzy♦ Nov 25 '14 at 16:09
1

I didn't seem to get much traction with this so I've had to knuckle down and create my own which you can find on GitHub.

It's early days and this requirement was holding up another project, so it's a bit rudimentary. I'll tidy it up when I get a few hours.

|improve this answer|||||
  • "when I get a few hours" == "never"? Lolx. No offense. I look forward to seeing the completed - AND DOCUMENTED - system (+1). – Mawg says reinstate Monica May 10 '16 at 7:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy