How to create an email account and set up email receiver when using AWS EC2 and SES? - email

So we are planning to use AWS SES for sending emails. But how do we set up the email receivers? And how do we create an email accounts? When activating AWS SES, it asks to verify an email account (eg. help#example.org)...
I tried to create a mail server on one of the instances using postfix following this article: http://flurdy.com/docs/postfix/, but it's not easy at all... Does anybody know any better alternatives?
Thanks.

SES is for sending email only. As you note, you must have some other way set up to receive email at least at the "From" address you intend to use, because Amazon will verify it before letting you send.
While you certainly could set up an email server and domain on an EC2 instance, it's very complicated. I recommend that you get an email service for just that purpose. If you only need a single address for all your messages, just get a free address from Google, Microsoft, Yahoo, etc.
If you need multiple addresses, consider getting Google Apps for Business, either for an existing or new domain name (it's easiest to set up if you have it register a new domain name for you). It's no longer free, but it's still quite cheap. A single user account can receive emails for every address in the domain, it's flexible, and it's reliable. It's a good companion to using SES for sending automated emails.

Use Amazon WorkMail if you prefer AWS. Gmail for work, Office 365, Hostgator, are some other examples. FYI, none of these providers simply provide domain emails. They come bundled with many other things such as chat clients, calenders, etc. Pricing of these services depends on what other things they are bundled with.
$4/user/month for AWS
$5/user/month for Google
$5/user/month for Microsoft
Since you are in AWS cloud, I will tell you a few things about Amazon WorkMail.
You get your own domain and 50GB of storage per user.
You get calendars for free.
You cannot use just any desktop mail client. You have to either use Outlook, or Mac's mail client, or the web interface. This is their weakest point. However, including other IMAP clients is in their roadmap (I guess atleast a year).
Integrates nicely with SES.
Important links:
FAQ page.
Features page.
There are many more features such as remotely removing emails from a device, managing your users, and so on.
What I can recommend you is to use Amazon WorkMail because they almost provide all the features supported by others, and you are tied with AWS anyway. AWS also recently launched Workspace and Workdocs (both separately billed) that will allow you to create a complete work solution. These services also combine nicely with IAM.

Related

How to acheive high email deliverability without sharing data with 3rd party ESP?

We are hosting customer data on behalf of companies/clients, and one of our tasks is to send out a very specific transactional email from us (with our email address as sender and reply-to) to clients customers.
We are trying to move away from storing the personal part of a customers data, including his email address. Of course, in order to be able to send out an email to a customer we need to at some point have access to the email address, but in our view it's a step in the right direction to retrieve the email address from the client during a session instead of retreiving it from our own database.
The problem now is that our unwillingness to have email addresses stored anywhere rules out using email service providers like Sendgrid. Instead we need to send out lots of emails through our own server, and this might hurt deliverability. I've been looking for a kind of "self hosted Sendgrid". One who will enable us to send bulks of emails, and one we can tweak to not store the sent emails.
One solution I've found is sendy.co who defines themselves as:
Sendy is a self hosted application that runs on your web server.
This sound promising, but then I read that emails are sent through Amazon's cloud:
Sendy uses multi-threading to send emails via Amazon SES.
I suppose this leads us back where we started, because then Amazon is storing the email addresses.
As I understand, the high deliverability that ESPs achieve is not only caused by state-of-the-art email headers, but also by their servers being recognized by Google/Gmail, Microsoft and other email hosts. So maybe a high deliverability just isn't possible without an ESP. But is there an alternative approach that lets us acheive relativly high deliverability without needing to involve a 3rd party server to do the sending?
The reason that people tend to pay for this service is because it is reasonably difficult/complicated/time consuming. If sending this email is a core part of your business, you'll want to hire a deliverability engineer to handle this. If it's not, I'd start by contacting the various transactional ESPs and see if you can find one that has an enterprise offering they're willing to tailor to this use case.
I think that I'm a little late to this. I hope that you figured out your question by now.
If you haven't then:
One alternative that you can try is to host your own server with an on-premise option. I would check out SocketLabs Hurricane MTA.
SocketLabs is a cloud ESP, like Sendgrid. But they also have a powerful on-premise option.
https://www.socketlabs.com/blog/introducing-hurricane-mta-3-0/

How to create Email like "info#domain.com" and send and receive email in aws amazon

I am trying since a last few weeks to setup an email, for example,info#domainname.com, in aws Amazon SES
I tried some of the links:
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email.html
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-email.html
I even went through a similar question marked closed on Stack Overflow:
How to set up Amazon SES to send and receive emails
But couldn't finish the setup correctly. Would anyone please help me to finish this task?
For your reference, I am using Free tier AWS account and have the domain attached to my Godaddy account.
When you say you want to send and receive emails, what do you mean ?
Generally SES is used to send emails from an app that you run and you want this service to handle all the posting for you, from doc - why use Amazon SES
Building a large-scale email solution is often a complex and costly
challenge for a business. You must deal with infrastructure challenges
such as email server management, network configuration, and IP address
reputation. Additionally, many third-party email solutions require
contract and price negotiations, as well as significant up-front
costs. Amazon SES eliminates these challenges and enables you to
benefit from the years of experience and sophisticated email
infrastructure Amazon.com has built to serve its own large-scale
customer base.
The receiving part as noted in doc
When you use Amazon SES to receive messages on behalf of your verified
domains, you can configure Amazon SES to deliver your messages to an
Amazon S3 bucket, call your custom code via an AWS Lambda function, or
publish notifications to Amazon SNS. You can also configure Amazon SES
to drop or bounce messages you do not want to receive.
so on receipt, SES will trigger rules that you have defined.
From your question, it sounds like you want to use a basic email client to do sending/receiving of emails, in this case Amazon provides another service called Amazon Workmail which you can compare with google apps.
If you're really looking into sending email from an app using SES, you can review this link which explains how to do it with GoDaddy

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

I'm new to Amazon SES and I see that there are two ways to programmatically send emails:
SES API (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-api.html)
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.
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.
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.
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
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.

Setting up Email Accounts EC2

I am just getting started with AWS and EC2 and can't quite get my head wrapped around what to do with email.
On previous servers, I would use it as a mail server and on cPanel create all the email accounts I needed, and could access them through web mail.
I can't get a consistent answer on how to set up email accounts on a domain that is pointing to an EC2 instance.
My question is, how can you set up email accounts for a domain pointed at EC2 instance, and if its not possible is there a way to set up emails on a third party like gmail with the domain pointed at EC2?
Just so you know the domain is managed at GoDaddy.
Thanks
I suspect if you are trying to treat it like shared hosting, EC2 may end up being more work than its worth. If you do want to give it a shot, read on.
EC2 provides mostly barebones virtual machines that you can purpose for anything you may need. They don't come with hosting control panels as many people use instances for things other than hosting websites.
You should be able to install cpanel or directadmin, but you may have some difficulties getting it to licence correctly as licences are often tied to a public IP (In EC2 everything is NAT'd).
To set up email on your instance, you need to install some kind of email server. There are quite a few different options available depending on what host operating system you choose to use. There are alot of tutorials that can walk you through setting up a mail server.
Now, for the annoying part. All EC2 IPs are on Spamhaus blacklists. To get around this, you can you can either configure your email server to forward through Amazon SES or fill out this form to whitelist your server IP: https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request
Running your own email servers on ec2 is doable, but if it is my call, i'll go with something like Google Apps for Domains to handle my email accounts.

Send over 1000 emails per day via gmail, amazon sns, or own smtp

I'm trying to code a mail sender service. Previously I built a simple desktop application which uses my shared hosting mail server to send html mails. But now it's not enough and I plan switching to Gmail or Amazon SNS.
For Gmail I have to use min 15 different accounts to be able to send up to 1500 emails. Also sometimes gmail blocks the accounts and I have to login and change the passwords.
I've just signed up for Amazon SNS but it does not looks to what I need. You first have to subscribe users then send emails. Also emails are sent from no-reply#sns.amazonaws.com addres. Is this the all service or I can configure it as I wish?
I also read some suggestions to lookup the MX records for the destination mail servers How to send 1000+ emails per day using an ASP.NET Web site
I want a minimum cost solution. So which is best and is there a better solution?
We use Mailjet for 3 sites now. Initially we used the free plan (6000 / month) to test the set-up and reporting. Now the 3 sites are run on it. Very satisfied - especially since they offer dedicated IP monitoring. According to us, it's rather easy to install. SMTP very easy and one of the sites integrates with the API. I'd recommend
There are a multitude of services available for you that will allow you to send 1500+ emails per day and will get the headache of email deliverability off your plate.
PostageApp (Ours!)
SendGrid
Postmark App
Deliver
Mailjet
Take a look and see which fit your needs and have the implementation method that you are looking for. They each have a free service, so it's definitely easy to try.
(Full Disclosure: I am the Product Manager of PostageApp. Let me know if you have any questions!)
A relatively new option for transaction emails that seems pretty good from Mailchimp:
Mandrill
Looks like it has decent integration with their main service as well.
You can utilize some premium services to send 1000 emails here, daily for free
Remember, you should not spam in the services listed, just you create multiple lists in all accounts & send emails daily.