Have you looked at https://github.com/nullterminated/ponder/tree/master/ERCoreBL
and https://github.com/nullterminated/ponder/tree/master/AWSPlugin ? We send more than 10,000 emails per day with that, mostly in one big lump. We queue up messages that aren’t time critical and the mail daemon sends a batch every five minutes. Things like password resets are sent straight through without waiting for the queue. The full email is captured in the database and can be resent or reviewed later if necessary. With the amazon plugin, it automatically handles bounce and complaint notifications, flagging the recipient’s address so later attempts to send to the same address are suppressed. The mail daemon is threaded and throttled so you can send X mails per second through amazon and know you aren’t exceeding your send quota. Amazon lets you set up SPF and DKIM rather easily and handles RBLs so you don’t have to. On Jan 29, 2014, at 8:15 AM, Musall Maik <[email protected]> wrote: > > Am 29.01.2014 um 16:08 schrieb Þór Sigurðsson <[email protected]>: > >> Don't queue the email - that's something the mail server itself is >> proficient at, not the WO framework (or any framework on top of that). > > I’m not talking about re-inventing SMTP servers. But we had a case where the > spooling filesystem of the SMTP server ran full, so it failed to accept any > new email, and data got lost. I only want to ensure that nothing is silently > lost while the app thinks the mail is safely on it’s way out. > >> Instead, log the request - an email was requested. Send the email, and once >> the email has been sent, mark the request as handled. >> That way, if your Wapp happens to turn its toes towards the sky, it still >> has the current state at restart. >> And keep the log small. Very small. It should be fast end efficient (e.g. >> USERID:REQUEST_TYPE:DATE:(BOOL)HANDLED ) > > Where would the restarting app get the lost email content and metadata from? > > Maik > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
