You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AWS SES API transport implementation for Mailer is not using the recipients set on the envelope in all cases. If an email has attachments the envelope is entirely ignored and the message send in its raw form. In every other case "to" destination is set from the envelope but cc and bcc is still read from the email headers.
How to reproduce
Configure the Mailer with AWS API transport (ses+api://AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY@default), override the recipients via EnvelopeListener according to the sf docs and send an email with attachment (envelope ignored) or a cc/bcc (to gets rewritten but cc/bcc is still delivered).
Possible Solution
Use the AWS SES SendRawEmail endpoint in any case and set the API parameter Destinations to override an emails recipient in case the envelop recipient are different from the emails header recipients.
Additional context
For us this is kind of critical because we use redirection in a staging environment where the customer is expecting all emails to be redirected while testing his software. We are currently using our own AWS Mailer transport based on the AWS SDK and implemented the mentioned fix and redirects are done reliable. I would be happy to provide a PR with an implementation for the Symfony provided transport.
The text was updated successfully, but these errors were encountered:
I am also slightly confused what the difference between the AWS API and AWS HTTPS transport is. The HTTPS transport is calling the AWS API via https as well as the API transport. The main difference is that the HTTPS one is ignoring the Envelope of the message completely. So I would not advice anyone to use this one.
This PR was squashed before being merged into the 5.1-dev branch.
Discussion
----------
[Mailer] Use AsyncAws to handle SES requests
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | #33183, #35468 and #35037
| License | MIT
| Doc PR | TODO
alternative to #33326
This PR replace the native code to call AWS SES by the new [AsyncAws](https://github.com/async-aws/aws) project maintained by @Nyholm and me.
This removes complexity of signing request, and adds new features likes:
- authentication via .aws/config.ini, Instance profile, WebIdentity (K8S service account)
- usesignature V4 (the one recommanded by the Official SDK )
- fully compatible with API (uses the official AWS SDK interface contract to generate classes)
Because it's based on `symfony/http-client`, it's fully integrable with Symfony application.
Commits
-------
2124387 [Mailer] Use AsyncAws to handle SES requests
Uh oh!
There was an error while loading. Please reload this page.
Symfony version(s) affected: 4.4/5.0
Description
The AWS SES API transport implementation for Mailer is not using the recipients set on the envelope in all cases. If an email has attachments the envelope is entirely ignored and the message send in its raw form. In every other case "to" destination is set from the envelope but cc and bcc is still read from the email headers.
How to reproduce
Configure the Mailer with AWS API transport (ses+api://AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY@default), override the recipients via EnvelopeListener according to the sf docs and send an email with attachment (envelope ignored) or a cc/bcc (to gets rewritten but cc/bcc is still delivered).
Possible Solution
Use the AWS SES SendRawEmail endpoint in any case and set the API parameter
Destinations
to override an emails recipient in case the envelop recipient are different from the emails header recipients.Additional context
For us this is kind of critical because we use redirection in a staging environment where the customer is expecting all emails to be redirected while testing his software. We are currently using our own AWS Mailer transport based on the AWS SDK and implemented the mentioned fix and redirects are done reliable. I would be happy to provide a PR with an implementation for the Symfony provided transport.
The text was updated successfully, but these errors were encountered: