Skip to content

Magento does not send emails with Content-Disposition: inline headers anymore #29258

Closed
@gwharton

Description

@gwharton

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 (*)

  1. 2.4-develop

Steps to reproduce (*)

  1. Configure the store in any way you like and trigger an email to be sent

Expected result (*)

  1. Email should be received and have the "Content-Disposition: inline" header, and it should not be UTF-8 encoded.

Actual result (*)

  1. "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

Issue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P1Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing.Priority: P2A defect with this priority could have functionality issues which are not to expectations.Progress: doneReported on 2.4.0Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchSeverity: S1Affects critical data or functionality and forces users to employ a workaround.

Type

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions