Unable to reply to emails with attachments after updating to 10.1.1

[a.slyzhko]

Hi there,

After upgrading EspoCRM from 10.1.0 to 10.1.1, users can no longer reply to certain emails containing attachments.

Steps to reproduce:

1. Receive an email with attachments and let EspoCRM fetch it. The attachments are stored with role = 'Attachment'.
2. Open the received email and click Reply.
3. Write a text response without adding or modifying any attachments.
4. Try to send the reply.

Actual behavior:
Attachments from the original email are included in the reply body as inline attachments. As a result, the request fails with a 403 Forbidden error, preventing the user from sending the reply.

Error log:
[2026-11-13 11:04:55] WARNING: (403) Not allowed inline attachment 'ef110027cbcf6119c'. Not inline attachment record. :: POST /Email
[object] (Espo\Core\Exceptions\Forbidden(code: 403): Not allowed inline attachment 'ef110027cbcf6119c'. Not inline attachment record. at /var/www/espocrm/application/Espo/Core/Record/Access/LinkCheck/WysiwygCheck.php:91)

Expected behavior:

Users should be able to reply to received emails without validation errors.

[yuri]

In the step 1, is it inline attachment (image in the body) or a regular attachment?

[a.slyzhko]

It is inline attachment (image in the body)

[yuri]

So there are two problems:

1. Why it was not written with inline attachment role.
2. How to by-pass access check for the replied body contents. This is more complex without introducing framework API changes.

[a.slyzhko]

For the first problem it seams to be the system never tries to write email body attachments with inline attachment role. We have half a million emails fetched to the system during last 3 years, but none of them have related attachments with the role 'Inline attachment'.

[yuri]

We have many Inline Attachments from inbound emails. Maybe your IMAP server modifies the Content Disposition header?

[a.slyzhko]

I've managed to retrieve and inspect the original MIME message.

The email was generated by Microsoft Outlook 16.0 and contains three PNG images embedded in the HTML body, plus one regular PDF attachment.

Here is what I found:

• All three PNG images are inside a multipart/related section.
• Each image has a Content-ID matching an <img src="cid:..."> reference in the HTML body.
• None of the three PNG images has a Content-Disposition header.
• The PDF attachment explicitly has Content-Disposition: attachment.

Example of one image:

Content-Type: image/png;
name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: <image001.png@01DD728D.48165040>

The corresponding HTML:

<img src="cid:image001.png@01DD728D.48165040">

[yuri]

I'll try implementing a separate check for emails.

This all is intended for preventing stealing new attachments with known ID. It was a security measure.

[yuri]

These 3 commits should solve the problem. Now, attachments from the replied emails are skipped in the check.

https://github.com/espocrm/espocrm/commit/44e0dbdb87d9c839d212f250b8e60eb501342078

https://github.com/espocrm/espocrm/commit/ede3a2cb632570ec1638d7dea324c4508c125e59

https://github.com/espocrm/espocrm/commit/53f5cb87a4a3489ec9724d4ed7b37a74f0c71f00

[a.slyzhko]

Thanks for the fix! I'll be able to test it on Monday.

While reviewing the tests, I noticed this comment:

Emails fetched from a mailbox may reference 'Attachment'-role records in the body (legacy).

Could you clarify why this behavior is marked as legacy? As far as I understand, it can still occur with newly fetched emails when inline images don't have a Content-Disposition header.

Does legacy refer only to previously imported emails, or is this behavior expected to change in the future?

[yuri]

I plan to come up with a solution, but not now.