Spludlow Web Header

Sending Email


Using the Spludlow Framework to Send Mail 1

Configuring Defaults. 1

Using the Generic Email page. 1

Getting Data to the Render Page. 1

Bulk Email 1

Getting Blacklisted. 1

Dealing with getting blacklisted. 1


Using the Spludlow Framework to Send Mail

Configuring Defaults

The Framework mail methods provide many overloads so you can specify where messages are rendered and to and from email addresses. Some methods omit these in which case the defaults are in configuration.

If you look on the Intranet Configuration page you will find the following:

Organization Level

·         MailHostAddress – This is the default host that email messages are rendered on, the format can be just the host name, in which case the Run queue will be used or you can specify it in the format “HOST:QUEUE” if you want to use a dedicated queue.

·         MailToAddress – Default address to send a message too, only really used in testing normally just set to your own email address.

·         MailFromAddress – Default from address used if not specified, this address is up to you, maybe you want dontreplay@mycompany.com or you prefer to let your customers reply back to with something like info@mycompany.com.

Network Level

·         SmtpServer – The SMTP server available to the network for sending mail, to send mail there must at least be a SMTP server available on one on the networks

Using the Generic Email page

Before you start creating your own email body ASP.NET pages you can use the generic built in page to check everything’s working. You can also use it during development just to show how it will work as you go along.

Getting Data to the Render Page

Your render pages, for example an order confirmation, needs to get its data form somewhere. There are 3 ways to achieve this:

·         Pass an ID – When firing the order confirmation pass the order number in the query string for example “OrderConfirm.aspx?OrderId=12345”. The page picks up this order number and performs the necessary database queries its self to obtain the data.

·         Post the data – When firing a mail one of the parameters allows you to pass an object[] that you can put what you like in, this will be posted (HTTP POST) to the page. From the page you can pick up the data using the GetPostedData() method to retrieve the object array.

·         Pass in the Query String – If the page requires little data you can pass it in Query Strings making sure you UrlEncode them. Web servers will have some limit on maximum request url length, you have to remain within this limit.

These techniques should make getting data to you render page pretty simple, each one suits certain business logic scenarios. You can also mix them.

Bulk Email

Sending out your own bulk marketing emails from your own server is not difficult provided you play by the rules to avoid getting blacklisted, further details in the next section.

Make sure you include an unsubscribe link, that works. The best way to do this is store in your database a key, a GUID is a good option, against each email address. Provide a link to a web page containing this key in the query string, the page can look up the email address display it with a button to confirm un-subscription, then store the current date against the email address so you know not to send it again.

Make sure you can pick up where you left off it a problem occurs half way through sending the bulk mail. If you’ve got some code that just goes through a list from start to finish each time and it’s fallen over 3 times before sending the lot on the 4th attempt then the people at the start will have had it 4 times and are likely to be annoyed.

Include a test function in your bulk mail code that runs exactly the same code in a test send as the real send. Enter a test customer record in your live database that you can run it against just on that record before doing all records. Double check the received email and get someone else, with a non-technical mind, to read through it also. Sending out an email that starts “Dear @CustomerName” to 10,000 addresses will leave you looking a bit of a dummy.

Don’t include attachments or embedded images in your messages, link to somewhere on the web and make sure it stays there for a while. This is from a bandwidth perspective, say you are attaching 1Mb PDF and sending out to 10,000 email addresses, you do the maths, it will leave a 2Mbit connection pretty chocked for a few days, I can tell you.

To avoid your main mail server getting blacklisted, the one that your user mailboxes are on, then consider setting up a separate SMTP server on a separate IP address for sending bulk mail, that’s if you have multiple IP addresses at your disposal.

The Frameworks low level mail sending methods wrap the send in a re-try on certain SMTP Exceptions. I have seen SMTP servers sometimes get overwhelmed and refuse a message, trying again a few seconds later often does the trick, some internal queue in the server gets too full.

Getting Blacklisted

When you are sending email from your own SMTP server you run the risk of getting blacklisted. You get blacklisted when other mail servers believe you are spamming and submit you IP address to a SPAM database. This happens when you are sending out an excessive amount of emails to non-existent mail recipients. What is actually detected is too many non-existent local parts to the email address. If you send out an email to fred@longgonebusineess.com the only email server that will detect a problem is your own, it won’t even leave your network, but if you send to nolongervaliduser@yahoo.com the mail will arrive at the yahoo mail server it will then detect the user is no longer registered, if you do this a lot then you will get blacklisted.

 An organization may have no intention of this but it can happen if you don’t keep you database clean.

Let’s suppose a business has been trading several decades, ever since email came out, the business has been entering customers’ email addresses in there database, they have around 10K customers. Every month they send out a marketing email to all the email addresses in there database with details on promotions and new products. The emails include an unsubscribe link to keep customers happy if they don’t want any more marketing messages. Everything appears sound. Now consider all the customers email addresses that are no longer valid, for whatever reason, let’s say 20% are duff, that’s 2000 bad email addresses they are sending out to each month. Quite a few may be to domains that no longer exist, but of that 2000 let’s say 100 are @yahoo.com, 100 are @aol.com, and 100 are @gmail.com if they do this every month then blacklisting is inevitable.

Be aware of this and keep you database clean, catch NDRs and update your database removing invalid email addresses.

The simplest action to take is to get employees to manually remove bad email addresses from the database when NDRs are received. How well this will work in practice is another matter.

You can use the “Return-Path” header in your messages, this should be where NDRs are sent back to. You could use this to create an automatic bad address removal system.

Dealing with getting blacklisted

So you’ve been blacklisted you may be getting NDRs back telling you this, or just messages are not getting though and you know it’s at your end as they send fine from a web mail account. You can confirm you are on a blacklist using the “Blacklist Check” tool at http://mxtoolbox.com/.

First off think about what you’ve done, if you have been sending bulk emails without keeping your database clean of non-existent email addresses then you need to address this problem to start with.

Maybe it was some malware that caused the problem, if so then get it sorted out.

You may be able to get yourself removed from individual blacklists, look at the web site for the blacklist maintainer and see if there is some mechanism for this.

You can also contact individual postmasters and get yourself whitelisted. You may find you are only getting NDRs back from and handful of you best customers, investigating where there MX records point to you may discover they are all using the same mail hosting server. Contacting the postmaster of this server and explaining the problem they may put you on the server’s whitelist which will allow your IP access overriding the blacklist.

The only other thing you can do is change the IP address of your SMTP server. You can configure your network interface to have multiple IP addresses, so during the transition it can still accept mail on both IPs. Make sure you update your MX records, reverse DNS, and the SMTP banner should all match, see the sections above. If you have plenty of IP addresses available with your Internet connection then this may not be so bad.


Spludlow Web Footer