MailQ: More control over Mail
Hello. I rescently released the guts of a a more complicated module called "MailQ". It's a module that "queues" mail up before sending, however still uses which ever smtp_library (either drupal_mail default or mimemail, etc.) to send the mail.
One can read more about the module here or try out the module at http://drupal.org/project/mailq.
I'm welcome to feed back and patches. :). I for one like that this module gives me more control, information, and feed back about what's going on with the mail-subsystem of Drupal.
Here's a snippet of the current features:
- Set a batch size to run on each cron
- Set a "max try" value so that if a mail fails to send, the mail will be retried.
- Select the "mail library" that you wish to use to send mail, or you can ONLY queue mail, which is good for development. You could e.g. select from mimemail, smtp mail, or the drupal default mailer.
- Mail can be "archived" post sending
Sounds good. Many
Sounds good.
Many mail-sending modules can easily reach enormous lists (10K-15K and more subscribers), in just a medium site, not to mention higher traffic sites.
I think that apart from simplenews, which does its own queuing, none of the other modules queue the mail, something that can cause troubles at shared hosting, or even misconfigured dedicated ones.
Apologies
Hey guys, my apologies as I'm new to the group and hadn't seen you guys had already started talking about something like this here: http://drupal.org/node/28604 . Well, hopefully this gives a reference or something :).
I'll add that Notifications
I'll add that Notifications framework and Subscriptions and OG have some functionality for queueing mail. They do more that that of course. OG uses the useful job_queue module to defer generating and sending of notification mail.
Mime Mail module
The work cited at that URL went into contrib - http://drupal.org/project/mimemail . It may still be on the table to implement a pluggable backend for Drupal core, but for now, this is a good module to latch onto and demo some real-world queuing implementations before committing to just one.
You can play well with this module by implementing a hook_mailengine() ( see mimemail_mailengine() for reference ). We need an actual queuing backend, so this would be super-helpful :)