- Newest
- Most votes
- Most comments
2024-07-23T04:58:18.000-07:00 2 632257070288 eni-06361c95e21cc9acd 172.20.104.4 172.31.1.13 49180 587 6 25 2295 1721735898 1721735958 ACCEPT OK 2024-07-23T04:58:18.000-07:00 2 632257070288 eni-06361c95e21cc9acd 172.31.1.13 172.20.104.4 587 49180 6 29 7915 1721735898 1721735958 ACCEPT OK
So, communication both ways; no email received and the only thing I see in the SNS topic feeding the dashboard is
{ "notification": { "messageMD5Sum": "5bb5f6b19bb3c4e085b6e3048361737b", "messageId": "32110e91-0b9d-5e6f-a82a-518895320e9f", "topicArn": "arn:aws:sns:us-west-1:632257070288:SES_Metrics", "timestamp": "2024-07-23 12:05:03.6" }, "delivery": { "deliveryId": "b07ddb1c-4c0e-5f60-ad57-8405d2a1a2ae", "destination": "http://54.219.98.72/webhook/brX64Qw4sh4oOYfeMmy9kLcT5vKFcgWQZxphx_ixmwpbtYBZKMA589ifHi241tHvhG-05T0OVNTKsQLhLNvAfQ", "providerResponse": "Bad Request", "dwellTimeMs": 39, "statusCode": 400 }, "status": "SUCCESS" }
No idea why it's a bad request. Let me think about how to see what is being sent to SNS that is giving the Bad Request.
Hi, Have you done proper ses configuration like domain verification, sender id verification and got production approval(not sandbox)
Enable to cloudwatch then share the log details
Thanks
Yes, I guess I should be clear the systems not using the VPN have no issues sending emails. It's just the connection via the VPN and the VPC endpoint that are having issues. Not sure what other logs I can show, the SES service doesn't really have a log group. I am using SesDashboard from the marketplace and it is not seeing any emails sent from SES that are coming from that address.
Can you change your security group to allow ALL traffic (0.0.0.0/0 all ports all protocols) just to test and verify if the SG is indeed not the root cause here.
(I see for example some of your rules relate to 172.31.0.0/24 but the IP I see in the VPC flow log you shared is 172.31.1.13 which is not in that range)
Oh, you're right about the range on the rule - needs to be /22. Let me try that first. I am not really wanting to throw the doors wide open if I don't have to. I do also have a rule that allows all traffic within the security group to all ports, but let me change the CIDR to /22.
I am baffled by this
2024-07-25T11:37:05.000-07:00 2 632257070288 eni-06361c95e21cc9acd 172.20.104.4 172.31.1.13 49205 587 6 25 2295 1721932625 1721932685 ACCEPT OK
tgw-attach-025bd083a6c4c4538 172.20.104.4 172.31.1.13 49205 587 6 25 2295 1721932625 1721932632 OK IPv4 0 0 0 0 27 us-west-1 egress - -
2024-07-25T11:37:18.000-07:00 2 632257070288 eni-06361c95e21cc9acd 172.31.1.13 172.20.104.4 587 49205 6 5 327 1721932638 1721932698 ACCEPT OK
tgw-attach-025bd083a6c4c4538 172.31.1.13 172.20.104.4 587 49205 6 29 7915 1721932625 1721932632 OK IPv4 0 0 0 0 27 us-west-1 ingress - -
There is clearly a connection happening and data being sent to the SMTP service, but an email is never actually sent out. I don't ever get an SNS message for it, an email in my email inbox, and I have no idea how else to track down the issue.
Relevant content
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
looks like changing the security group got you one step further and now the request is received by SNS. Now you need to take care of handling the bad request.
I setup another SNS with an email subscription and I am not ever seeing this same type of thing but I am also never seeing anything from the system in that message topic.
Yea, there is never even a SEND coming through.