tags:

views:

262

answers:

4

I've been kicking around this idea for a while and would like to read your thoughts.

I'd like to create a .NET service to send and track email messages.

My rough ideas:

  1. Within various applications, serialize instances of .NET email (System.Net.Mail.MailMessage) objects and put them into a database or file system queue

  2. The mail service/process polls the queue and sends the emails

  3. Enforce subscribe/unsubscribe lists/rules

  4. Track opens, bounces, out-of-office auto-replies, etc.

  5. Report statuses back to the original applications

Does anyone have advice for how I should get started or what issues I may have? Is there off-the-shelf software/service I should look at?

+3  A: 

You will need to learn everything you can about the SMTP protocol, even if you are using higher level tools that do most of the work for you. In my own experience with processing outbound and inbound emails with .NET, I didn't really "get it" until I learned to telnet to port 25 of an SMTP server and send en email by issuing the commands myself.

If you are sending lots of emails out and you need to monitor NDRs (non-deliverable reports), you will have to set the SMTP envelope sender address to your own server and parse all of those emails when they come in to figure out what happened.

The System.Net email classes don't allow you to set the MAIL FROM in the conversation with the MTA without also setting the From address in the email header to the same thing, so you will need to use a 3rd party library like aspNetEmail if you need those addresses to be different.

ListNanny is another tool that is helpful to parse NDRs, among other functions.

I'm not sure about serializing the MailMessage objects. I think it would be simpler to just store the separate data elements themselves and then instantiate MailMessage objects when you need them.

Eric Z Beard
+1  A: 

You may find some of the answers to Handling undelivered emails in webapp useful.

TimB
A: 

Awesome post. I love stuff like this post.

A: 

I suggest you seriously consider outsourcing your email services. I've looked into building a service like this for my webapps as well, but there are many things you will have to keep on top of that will take your time away from your primary webapp (unless of course, you are making this service your primary offering). Third party services take the headache and ongoing maintenance out of the picture.

If you go this route, you will need to regularly monitor your server reputation, maintain whitelist relationships with the big ISPs, monitor and handle bounces, set up correct message throttling per ISP, implement features such as DKIM, VERP, SPF, etc. Assuming this is for opt-in mailings, your primary objective will be to make sure that every message sent will land in a user's mailbox, not their spam box. Be prepared for it to take more time than you realize.

For transactional email (account signup confirmations, account status reports, billing, etc.), take a look at this SO post for providers with webapp friendly APIs.

For marketing email and mass opt-in mailings, take a look at this SO post. I just added MailChimp to that list.

Tauren