Symfony version(s) affected

6.4

Description

The fix #59836 for bug #59819 broke attaching inline images to emails from Twig if that part has a CID.

Before the change an attachment would look like this:

--mk3-d5519ae4f67c4b77adc67d13c67652b0
Content-Type: image/png; name="@assets/img/logo-email.png"
Content-Transfer-Encoding: base64
Content-Id: <@assets/img/logo-email.png>
Content-Disposition: inline; filename="@assets/img/logo-email.png"

Now when the same image is attached this is the resulting source:

--mk3-5ae7974fd5db4896b88f552f84d16213
Content-Type: image/png; name="@assets/img/logo-email.png"
Content-Transfer-Encoding: base64
Content-Id: <2cbd223df91ad9f20e2ac4c6a86ad072@symfony>
Content-Disposition: inline; filename="@assets/img/logo-email.png"

It might seem correct to set a CID, but this is only works for attachments if they don't have a content ID. "ad-hoc" attachments using Twig broke here if that part (for whatever reason) has a content ID which will always differ from the filepath.

The problem is that the resulting markup is still referencing the "old" CID:

<img src=3D"cid:@assets/img/email-bg.png" ….

I guess this might have been the reason why the filename was used for ContentID instead of actually using DataPart::getContentId().

How to reproduce

Attach an image part with a CID to an email using email.image in Twig. Send templated email with Postmark API.

Possible Solution

A valid fix (apart from reverting the PR) might be updating WrappedTemplatedEmail::image to actually use the CID of the image part it attaches. I tested this with local Maildev and a real Postmark API transport, but there might be problems I'm not thinking about. This would also "improve" image tags references in email which currently are often referenced with a Twig part that of course doesn't exist anywhere and might be misleading. randomchars@symfony would be much better in my opinion.

Additional Context

No response