0

Here is what I perceive is our problem.

In our corporate environment, we have developed over 40 custom .Net applications (and growing). A good many of these send email notifications in some fashion. A few of these send "real time" notifications -- the user takes some action on the front end, which triggers an email sent. But most of the applications queue these notifications in a database table. A separate console app will then process these emails periodically. Note that each application has its own little console app which processes these emails. So we probably have a good 25+ little separate console apps that run all day, hitting tables in their respective application databases, using the .Net libraries to send mail.

This isn't the most horrible of things in and of itself but some applications send a TON of email -- to the tune of 100k+ per day. And if something goes wonky, we have to look at some console app to see what's the problem.

So the problem is two-fold: a) volume, and b) maintenance.

What I envision is, rather than some user action storing a mail record in the application database to be processed later by its own console app, that this action would queue it up in a central location (either send some web service request or MQ, whatever) for some central, dedicated application to process.

Basically, I think I want some optimized, centralized, enterprise email sending service where I can just hand it jillions of emails from any app. Not a email marketing software per se (although this may fall into that category) because that is more like defining templates, logging into a UI and emailing people on a list. Rather, I want to queue up mail dynamically for this thing to send. (As a bonus, other groups in our org could use this.)

I'd prefer some OTS, supported product, and not have to write it myself.

Anybody have any experience with something like this?

Thanks! Tom

ironfist
  • 101
  • 1
    Why not ... just send the email from in app like just about everyone else does and let the MTA of your choice handle the sending and queuing? – Zypher Apr 29 '16 at 20:12
  • Thanks @Zypher -- but I'm not following? If I send it immediately in-app via SMTP, there's no sending or queuing for me to worry about. Which goes back to my OP: whatever I do in-app (send via SMTP, which would just go through our Exchange server now, or queue the message somewhere to be processed later), I want *something else* to be responsible for processing the queue and sending. It's the *something else* I'm looking for guidance in. – ironfist May 02 '16 at 13:25
  • Why do you need to add a layer in front of the MTA to process the queue? Literally an MTA's job is to manage the delivery life cycle of a message. What do you think you'll gain by putting a program between the app and the MTA? – Zypher May 02 '16 at 13:34
  • Maybe I'm not understanding your question. There's 3 parts to this. 1) The app. 2) The queue (where the messages are stored). 3) The queue processor. Right now, #2 is the individual app database and #3 is a batch job specific for the app. So if I have 40 apps that need to send messages, I have 40 #2's and 40 #3's. I don't want that. I want *one* #2 and *one* #3. I want all my #1's to send to a centralized place that is optimized for this queuing and sending. This post is about identifying what #2 and #3 are -- what options are available "out there in the world." – ironfist May 16 '16 at 17:43
  • #2 and #3 can be fulfilled by and MTA. Send your mail, and let the MTA handle it. From the information in your question there is NO NEED to write to a DB, then read back from that DB just to send mail. Just. Send. The. Mail. – Zypher May 16 '16 at 17:53

0 Answers0