Amazon Simple Email Service (SES) - Should I use SMTP Interface or SES API?

Question

I'm new to Amazon SES and I see that there are two ways to programmatically send emails:

1. SES API (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-api.html)
2. SES SMTP Interface (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-using-smtp-java.html)

What are the pros and cons of each method? They seem interchangeable to me, but I'd like to hear from folks who have had experience with SES.

In terms of my own requirements, I'll be sending transactional emails (i.e. receipts, account confirmation, etc.) and notification emails (i.e. "you have a new message", status change, etc.) to my users as they interact with my web and mobile app. If possible, I'd like to keep a history of all these outgoing emails.

Solution 1

The SES API ties you to AWS, the SMTP interface... well it's SMTP.

Do you foresee, in the future the need to move off AWS? Does your application already speak SMTP to another email server?

Depending on your current application it may be easier to go with SMTP.

If you're starting from scratch and don't foresee any need to move off AWS you should probably go with the SES API.

Solution 2

From Amazon's documentation on improving throughput, one advantage the API is the option of using persistent HTTP connections for increase throughput. This is not available to the SMTP option.

Apart from this, I have not been able to find any other major differences between the API and SMTP.

Solution 3

By using the SES API, you are using the SDK, so you can use Roles on your instances: you won't have to handle and store a password for your configuration, so you won't go through the pain of changing the password.

I released a small project https://github.com/loopingz/aws-smtp-relay to relay from a localhost SMTP to SES API, this way you can connect legacy applications that only handles SMTP to a more normal SES API

Solution 4

They seem interchangeable to me

That's a fair analysis. I use both -- API for new code, SMTP for existing code that already knows how to speak SMTP. I haven't found a strong case either way.

Neither interface will preserve a history -- you'll have to do that yourself. One mechanism I'm working on for use with some legacy code is an SMTP proxy that captures the interaction between the app and SES, saving the entire transaction to S3 using the SES message ID as the S3 key for later retrieval if needed (still a work in progress, more pressing projects to do).

You, at minimum, need to preserve those message IDs returned by SES, and configure bounce, delivery, and complaint notifications so you have feedback... which also works the same with either interface.

View more solutions

Comments

[coder771]

can i get messages in amazon seller account using it?

[HopeKing]

Thanks for the useful link

[Rimu Atkinson]

This documentation has moved to docs.aws.amazon.com/ses/latest/DeveloperGuide/…

[Tengiz]

This answer is very valuable because in many cases, message retrieval is necessary. I wish they were stored somewhere.