Simplest way to receive email to a lambda - AWS Simple Email - amazon-web-services

I am new to SES and thought it would be a quick setup but its looking a bit more involved than expected. I also have to go through a client so I want to make sure I understand my options before I make any requests.
So I have a client who has set up an email mailbox in outlook, dev#clientdomain.com. I want to have emails sent to this go into a lambda for processing, so I was looking at SES. Do I need to go through the same setup as if I was going to be sending emails? That is do I need to verify a domain identity or can I get away with verifying just an email? Do I need to ask the client to publish an MX record on their domain?
Tbh I was hoping I could just some email address in AWS that is linked to a lambda, and then have the client email forward to this. Is there nothing straight forward like this in AWS? I am able to send emails with the client email following this, but how can I receive an email and parse it with a lambda the easiest way?

Related

How to bcc another recipient on an Amazon Cognito verification email

For legal reasons I need to BCC someone on my Cognito verification emails when someone signs up on my website. Is there a way to configure this in Amazon SES or Cognito? I have searched through the settings on both of the services and searched google but I haven't been able to find anything. I am wondering if maybe I should use SNS to trigger a welcome email with the compliance information after the user verifies their email, though I am still not sure if this is possible.
You will need to implement a Cognito custom email sender Lambda function. There's an example of that function using NodeJS at the above link. Having gone through this myself I would point out that it can only be done using NodeJS or Java due to the specific AWS encryption SDK needed to decode the email body in your Lambda function.
Inside that example Lambda function you can see the different event triggers the function has to handle. In the CustomEmailSender_SignUp trigger handler you would add your BCC when you send the email.
You would need to use the AWS SDK inside that code to send the emails using SES.

Custom domain + receiving at SES

I'm wondering if anyone has done the below before, the documentation is not apparent since this is sort of combining two configurations on AWS...
I use SES for receiving mail more than sending it. It's a pretty good service to use as a catch-all for domains without multiple users, which works fine for... say, small non-profits in which one person answers all of the incoming email from a few public addresses. I have all incoming mail dumped into an S3 bucket and the SES active rule set triggers a Lambda function to parse the recipient of the incoming mail and forward it to predefined gmail addresses.
However, I have one account that wishes to send out fundraising mails to newsletter subs, and of course they'll want to buy their own IP from AWS for this purpose, to include DMARC and PTR records for minimizing their losses to spam filters.
SES has the capability to do this, by setting a 'custom domain' for your outgoing SES email. The catch is, by going through the motions to set this up I notice that SES designates the incoming MX you must use to feedback-smtp.(region).amazonses.com rather than the inbound-smtp.(region).amazon.ses.com that normal receiving at SES requires.
Can these two configurations (receiving as well as custom domain for outgoing) co-exist? Or does feedback-smtp.(region).amazonses.com get handled differently somehow?
Anyone done this before?
You don't need to worry about the Feedback MX address.
In SES, you can't have Custom mail from for naked domain (e.g: example.com)
You need to use something like mail.example.com and publish the MX record as feedback-smtp.(region).amazonses.com, this won't affect your incoming emails.
To comply with DMARC using that, you need to make sure that aspf is set to relaxed.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/dmarc.html

Should AWS SES bounce emails be notified by one or more methods

AWS Simple Email Service (SES): Bounce Email Notification/Feedback
I have both the following methods set up in the AWS Console to receive information about bounce emails:
1) Email Feedback forwarding - to send any bounce email details back to the sender. This is the domain or email that is managed in the AWS console and is verified. Hence the From/Source is a valid user email with a mailbox
2) SNS Notification for bounce emails - This is used to trigger a lambda function and the intention here is to get a notification on the emails that bounced and was sent from an address of a verified domain that doesn't have a mailbox e.g noreply#domain. This is automated from the software.
The lambda function forwards this notification to the reply emails that are part of the Header in the notification.
The reply emails may also contain personal email addresses that are not necessarily managed in the AWS console. Therefore the lambda is basically forwarding the notification back to all the reply emails of the user.
My issue here is that the above works but sometimes I get notifications using both methods.
Should AWS only choose one of the above two when dealing with bounces? Can someone please shed some light on this?
Thank you
Try creating a Deliverability dashboard, it now provides excel sheet to download and track your bounce emails.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/bouncecomplaintdashboard.html
The AWS documentation is not super clear with respect to simultaneously using multiple methods for bounce email notification. However, the following under 'Disabling Email Feedback Forwarding' does indicate that using more than one method for bounce notification will result in multiple notifications.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/notifications-via-email.html
In my case (using the above two methods for bounce email notification), When I use the SES via SMTP interface from an Asp.Net app, I get two bounce email notifications, one via SNS and the other via the Email Feedback Forwarding method. In Addition when I use an email client like MSOutlook, then I only get one bounce notification which is expected
because it's not using SES.
My solution:
Option 1:
Use both methods for SES.
The Email Feedback Forwarding method will be responsible for delivering the notification to a verified email eg user#mycompany.com with a mailbox.
The lambda triggered by the SNS method will have a filter that will only process notifications where the source is norepy#mycompany.com.
Hence this will prevent duplicates and will also allow me to forward bounce email notifications to other reply-to emails (set by the web app in the header) that are not verified in my AWS.
Option 2:
Disable Email Feedback Forwarding Method and process all notifications via lambda triggered by SNS Method.

Amazon SES - notifications for email verification

We use Amazon's SES service, and have set up Topics and Subscriptions under SNS (Simple Notification Service) so that we get notification emails when an email is bounced or successfully delivered. That's all working fine.
We sometimes send emails via SES on behalf of one of our partners, and before we can do that we need to verify their email address. The process is that the system asks SES to send out a verification email to the person saying "Example.com wants to send emails on your behalf, is that ok?", with a link for them to click. If they click it, then that email is marked as Verified within SES, and we can use it as a from address.
What I can't work out is how to automate the process of knowing whether they've clicked the link yet. I can log in to the AWS dashboard, and go and look at the list of verified email addresses, but i'd like to make it an automated process.
What would be ideal is if it worked the same way as bounces & deliveries: that i set up a "Verification" topic, and subscribe to it so we get an email like we do with bounces and deliveries. Then, the scheduled job that deals with incoming email notifications can say "Aha, this is a verification email for foobar#example.com: I'll mark their account as 'ses-verified'".
Does anyone know if it's possible to set this up? All the docs on the SES site just talk about bounces, deliveries and complaints.
thanks, Max
You can use the GetIdentityVerification api call in the SES part of the awssdk:
https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityVerificationAttributes.html
You could do this in a serverless way by having a lambda function do the check, and expose the lambda as an API endpoint to your application (among other ways).
Alternatively you could just try to send a single test email to a test/internal email address and check if it gives you an error - if its not verified, it will return an error immediately when you try to do the send.
EDIT:
If you want to use the CLI instead:
aws ses get-identity-verification-attributes --identities "mailbox#thedomain.com"

AWS SES for bulk mail : Require email verification?

We're thinking of moving to Amazon's SES for sending bulk mail. It appears that we have a unique API call for each email we want to send. So if there are 20k emails to send, we make 20k API calls. My question is, do we need to verify these email addresses before we send to them? We have an existing database of users and I'd rather the transition to SES to be transparent to them.
I noticed that SES has an API method for verifying emails. If we aren't required to verify, why would someone would use this method?
http://docs.amazonwebservices.com/ses/latest/APIReference/index.html?API_SendRawEmail.html says:
Important:
If you have not yet requested production access to Amazon SES, then you will only be able to send email to and from verified email addresses.
So, that method you asked about is used for building a list of addresses that can be e-mailed to, if you haven't requested production access yet. Since you seem to already have done that, it's not useful to you.
Note - once you have production access, you will still need to verify email addresses you are sending FROM, but not to.