Contents
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
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
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.
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.
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.
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.
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.