I am trying to send an email via Amazon SES. I came across a pretty weird behaviour regarding the email's DKIM Signature.
According to this documentation, the last 2 lines stipulate that Amazon SES adds a DKIM signature of its own, which looks like this:
Received-SPF: pass (domain of amazonses.com designates 5.240.8.29 as permitted sender)
Authentication-Results: atlas222.free.mail.bf1.yahoo.com;
dkim=perm_fail header.i=#amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;
spf=pass smtp.mailfrom=amazonses.com;
dmarc=unknown header.from=somedomain.com;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=167098234;
h=Date:MIME-Version:Message-ID:To:From:Reply-To:Subject:Feedback-ID:List-Unsubscribe:List-Unsubscribe-Post:List-Help:Content-Transfer-Encoding:Content-Type;
bh=N9guynJNBoGOSIx//oL1JHgbJyamt5u5yxgWxtw04xA=;
b=geaU3laohsTcVBHSolTgZ2v9L9QKv0dD7B9UIpuPWIEnaUS2COUXFHrlTR66dN7p
j7D90DpKM4hUYUU2LGUIBWw6xGv/4clqol45DBYNZnvyTD9TRR+D3PL6AH2oezRggV1
MTnZ2ygtXlSctbJKWDeZR1AUlAw5VJJrFea9LxQE=
If I activate my DKIM on SES, another signature is added as well as another DKIM line dkim=perm_fail header.i=#amazonses.com.... and when correctly set-up it has pass status.
How can a DKIM signature added by Amazon SES have perm_fail status? Is there a way to correct that?
Finally ! After hours and hours of searching and testing I found out why the Amazon SES DKIM check fails.
It was an encoding problem.
Sending e-mails with the utf8 allowed mime type will cause this error when some exotic characters are sent in email body/headers.
When sending a simple email with a hello world body the DKIM was pass. but sending an email containing a character like this one ᥱ for example with the utf8 led DKIM to fail.
Related
I will try to express my question, I'm sorry if is not the correct way to do it.
I have an AWS SES configured to receive emails from my customers, sometimes the client get in a list and try to send an email too large (above 10MB), and my costumer start to receive bounced emails from all recipients in that list.
The bounce happens when my client tries to send an email for another people but the email of my company appears on CC field.
E.g:
the client sent an email:
TO: wherever#google.com
CC: mycompany#mycompany.com (this one will be sent for my SES); [a lot of other emails.........list]
This mail will be more large than 10MB (my SES must have to treat it).
This chain wil generate an bounced mail for my costumer, once that my email appears on CC list.
It's a little bit complex to express, but basicaly is it.
I'd like to know if is possible to track this attempts when the costumer receive the first bounce email from AWS. and to trigger a alert for me that the costumer is getting in a bounced list.
You can absolutely do this, SES supports notifications per type to SNS. The types are Delivery, Bounce, Complaint.
Each type can be registered to an SNS topic which you can subscribe a Lambda function to.
This Lambda function can then perform any logical decisions that you would like for your workflow.
In addition you can subscribe any email addresses you want to receive the raw notification that it was undelivered, although you will need to confirm there subscriptions before they can receive notifications. This would be ideal for a support inbox for example.
The AWS documentation contains more information about notifications
I have set up a rule set for inbound emails in AWS SES. This inbound rule receives an email and a lambda function processes the email content.
This worked up until a couple of days ago when I started receiving the error message below when sending emails to the address connected to the inbound rule:
4.3.0 smtp; 451 4.3.0 This message could not be delivered due to a recipient error. Please try again later
However - the rule still triggers the corresponding lambda function which means that the email is actually delivered.
How can I prevent the server from sending this response?
Under Actions in Email receiving add a Stop rule set action where it should stop checking additional rules.
The lambda function that I thought was causing this was not the culprit in this case.
There was another rule in place which failed since it did not have access to the S3 bucket in which is was supposed to save incoming emails.
Lesson learned: This error message is sent back from the email server when an incoming SES rule fails to exit successfully.
If anybody comes across this in future and Karl's solution isn't the issue: I had this exact issue and it turned out the action ordering was causing the error.
If the Lambda function action was before the S3 action, it threw the 4.3.0 smtp; 451 4.3.0 This message could not be delivered due to a recipient error. Please try again later error, even though the flow worked as expected. If you swap them over so it is S3 then lambda, it works fine.
I don't have a ton of experience with Amazon SES. For a client of mine, I maintain a small subscription list (about 1300 people) and I use Amazon SES to send messages through from the WordPress blog that this group is subscribed to, whenever there is a new post. Every so often I get complaint notifications from Amazon, but there is no identifying info to tell me who the complaint is from so that I can remove them from my list. How can I use those emails (or some other part of SES) to effectively remove these recipients? I have no intention of sending to anyone who doesn't want to receive these emails (even if they have not unsubscribed on the blog directly), but I can find no way of addressing these complaints.
The messages contain (in addition to the content of the email), information like the following:
User-Agent: ReturnPathFBL/1.0
Abuse-Type: complaint
Arrival-Date: Thu, 17 Aug 2017 10:22:08 +0000
Feedback-Type: abuse
Version: 1
Source-IP: 54.240.27.23
Original-Rcpt-To: 8516be265e1454635b9a5885efb329a4#comcast.net
Original-Mail-From: 0101015defb6e57b-8068a1db-1011-407e-af0c-1bf96aa38c5f-000000#us-west-2.amazonses.com
Reported-Domain: comcast.net
UPDATE
This is maddening. I have now setup an endpoint on my server, and when subscribed to SNS topic I correctly receive logs that I have been subscribed. But then...NOTHING. I still get the useless emails, but I get zero SNS notifications, despite being verified. Still investigating.
UPDATE II
Success!! It turns out that setting up SNS (or email notifications) on the DOMAIN was meaningless. I had to set it up specifically on the EMAIL SENDING ADDRESS. This was CRUCIAL but not at all obvious (at least to me)
Your question been addressed in amazon blog.
https://aws.amazon.com/blogs/ses/tag/abuse-complaint/
Make sure you are following the procedure to handle bounces and complaints from amazon aws.
When I first sent a test message with Amazon SES, the MAIL_FROM was 0101015825ed6274-5b0cad8d-ddb6-425b-9802-782cc554497a-000000#us-west-2.amazonses.com.
In most email programs that address is hidden in the header, and it appears to be FROM a more human-friendly address. This is not the case when using an email to MMS gateway, which displays the spammy looking MAIL_FROM address to the user.
I figured out how to change the MAIL_FROM domain, but that just changes it to something like: 0101015825ed6274-5b0cad8d-ddb6-425b-9802-782cc554497a-000000#my_domain.com.
Is it possible to change the spammy-looking string of characters in the MAIL_FROM to a customized, human-friendly, less spammy-looking local_part of the address?
It is not possible.
The local_part of the MAIL FROM address is a unique, opaque identifier that SES uses for feedback tracking -- linking backsplatter bounces from poorly-behaving mail gateways that "reject" undeliverable mail by first accepting it and then firing back a separate bounce message... as well as spam complaints and out-of-office auto-responders, back to the original sender, message, and recipient.
That's why of the configuration of a custom MAIL FROM domain involves setting the domain's MX record to point to feedback-smtp.[aws-region].amazonses.com -- it collects those responses and correlates them back to the original message.
Techniques of this nature are necessary due to weaknesses in the design of SMTP itself, where it is difficult, unreliable, or impossible to otherwise correlate such events back to the original message that actually triggered them.
Setting up Meteor to use "out of the box" AWS SES is simple, and one can use native Meteor "Email" methods without modification.
Steps to implement this can be found here. Thanks to Brian
Shamblen for putting together a detailed answer.
But one caveat with the "out of the box" SES is you need to both verify the sender and receiver email address.
To remedy this, you can put in a request with AWS SES for what they call, Production Access.
And further, according to Brian Shamblen,
The process to get production access is rather complicated. One will
need to handle bounce and complaint notifications from SES and prevent
messages from being sent to those addresses in the future.
Question
What is the Meteor code involved in handling bounce and complaint notifications from SES and prevent messages from being sent to those addresses in the future?
EDIT: Made modifications to question for clarity.
Requesting production access is fairly straightforward. You just need to contact them and they usually give it to you in a couple of hours.
Information about the process is here: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html
Load up the URL : http://aws.amazon.com/ses/fullaccessrequest/ and let them know what you will be sending via Emails, for example if you will be sending transaction based email (verification of a transaction, etc)
With production access you can either send email from:
A specific verified email address, where you will be asked to click a link to an email sent to that address to verify you own it
Any email under an entire domain. Under this process you prove you own the domain by editing its DNS records to contain a 'key'.
Most use cases are covered under production access, they typically give you 2000 emails a day and rate limit emails to 5/sec (they queue them so the maximum send rate is 5/sec). If you need more than this you can contact them to raise this additionally.
The process of verification is to stop people quickly creating AWS accounts to mass-spam users. If they allowed this straight-off then AWS IPs would be looked at as spam by other email providers.
For bounce notifications, SES tracks these, and you have to make sure that you don't get an above average bounce rate. Typically these would come from sending unsolicited email, which I wouldn't advise sending via SES.
Production access is only approved by the AWS team. Wait a bit and they should easily give you 2.000 emails/day for free.
As per bounces-unsubscribes... You'll need to have the SES API notify you of each email address which has been 'marked' with such status.
You should store all those email addresses somewhere and tell your app not to send them ANYTHING else in the future.