Can you please add a test case?

@nicolas-grekas I could not find any other transport mocking the API they are calling. I wrote a test for normal submission and an envelope example. Happy to hear some feedback.

I've just read your last comment on the issue and that made me re-read this PR. The difference between the API and HTTP transports is the following (true for all transports): API should use the API abstraction of the transport (the transport is responsible for generating the email as a string). For the HTTPS transport, Symfony is responsible for generating the email as a string.

@fabpot thank you for the clarification. I tried understanding the existing transports and did more local testing. I have a couple of questions to have my PR aligning to the concept:

• I use the SendRawEmail API endpoint from AWS (symfony is creating the email string). Should I move everything I did to the HTTPS version of the transport?
  This would also fix the issue that the AWS HTTP transport is not using the envelope at all.
• The current AWS API transport is overriding the TO destination using the envelope recipients but still setting original CC/BCC recipients on the api call. (see https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Mailer/Bridge/Amazon/Transport/SesApiTransport.php#L104-L109)
  If you redirect using an EnvelopeListener the CC/BCC will still receive an email. Is this intended behaviour or can we change this?
• The current AWS API transport is ignoring the envelope when sending emails with attachments and symfony is creating the email string (see https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Mailer/Bridge/Amazon/Transport/SesApiTransport.php#L90)
  Using attachments can not be done when AWS creates the email string. Should we leave the switch from SendEmail to SendRawEmail in this case but ensure the envelope recipients are set?

I'm wondering it #35992 makes this PR not needed anymore.

Closing as the code changed here is deprecated is favor of new classes.