Description
Right from the beginning, Magento has always sent emails with Content-Disposition: inline set as a header. This was the default implementation of MIME encoded emails provided by Zend Framework 1. Magento never needed to do anything as it was handled within ZF1.
When Magento moved its mail handling routines to Zend Framework 2, the content-disposition header, along with other functionality, such as mime encoding text based emails so they can be UTF-8 encoded was lost during the transition (This functionality was previously provided by ZF1 by default, but with ZF2 it was now Magento's responsibility to implement). I patched these missing items back around July 2019 with a series of commits (fa030f2, 226009e).
Unbeknown to me at that time, ZF2 contained a bug which caused the Content-Disposition: inline header to be UTF-8 encoded which caused some problems with some mail clients adding the body of the message as an attachment.
Because of this issue, another commit was made (6976aab) which removed the Content-Disposition: inline header, as removing the header altogether made the email clients that previously had trouble with the incorrectly UTF-8 encoded header, now work.
Laminas-Mail have now fixed the issue in release v2.11.0 so this can now be looked at again, and the Content-Disposition: inline header reintroduced, as it always has been in previous Magento releases.
See for further discussion
#26913
https://github.com/mageplaza/magento-2-smtp/issues/227
#25076
laminas/laminas-mail#2
Preconditions (*)
- 2.4-develop
Steps to reproduce (*)
- Configure the store in any way you like and trigger an email to be sent
Expected result (*)
- Email should be received and have the "Content-Disposition: inline" header, and it should not be UTF-8 encoded.
Actual result (*)
- "Content-Disposition: inline" header is not present at all.
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status