views:

110

answers:

5

i have to write application for sending newsletter. what is the best way to send newsletter thoundands of users? My requirement is

  1. Each mail is seprately as To :
  2. Every mail has unique Unsubscribe link

Is is good to use SMTP mail class of .net? I look aound may questions in so but can't decide which approcah i should go? There are many suggestions

  1. Multi threaded Windows service
  2. Use Mail Server
  3. Add thread.sleep(2000) between each send.

can anyone suggest good way to imepement this?

+1  A: 

I've written pages that send emails, but not nearly the volume yours will. Nonetheless, I would recommend the following based on code I have implemented in the past:

  • Use the web application to write out the email and all the recipient addresses to database table(s).

  • Have a process that is outside of ASP.NET actually send the emails. This could be a vbs file that is set up as a scheduled task, or (preferably) a windows service. The process would take the text of the email, append the unsubscribe link, and once sent successfully flag the database record as sent. That way, if the send fails, it can try again later (the send process loops over all the records flagged as unsent).

  • If you need a log of what was sent and when, you just need to keep the sent records in the database tables. Otherwise, just delete the records once sent successfully.

IMHO sending emails within the ASP.NET worker process is a bad idea because you don't know how long it will take and if the send fails there's little opportunity to retry before the page times out.

pjabbott
+3  A: 

I would not recommend asp.net webpage to send, even if you do start it in a separate background thread. I would think you run the risk of the server recycling your process in the middle of the send, which would mess it up. You really need to write some kind of separate service or application to send your emails.

The simplest option would be to just create a quick and dirty console or windows form application.

Also logging is critical just like the other poster said. If it fails you want to know exactly what got sent out and where it stopped so that when you restart it you don't mail all the people who it did work for again. You want to be able to input the starting point for the send, so if you need to restart at number email #5000 you can.

The classes in System.Net.Mail namespace will work just fine for sending your mail.

One of the biggest problems will be finding a email host that will let you send so many emails. Most email hosts have throttling and sometime it changes depending upon server conditions so if the server is being heavily used then the email limits will be more restrictive, and you may only get to set 500 emails per hour.

We have a newsletter that goes out to around 20000 people as separate emails and we had to play around with the delay between emails until we found one that would work for our email host. We ended up with 1.2 sec between emails, so that might be a good starting point.

I think there are email hosts specialize in bulk mailings though so if you get one of those it might not be a problem.

Also if you host your own email this may not be a problem. And if you do host your own mail you will have the option of dropping the mail in the pickup directory and you could just dump it all in there as fast as you want, and let the email service pick it up at it's own pace.

EDIT: Here is the settings to add to the config file for setting the pickup directory

<system.net>
    <mailSettings>
        <smtp from="[email protected]" deliveryMethod="SpecifiedPickupDirectory" >
            <specifiedPickupDirectory pickupDirectoryLocation="Z:\Path\To\Pickup"/>
        </smtp>
    </mailSettings>
</system.net>
Chris Mullins
hi cris,thanks for answer.we have our own exchange server.I am wondering how can i drop the mail in pickup directory?
Pragnesh Patel
In the mailsettings element of the config file you can change the delivery method. You can also do it programmatically.http://msdn.microsoft.com/en-us/library/ms164240.aspx
Chris Mullins
Thanks Crisi will give it try
Pragnesh Patel
+1  A: 

Definitely do not do this in ASP.NET. This is one of the biggest mistakes that new web developers make.

This needs to be a windows app or service that can handle this much volume.

Ed B
A: 

Create a webpage to "Design" the newsletter in. When they hit Send, queue the newsletter up somewhere (database) and use another program (windows service, etc) to send the queued letter. This will be many times more effecient and potentially fault tolerant if designed properly.

Michael Rice
A: 

I have written a Newsletter module (as part of a bigger system) in ASPNET MVC 2, Entity Framework and using the System.Net.Mail namespace. It is kicked off in view and actually just runs in a controller with a supporting method to do the send. As each email is sent I track whether there is a hard bouce (an exception is thrown) and I update that database record stating a fail with the exception, otherwise I update the record stating success. We also do personalisation so we have 'tags' that get replaced by an extra field in the database (stored as XML for flexibility). This helps handle an unsubscribe function.

My code is quite simple (please don't flame me for using exception handling as business logic ;) and it works like a charm.

This is all done on a VPS at http://maximumasp.com which also hosts 4 sites with pretty decent traffic. We use their SMTP servers. We notified them that we needed this service and have had no problems relationship-wise.

We had 2GB of RAM on the machine running Windows 2008 and it was doing 6 emails/sec. We bumped it up to 3GB as the web sites needed it and now the mailout is doing about 20emails/sec. Our mailouts range from 2,000 to 100,000 email addresses.

In short, ASP.NET can be used to handle a mailout, and if you add in some logic to handle record updating the worry of losing your way mid-send is mitigated. Yes there are probably slicker ways to do this. We are looking in to MQMS and threading, and separating that out to windows service to make it more stable and scalable as we put more clients and larger lists on, but for now it works just fine with reasonable reporting and error handling.

Ben E G