Magento2: Magento 2.3.3 notifications converted to attachments in MS Exchange - Disposition Header

[jaminion]

Preconditions (*)

1. Magento version 2.3.3 (worked fine previously on 2.3.2)
2. Outlook 2010 behind MS Exchange 2010 (don't have later version accessible for immediate testing with this project), or Outlook Web Access, have also confirmed with Mail clients on Mac, iPhone and Android that pull mail from this Exchange server
3. Issue does not appear to affect rendering from Gmail/etc - seems to only be clients that are connecting to MS Exchange 2010 to retrieve the message

Steps to reproduce (*)

1. Submit an order, send order notification or send shipment notification
2. Receive email using a client/server combination similar to above noted configuration (Outlook/Exchange)

Expected result (*)

1. Receive an email with the body of the message containing the rendered template for the order notification email

Actual result (*)

1. Receive an email with a blank body, and the content included as an ATT*-labeled attachment to the email
2. 

Notes

I understand that this Outlook/Exchange combination is fairly aged, but it's what I'm working with for at least the next couple of months.

I believe this is associated with the changes from #23643, putting the quoted-printable [back] into the emails.

From what I can determine, when a header is rendered, it's processed by a class implementing Zend\Mail\Header\HeaderInterface. There is no class registered for the header "Content-Disposition", so it ends up getting rendered through the Zend\Mail\Header\GenericHeader class. The getFieldValue() method looks like this:

    public function getFieldValue($format = HeaderInterface::FORMAT_RAW)
    {
        if (HeaderInterface::FORMAT_ENCODED === $format) {
            return HeaderWrap::wrap($this->fieldValue, $this);
        }

        return $this->fieldValue;
    }

When commenting out the if() block above, the email looks fine when it's received. What's happening is that the Content-Disposition is getting set to "inline", however when rendered it is being translated as quoted-printable and ends up with a value of =?utf-8?Q?inline?=, instead of inline. The MS Exchange 2010 involved appears to reject or not understand this disposition type and treats it as a generic attachment.

I don't believe that it's necessary/good to have the Content-Disposition header encoded like this. Maybe it is. I'm not completely familiar with the relevant RFCs and it's completely possible that this Exchange server is not handling it correctly. I will be attempting to find a workaround I can implement as a local plugin for now, but wanted to get this out in front of more experienced Magento developers in case the impact is greater than an old and just about out-of-support version of MS Exchange.

Thank you!

The 2.3.3 rollout has been working pretty well for us so far outside of this issue - all the hard work is much appreciated, you guys rock!

[m2-assistant[bot]]

Hi @jaminion. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.3-develop instance - upcoming 2.3.x release

For more details, please, review the Magento Contributor Assistant documentation.

@jaminion do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [x] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[jaminion]

@magento give me 2.3-develop instance

[magento-engcom-team]

Hi @jaminion. Thank you for your request. I'm working on Magento 2.3-develop instance for you

[magento-engcom-team]

Hi @jaminion, here is your Magento instance.
Admin access: https://i-25076-2-3-develop.instances.magento-community.engineering/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[jaminion]

I'm sorry - I set up quick on this develop instance, but it doesn't appear like email's going anywhere from it, I'm not receiving anything.

That is probably by design. It would be a spammer's delight if they could just keep asking for instances from you guys and send mail all day. I understand. I'm thinking through setting up a third party smtp somewhere - but this ends up being public credentials/access temporarily and someone could hijack that as well. So, I'm kind of stuck on the reproduction, as it's not something that you can generate directly from the Magento site. It's like trying to see if the dog ate your diamond bracelet - you can't inspect the dog so easily for that, you gotta wait for and inspect the poop instead.

If there happens to be some standard way to approach the notification-from-a-develop-instance problem, please let me know, I'm all ears. Otherwise, I'll leave this hanging out here, and tag it if I come up with something that might be more useful.

Thank you!

[m2-assistant[bot]]

Hi @davidverholen. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

:white_check_mark: Confirmed by @davidverholen
Thank you for verifying the issue. Based on the provided information internal tickets MC-21868 were created

Issue Available: @davidverholen, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

[jaminion]

My for-this-project-immediately solution to this was to add a preference over the Magento\Email\Model\Transport class. The difficulty is that the Zend\Mail\Message instance is the one that's processing the headers, and it is generated using a static method from its class inside the sendMessage method, and used there - it's never accessible at a scope where it's targetable with DI, at least how I'm familiar. It's not so useful to use an around() plugin on that sendMessage() method because the object you'd need to work with, the MessageInterface, is private to that class instance and inaccessible.

I added a DispositionHeader class inheriting from the GenericHeader it would otherwise use and tweaked the getFieldValue() for that, and then adjusted the sendMessage() to pull a reference to the class loader with $zendMessage->getHeaders()->getPluginClassLoader(), and used the registerPlugin() method to add an entry for the disposition to the table. Just a crutch - my immediate use case doesn't handle attachments and filenames, and that's where things get fun - and more susceptible to user generated content.

https://github.com/zendframework/zendframework/issues/4917 is interesting, was closed because nobody was fighting for it when they did a cleanup, but suggests this is kind of a lingering thing with ZF2.

Thank you again, very much, for taking an interest in this problem.

[Timothy-V]

I can confirm this issue as well for Outlook and Outlook Web App behind MS Exchange 2013!

[AndyJAllen]

Also experiencing this after 2.3.3 upgrade.

I tested what jaminion suggested about commenting out the if statement and it worked for me. Are there any side effects of doing this?

[david-kominek]

Also experiencing, this is blocking our upgrade.

[verhaeghep]

Also experiencing since 2.3.3 upgrade. Not only in Outlook but also in Thunderbird with IMAP server.

[AndyJAllen]

On a related note I am also experiencing an issue sending tracking emails from admin.

Click "Send Tracking Information" and it just displays the following:

Anyone else not able to send tracking emails? Edit: created a new thread for this: https://github.com/magento/magento2/issues/25221

This update has been a disaster for me so far. It also broke my "Multiple Custom Forms" module.

[jaminion]

@AndyJAllen we are not having that particular problem - did you by chance apply the "EmailMessageInterface backward compatibility issue patch"? If you haven't seen that, it might be worthwhile to review, although I have not applied that patch as I haven't found any affected code. A link to it:

https://magento.com/tech-resources/download#download2333

They changed the function signature (interface classes mainly) for the Transport class with this update, and didn't appear to anticipate the issues that would cause with third party code using it. Otherwise, in your case it really seems like that particular transactional email template has been wiped and is only displaying the rendered tracking information blocks, the Magento_Sales/templates/email/shipment/track.phtml template.

[AndyJAllen]

@AndyJAllen we are not having that particular problem - did you by chance apply the "EmailMessageInterface backward compatibility issue patch"? If you haven't seen that, it might be worthwhile to review, although I have not applied that patch as I haven't found any affected code. A link to it:

https://magento.com/tech-resources/download#download2333

They changed the function signature (interface classes mainly) for the Transport class with this update, and didn't appear to anticipate the issues that would cause with third party code using it. Otherwise, in your case it really seems like that particular transactional email template has been wiped and is only displaying the rendered tracking information blocks, the Magento_Sales/templates/email/shipment/track.phtml template.

I had tried doing just the patch (which seemed a lot more confusing and complicated than it needs to be). I had put the patch in my root directory and ran the patch command, but it kept failing with errors. I gave up on it.

I then grabbed all the files I could find that were recently updated on github and applied them to my installation; which fixed my custom emailing module...however I still experience this problem where I can't use the "Send Tracking Information" button.... I use the Fedex module.

Thanks for the reply.

Edit: I think you put me on the right path. When I comment out the following line of code in track.phtml it works (albeit, without the tracking number).

<a href="<?= $block->escapeUrl($block->getTrackingUrl()->getUrl($_item)) ?>" target="_blank"> <?= $block->escapeHtml($_item->getNumber()) ?> </a>

[elvinristi]

Confirming also issue when mail server is Kerio version 9.2.5 patch 3 (3336) and Outlook 2016 as email client.

Some guys quick-fixed this by removing Content-Disposition header (which probably isn't the overall solution to this):

• https://github.com/mageplaza/magento-2-smtp/issues/199#issuecomment-542442946

cc @gwharton (ref: https://github.com/magento/magento2/pull/23650)

[elvinristi]

@jaminion did you do something similar to this?

     {
         try {
             $zendMessage = Message::fromString($this->message->getRawMessage())->setEncoding('utf-8');
+            $zendPluginLoader = $zendMessage->getHeaders()->getPluginClassLoader();
+            $zendPluginLoader->registerPlugin('contentdisposition', MyCustomContentDisposition::class);
+
             if (2 === $this->isSetReturnPath && $this->returnPathValue) {
                 $zendMessage->setSender($this->returnPathValue);
             } elseif (1 === $this->isSetReturnPath && $zendMessage->getFrom()->count()) {

[jaminion]

@elvinristi yes, that's exactly what I did - it's unfortunate that a full override of that file was necessary due to the use private members for all of the important bits.

Following the example from some of the other plugins registered for the ZF2 mail header loader, I also registered the MyCustomContentDisposition for "contentdisposition", "content_disposition" and "content-disposition".

In the MyCustomContentDisposition, I only did this:

<?php
class DispositionHeader extends \Zend\Mail\Header\GenericHeader {

    // No wrapping
    public function getFieldValue($format = HeaderInterface::FORMAT_RAW) {
        return $this->fieldValue;
    }

    // specifically just this header
    public function getFieldName() {
        return 'Content-Disposition';
    }

}

I'm sorry I'm not too much more use with this - the M2 codebase can be a bit overwhelming at times, and I always feel that there's a better way to do things.

[RaphaelBronsveld]

Is there any update on this? I'd like to apply a composer patch, or is a complete overwrite via a preference the the only way to fix this?

Thanks in advance.

[elvinristi]

my current hotfix patch was to patch vendor/zendframework/zend-mail/src/Headers.php

Fix: Emails are converted to attachments in MS Exchange due encoded value in Content-Disposition header.

@issue https://github.com/magento/magento2/issues/25076

@package zendframework/zend-mail
@version >=2.10.0

--- src/Headers.php.org 2019-10-28 12:00:52.998605927 +0100
+++ src/Headers.php 2019-10-28 12:06:44.672407149 +0100
@@ -512,7 +512,10 @@
         }

         $current = $headers;
-        $current->setEncoding($encoding);
+        // PATCH
+        //$current->setEncoding($encoding);
+        $current->setEncoding($key === 'contentdisposition' && $current->getFieldValue(false) === 'inline' ? 'ASCII' : $encoding);
+        // ~PATCH
         $this->headers[$index] = $current;
         return $current;
     }

Haven't got yet confirmation from customer if it solved but at least I see header difference.
[EDIT] Got confirmation that now emails are not shown as attachments anymore after the fix.

Header before:
Content-Disposition: =?utf-8?Q?inline?=

Header after:
Content-Disposition: inline

@melnikovi (cc @buskamuza), any suggestions on this what would be proper approach? Should we include plugin for zend mail in Magento email component?

[jesse-thomas]

I am having a similar issue with M 2.3.3, while testing the contact form emails opened in Thunderbird at home (on a PC) display the content as an attachment. At work on a mac the same email will display correctly. We are not using exchange at all, its postfix and a open source imap server.
applying the patch from above makes the email display correctly (not as an attachment)

[extremeskillz]

I'm having this same exact issue with 2.3.3 with my Zimbra email system. This worked fine in 2.3.2. Our clients are Thunderbird. Zimbra webmail client renders the same email in html just fine. Seems to be happening only on the desktop client side, in my case Thunderbird. I did test Outlook and same issue there. So this is definitely a client issue not email server but the main culprit is Magento 2.3.3 as this upgrade started it. Like I said it worked fine in 2.3.2.
Was there a setting that was turned on during the upgrades??????????

[jaminion]

Hey @extremeskillz, one of the changes in 2.3.3 was applying the message encoding to the email header. The way I read the PRs associated with it, someone was having an issue with the subject line not getting split right and their mail getting a bit trashed because it was going over the line limit threshold for the transport service. The encoding ensures the lines are split and marked in such as a way that the mail clients can piece them back together.

Unfortunately, Zend Framework 2, which is now used for the mail transport in Magento 2.3.x (I think 2.2.10+ or so too?), does not have a great whitelist of header fields for which various encodings should not be applied, such as in this case, the "Content-Disposition" header. When the disposition ends up getting set to "=?utf-8?Q?inline?=" instead of "inline" some smtp servers don't handle it very well.

There are various comments in here suggesting how to patch around it with a module, I'd suggest paying attention to elvinristi's comment, and jesse-thomas' support of it. Good luck!

[extremeskillz]

@jaminion Thanks for the update. Was there a fix request for this issue?

[magento-engcom-team]

Hi @jaminion.

Thank you for your report and collaboration!

The issue was fixed by Magento team. The fix was delivered into magento/magento2:2.3-develop branch(es).
Related commit(s):

• 6976aabdfdab91a9d06e412c2ed619538ed034b6

The fix will be available with the upcoming 2.3.5 release.

[david-kominek]

Is this patch not coming to 2.3.4? Short of running the patch file from above, we will have to wait until April to get this patched?

[robolmos]

@magento-engcom-team I can't access that commit 6976aabdfdab91a9d06e412c2ed619538ed034b6

Is there another place to get the patch?

[piotrkwiecinski]

@robolmos could you try today. It was not accessible for me too yesterday but seam to work now.

[george-vlahakis]

my current hotfix patch was to patch vendor/zendframework/zend-mail/src/Headers.php

Fix: Emails are converted to attachments in MS Exchange due encoded value in Content-Disposition header.

@issue https://github.com/magento/magento2/issues/25076

@package zendframework/zend-mail
@version >=2.10.0

--- src/Headers.php.org   2019-10-28 12:00:52.998605927 +0100
+++ src/Headers.php   2019-10-28 12:06:44.672407149 +0100
@@ -512,7 +512,10 @@
         }

         $current = $headers;
-        $current->setEncoding($encoding);
+        // PATCH
+        //$current->setEncoding($encoding);
+        $current->setEncoding($key === 'contentdisposition' && $current->getFieldValue(false) === 'inline' ? 'ASCII' : $encoding);
+        // ~PATCH
         $this->headers[$index] = $current;
         return $current;
     }

~Haven't got yet confirmation from customer if it solved but at least I see header difference.~
[EDIT] Got confirmation that now emails are not shown as attachments anymore after the fix.

Header before:
Content-Disposition: =?utf-8?Q?inline?=

Header after:
Content-Disposition: inline

@melnikovi (cc @buskamuza), any suggestions on this what would be proper approach? Should we include plugin for zend mail in Magento email component?

We also had issues sending via Amazon SES and the aforementioned patch finally solved it for us (2.3.3) !!

[dfelton]

@georgios-2317 I was just in the process of resolving this same issue locally (AWS SES as well).

By chance did you have encoding characters showing up in your email "From" address? My emails received via AWS SES were coming through like this in my inbox:

=?utf-8?Q?Admin=20@ <=20Store=20Name?= [email protected]>

[george-vlahakis]

@georgios-2317 I was just in the process of resolving this same issue locally (AWS SES as well).

By chance did you have encoding characters showing up in your email "From" address? My emails received via AWS SES were coming through like this in my inbox:

=?utf-8?Q?Admin=20@ <=20Store=20Name?= [email protected]>

@dfelton my scenario was that none of our emails were leaving Magento framework. They were all bounced by SES with the Expected disposition, got = response.

[gwharton]

So, does the merged resolution actually fix this issue or not. The merged fix just removes the INLINE content disposition header, it does not change the encoding of the header, as per the patch above?

[george-vlahakis]

So, does the merged resolution actually fix this issue or not. The merged fix just removes the INLINE content disposition header, it does not change the encoding of the header, as per the patch above?

We found that the merged solution is already part of the 2.3.3 source code. So no it does not fix it as we were looking for a solution with that source in place.

[diazwatson]

Guys is removing the Disposition completely https://github.com/magento/magento2/commit/6976aabdfdab91a9d06e412c2ed619538ed034b6
the best approach to solve this issue?
CC @magento-engcom-team

[gwharton]

I added the disposition inline header back in to 2.3 as it had always been there in 2.2. I think the problem was that 2.2 used zf1 which did not encode the disposition inline header in utf8 whereas 2.3 with zf2 encoded the header in utf8 which i think is possibly where the problem lies. Needs some investigation but i would have thought a better solution would be to stop the utf8 header encoding for dispositon inline header in the first place, not to remove the header. Someone elses call!

[diazwatson]

Thanks @gwharton it makes sense.
I think ZF2 recently added some changes in this regards. I am going to check with my colleague @DavaGordon who recently investigated this issue and see if he can provide a better approach.

[DavaGordon]

@gwharton I personally dont agree with the method taken in https://github.com/magento/magento2/commit/6976aabdfdab91a9d06e412c2ed619538ed034b6
and would recommend writing a m2-hotfix to fix this issue until an permanent solution is found

./m2-hotfixes/ISSUE-21868-email-converted-to-attachment.patch

Fix: Emails are converted to attachments in MS Exchange due encoded value in Content-Disposition header.

@issue https://github.com/magento/magento2/issues/25076

@package zendframework/zend-mail
@version >=2.10.0

--- ./vendor/zendframework/zend-mail/src/Headers.php.org    2019-10-28 12:00:52.998605927 +0100
+++ ./vendor/zendframework/zend-mail/src/Headers.php    2019-10-28 12:06:44.672407149 +0100
@@ -512,7 +512,10 @@
         }

         $current = $headers;
-        $current->setEncoding($encoding);
+        // PATCH
+        //$current->setEncoding($encoding);
+        $current->setEncoding($key === 'contentdisposition' && $current->getFieldValue(false) === 'inline' ? 'ASCII' : $encoding);
+        // ~PATCH
         $this->headers[$index] = $current;
         return $current;
     }

I will look at a more suitable fix and post shortly.

[fredden]

I believe https://github.com/laminas/laminas-mail/pull/31 is a fix for the actual bug and 6976aab is merely a work-around. Let's leave this issue open until a proper solution is implemented and the work-around removed.

[borriglione]

So, does the merged resolution actually fix this issue or not. The merged fix just removes the INLINE content disposition header, it does not change the encoding of the header, as per the patch above?

We found that the merged solution is already part of the 2.3.3 source code. So no it does not fix it as we were looking for a solution with that source in place.

That is not correct.

Official fix seems to be commit:
https://github.com/magento/magento2/commit/6976aabdfdab91a9d06e412c2ed619538ed034b6

Compared to the codebase of the 2.3.4 release the commit/patch is not part of it:
https://github.com/magento/magento2/blob/2.3.4/lib/internal/Magento/Framework/Mail/Message.php

But the fix is part of the current 2.4-develop-branch (see https://github.com/magento/magento2/blob/2.4-develop/lib/internal/Magento/Framework/Mail/Message.php). Therefore as mentioned by @magento-engcom-team it seems to be part of the next release 2.3.5:
https://github.com/magento/magento2/issues/25076#issuecomment-558339798

--

If somebody wants to apply the official patch by composer.

Patch file stored in my project in patches/composer/M234/github-pr-25587-base.diff: https://gist.github.com/borriglione/ef981f296eec59cdf06402fffb738f6e
In composer.json add:

    "extra": {
        "magento-force": "override",
        "composer-exit-on-patch-failure": true,
        "patches": {
            "magento/framework": {
                "Fix email MIME type issue https://github.com/magento/magento2/issues/25076 by official commit https://github.com/magento/magento2/commit/6976aabdfdab91a9d06e412c2ed619538ed034b6": "patches/composer/M234/github-25076-magento-framework.diff"
            },
        }
    }

[convenient]

I've arrived at this issue via a different problem.

Emails via Amazon SES are failing completely with the following error

status=bounced (host email-smtp..... said: 554 Transaction failed: Expected disposition, got = (in reply to end of DATA command))

This is because the header is now like the following (introduced in https://github.com/magento/magento2/pull/19978)

Content-Disposition: =?utf-8?Q?inline?=

This is not compatible with Amazon SES because it is not Q-encoded I think

=?charset?encoding?encoded-text?=

The value of encoding can be either Q or B. If the value of encoding is Q, then the value encoded-text has to use Q-encoding. If the value of encoding is B, then the value of encoded-text has to use base64 encoding.

• https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-raw.html

I've worked around this for now with a composer patch doing the following

diff --git a/app/code/Magento/Email/Model/Transport.php b/app/code/Magento/Email/Model/Transport.php
index 79ceb56a8834..3b2dc5c101e7 100644
--- a/app/code/Magento/Email/Model/Transport.php
+++ b/app/code/Magento/Email/Model/Transport.php
@@ -90,6 +90,12 @@ public function sendMessage()
     {
         try {
             $zendMessage = Message::fromString($this->message->getRawMessage())->setEncoding('utf-8');
+
+            $contentDisposition = $zendMessage->getHeaders()->get('Content-Disposition');
+            if ($contentDisposition instanceof \Zend\Mail\Header\HeaderInterface) {
+                $contentDisposition->setEncoding('ASCII');
+            }
+
             if (2 === $this->isSetReturnPath && $this->returnPathValue) {
                 $zendMessage->setSender($this->returnPathValue);
             } elseif (1 === $this->isSetReturnPath && $zendMessage->getFrom()->count()) {

This will allow us to set a disposition, and have it come through encoded plainly for SES like

Content-Disposition: inline

[gwharton]

The header has been removed completely in 2.3.5!!!! Lets hope it gets added back soon when laminas-mail fix the underlying issue, although the above fix is a perfect workaround in the meantime.

@sidolov Sorry for the username tag, not sure if Magento has an eye on this one, I didn't know who to shout. The actual fix that was merged into 2.3 some months back, and was released to the wild in 2.3.5 for the first time removes the content disposition header as it was not being encoded properly, causing problems with some clients. The underlying problem is with laminas-mail which is incorrectly encoding the header when it shouldn't, but removing the content disposition header, which is what was merged a while back is not the right solution. The header should be there, has always been there, and just needs to be not encoded. The above comment from @convenient is a good workaround until laminas fix their issue.

[convenient]

@gwharton My change to tweak the encoding of the header is deployed in production with no issues so far, I will update if I see any issues but I hope I won't.

Agreed, completely removing the header seemed like the wrong move to me. As mentioned above https://github.com/laminas/laminas-mail/pull/31 should hopefully fix this eventually.

[gwharton]

And to revert the change introduced in 2.3.5 which removes the disposition header altogether.

composer patch for magento/module-framework

--- Mail/MimePart.orig.php     2020-04-13 17:35:44.000000000 +0100
+++ Mail/MimePart.php  2020-05-01 18:58:11.620000000 +0100
@@ -50,7 +50,7 @@
         $content,
         ?string $type = MimeInterface::TYPE_HTML,
         ?string $fileName = null,
-        ?string $disposition = null,
+        ?string $disposition = MimeInterface::DISPOSITION_INLINE,
         ?string $encoding = MimeInterface::ENCODING_QUOTED_PRINTABLE,
         ?string $description = null,
         ?array $filters = [],
--- Mail/Message.orig.php      2020-04-13 17:35:44.000000000 +0100
+++ Mail/Message.php   2020-05-01 18:57:11.680000000 +0100
@@ -171,6 +171,7 @@
         $part = new Part($body);
         $part->setCharset($this->zendMessage->getEncoding());
         $part->setEncoding(Mime::ENCODING_QUOTEDPRINTABLE);
+        $part->setDisposition(Mime::DISPOSITION_INLINE);
         $part->setType($messageType);
         $mimeMessage = new \Zend\Mime\Message();
         $mimeMessage->addPart($part);
--- Mail/Test/Unit/MessageTest.orig.php        2020-04-13 17:35:44.000000000 +0100
+++ Mail/Test/Unit/MessageTest.php     2020-05-01 18:58:47.420000000 +0100
@@ -29,6 +29,7 @@
         $this->assertEquals('quoted-printable', $part->getEncoding());
         $this->assertEquals('utf-8', $part->getCharset());
         $this->assertEquals('body', $part->getContent());
+        $this->assertEquals('inline', $part->getDisposition());
     }

     public function testSetBodyText()
@@ -40,5 +41,6 @@
         $this->assertEquals('quoted-printable', $part->getEncoding());
         $this->assertEquals('utf-8', $part->getCharset());
         $this->assertEquals('body', $part->getContent());
+        $this->assertEquals('inline', $part->getDisposition());
     }
 }

[fredden]

laminas/laminas-mail v2.11.0 includes a fix for this. See https://github.com/laminas/laminas-mail/pull/31#issuecomment-652012322

[MarcusWolschon]

         $zendMessage = Message::fromString($this->message->getRawMessage())->setEncoding('utf-8');

+

• $contentDisposition = $zendMessage->getHeaders()->get('Content-Disposition');
• if ($contentDisposition instanceof Zend\Mail\Header\HeaderInterface) {
• $contentDisposition->setEncoding('ASCII');
• }

Are you setting the encoding of a UTF-8 text to ASCII ?
That sounds like it breaks all L10N and I18N.

[convenient]

Only on the content disposition header @MarcusWolschon

All other headers and values will remain encoded as they are. This will mean that the content disposition header can have a value like inline and not =?utf-8?Q?inline?=

This matches the possible values at https://www.iana.org/assignments/cont-disp/cont-disp.xhtml

Based on this only changing this one header I do not think this will affect localisation or internationalisation.

[befrednguyen]

The same issue on 2.2.11