Sending email through code is not as simple as one might expect. Jeff Atwood, founder of Stackoverflow / the Stack Exchange Network, has a strong opinion about that and shows that there are a lot of things to consider if you want to do it properly.
It gets even more complicated when you’re trying to send email from a cloud service. Steve Marx, who works in the Windows Azure Team for Microsoft, wrote a blog post about that (which also has a link to the aforementioned article by Jeff Atwood). He also points out that, when running a cloud service, receiving email is not the big deal – sending is.
One way to get around all of these hazards is to not send email directly but to relay it through a third-party provider. Currently, we’re using Amazon Web Services’ Simple Email Service, known as AWS SES. What are the advantages of this approach?
- There’s no need to host your own SMTP server in order to get your emails out
- It handles many of the problems described in the above blog posts, such as spamming from the Windows Azure IP ranges and authenticating your emails via DKIM
- It’s a SaaS pay-per-use model, so there are no upfront or fixed costs involved
Historically, SES only offered the ability to send emails issuing webservice calls. For this purpose, you had to reference the AWS SDK and structure your message by means of their SDK (or implement the appropriate calls yourself). This worked well for us with simple messages without attachments.
When it’s coming to attachments, this gets much more complicated. Sending email with attachments has now been possible with SES for about a year, but AWS SDK doesn’t offer any support for them. Instead of composing messages using their SendRawEmail methods, we decided to try a relatively new feature of SES:
As of December 2011, instead of using webservice calls to send messages we can now choose to use the standard .NET SmtpClient and target it at an AWS SES SMTP endpoint. This means we can now handle attachments in a way we (as .NET developers) are already familiar with.
WhenI tried this new feature at the beginning of 2012 I hit a wall that made it impractical. The reason was that .NET’s SmtpClient only supports STARTTLS but SES SMTP endpoints enforced TLS, so they were not compatible. This has been solved in March 2012 (SES now also supports STARTTLS) so that sending mails is now finally as simple as this:
Client = new SmtpClient(“email-smtp.us-east-1.amazonaws.com”, 587);
Client.EnableSsl = true;
Client.Credentials = new NetworkCredential(awsSmtpUser, awsSmtpPassword);
The necessary credentials for SES SMTP can be created using AWS Console.
We are using SES in many of our solutions, mostly for health and status reports or critical notifications sent directly to our team. We welcome these changes to AWS SES and think it adds to the versatility and simplicity of the service. That being said, we will continue to use the older alternative (webservice calls to AWS SES) since some scenarios (e.g. corporate firewalls) don’t allow connections to arbitrary external ports. Webservice requests are much more likely to succeed.
When evaluating SES for your purposes, keep in mind that SES imposes send ratio restrictions, even after your account leaves sandbox and enters production mode. You might have to compensate for that in your code.
Trackback von deiner Website.