By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Amazon SES Click-Tracking Results in 400 Bad Request Errors

0

Hello AWS Community,

I've been experiencing a persistent issue with Amazon Simple Email Service (SES) that has been a hurdle for over a week now. The problem manifests when using the click-tracking feature of Amazon SES, causing a 400 Bad Request error.

For context, the click-tracking feature of Amazon SES modifies the URLs in the emails. However, it seems that the generated tracking URL isn't being properly recognized, resulting in the aforementioned error.

An example tracking URL from my CloudFront logs looks like this: /CL0/https:%252F%252Fwww.google.com%252F/1/0100018845efafc0-3c3f580c-8e89-44a4-a3e1-bce42d0cd72e-000000/zZlJtD0ToaUezqR7BWev5LOdMBR8Uqa9RG6_SUbOqhA=301

My setup utilizes CloudFront, and when attempting to navigate to this tracking URL, it returns a 400 Bad Request error.

I've spent considerable time troubleshooting this issue. Here are some of the tests and checks that I've done:

  1. Reviewed the URL formation for click-tracking: The tracking URL seems to be correctly formed, following the pattern of AWS click-tracking. Despite being correctly formed, it still results in a 400 Bad Request.
  2. Checked if the URL is being double encoded: I've looked into this possibility, but found that the URL is only single encoded, which is the expected format.
  3. NSLookup and DNS Verification: The DNS records seem to be working as intended. An nslookup command on the tracking URL successfully resolves to the expected addresses.
  4. Checked the CloudFront Distribution and Amazon S3 Bucket: Both the distribution and the bucket are correctly set up and do not seem to be the cause of this issue.
  5. Checked the response headers: I observed a '400 Bad Request' error in the response headers, leading me to believe the issue lies within the request.
  6. Verified DNS Records: I've verified that the DNS records are working correctly by running an NSlookup on track.mailpass.ai, which successfully resolved to the right addresses.
  7. Checked Amazon CloudFront Logs from S3: From the logs, it was clear that the request was processed but resulted in a '400 Bad Request' error.

Despite this thorough troubleshooting, the problem persists. This leads me to suspect that the issue could be rooted in the SES click-tracking feature itself, which is beyond my control.

I believe this could be an issue with the SES click-tracking feature, and as such, it's something that I can't resolve on my own. I kindly request the AWS support team to investigate this matter further.

I look forward to your insights and possible solutions to rectify this issue. Thank you for your time and support.

Best regards,

Eran Betzalel.

Topics
Networking & Content DeliverySecurity, Identity, & ComplianceFront-End Web & MobileBusiness Applications
Tags
Amazon CloudFrontAWS Certificate ManagerAmazon Simple Email Service
Language
English
Eran Betzalel
asked a year ago686 views
7 Answers
0

I am not an expert in this, but these are some things that I have ran into related to CloudFront with S3, I am not sure that your issue is with SES at all.

  1. Check your Security groups or network access control lists (ACLs): If your CloudFront distribution is unable to establish a connection with the origin server due to restrictive network rules, such as security groups or ACLs, it may result in a 400 error. Verify the network configurations to ensure that the appropriate ports and protocols are allowed.
  2. Check to see if Static website hosting is enabled on your S3 bucket (it should be enabled I believe in this use case)
  3. Can you put a basic index.html document in your bucket and see that?
  4. Under your Cloudfront distribution do you have anything in the root object to point it to the right document? Enter image description here

Hopefully that guides you in the right direction!

Mike Cairns
answered a year ago
  • Eran Betzalel
    a year ago

    Hi Mike,

    Thank you for your insights. However, I believe there might be a misunderstanding. In this case, I am not using S3 as the origin for CloudFront. I merely used S3 for logging purposes to gain more insight into the CloudFront-SES issue. Consequently, static website hosting and the presence of an index.html document in the S3 bucket are not relevant in this case.

    The core issue I'm experiencing seems to be related to Amazon SES and its click-tracking functionality, specifically resulting in 400 Bad Request errors. My initial assumption is that the redirection system or the URL rewriting done by SES might not interact well with CloudFront, leading to these errors.

    Thanks again for your help. It's much appreciated.

0

Got it. My bad, I misread that. You are not tracking user link clicks in email, but the fact that a user opened the email.

So is this the flow? user opens email -> email client does http GET to fetch the image -> Route53 DNS -> CloudFront -> Origin (fails with 400) If so, what is the origin set to in your CloudFront distribution?

Did you go through this already? https://docs.aws.amazon.com/ses/latest/dg/configure-custom-open-click-domains.html

Mike Cairns
answered a year ago
0

Hi Mike,

Apologies for any confusion. I didn't specify my DNS provider clearly, and I'm using DigitalOcean's DNS, not AWS Route 53. I did go through the documentation you mentioned and followed it, but I'm still facing the same issue.

To clarify the flow in my setup: When a user opens an email, the email client does an HTTP GET to fetch the image, which is then directed to CloudFront through my DNS setup on DigitalOcean. The failure with a 400 status code happens at the origin stage.

I hope this clears up any misunderstandings. Could you perhaps provide some insight into what might be going wrong given this setup, especially considering the origin set in my CloudFront distribution? Any guidance on troubleshooting the 400 error would be greatly appreciated.

Eran Betzalel
answered a year ago
0

To me the problem is between your CDN (CloudFront) and the origin. The DNS provider doesn't seem to be the issue since you are seeing this error in your CloudFront logs. I still don't understand your architecture here, but without sharing any details can you at least tell me what type of origin you are using in CloudFront? I feel like you are leaving out part of your architecture.

Maybe if we start with what you are trying to do and maybe we can work backwards from that and find an alternative?

Mike Cairns
answered a year ago
0

I want to use a custom domain to track click and open events.

I've used this document to configure the environment for that purpose with an added certificate to use it with HTTPS: https://docs.aws.amazon.com/ses/latest/dg/configure-custom-open-click-domains.html

Here is my architecture flow: Email link click -> DigitalOcean DNS (CName) -> Amazon CloudFront -> Origin

It fails at http://[custom domain]/cl0/.... - returns 400.

Eran Betzalel
answered a year ago
0

Stuck with the same issue here, the issue seems to come from the URL generating feature.

my flow is: Email link click -> Cloudflare DNS (CName) -> Amazon CloudFront -> Origin.

What I found interesting while troubleshooting was before enabling the custom domain redirect feature, if I replace the aws domain with my custom domain it works just fine. The redirect behavior is exactly as expected and click metrics gets updated as well. After I enable the custom domain redirect feature, the generated URL with my custom domain gets long (despite custom domain shorter than aws one) and fails with 400.

Rofi
answered 7 months ago
0

I was facing error 400 after enabling custom redirect domain (using CloudFront as CDN for https support).

I've followed the instructions described in the doc: https://docs.aws.amazon.com/ses/latest/dg/configure-custom-open-click-domains.html (Option 2: Configuring an HTTPS domain)

The problem was related to a missing CloudFront configuration. The issue was solved after defining an "Origin request policy" - set to "AllViewer" (Origin behavior section).

After this, all started to work as expected (for http and https).

Thiago Flessak
answered 6 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content