UTF-8 and ISO-2022-JP decoding fails.
The attached file name character is from the same sender. use a browser-based webmail batch transmission tool such as DeepMail.
From 16:17 on July 14, 2020 (Tuesday) until just before applying the following [Workaround 1] and [2].
Environment at the time of the bug.
Windows 10 Pro Ver.1909 32Bit OS build 18363.1110
Microsoft Office Personal 2019 Version 2008 (build 13127.20508)
See also.
https://answers.microsoft.com/ja-jp/msoffice/forum/all/outlook%e3%81%a7%e3%83%a1%e3%83%bc%e3%83%ab/b...
I got support from Microsoft Technical Support Customer Advocate via chat and found out about the recommended rollback version.
The following is a summary of the workaround in my environment.
[Verification Results 1]
Cumulative Updates for Windows 10
September 8, 2020 - KB4574727 (OS builds 18362.1082 and 18363.1082)
The following Office rollback procedures were found to be invalid in environments where Office is not installed.
[Verification Result 2]
Office 2019 version 2006 (build 13001.20266)
It has been found that there is a problem if the update is installed as follows
Version 2008 (build 13127.20508) NG
Version 2007 (build 13029.20460) NG
Version 2007 (build 13029.20344) NG
Version 2007 (build 13029.20308) NG
Version 2006 (build 13001.20498) NG
Version 2006 (build 13001.20384) NG
Version 2006 (build 13001.20266) NG
Version 2005 (build 12827.20470) OK
[Workaround 1]
Apply Windows 10 cumulative update KB4574727 in Windows Update.
[Workaround 2]
Roll Office back to 2020/6/24 version 2005 (build 12827.20470).
Open (1) Start button > Windows System Tools and right-click on the command prompt.
(2) Open the Start button > Windows System Tools and right-click Command Prompt.
(2)
cd %programfiles%Common FilesMicrosoft Shared\ClickToRun
Drag the above command and when the copied command is pasted, hit enter
(3)
officec2rclient.exe /update user updatetoversion=16.0.12827.20470
Drag the above command and when the copied command is pasted, hit enter
Launch some application, whether it be Word or Excel again, and then click on the button.
Go to File > Account and click "Update Options" and set "Disable Updates".
2020/6/5 Windows Beta Channel version 2006 (build 13001.20002)
It says: "Fixed an issue where Outlook could not parse RFC2231 encoded long file names.
So my guess is that the bug is very likely to have been included in this fix.
For example, even if your mailer is not Thunderbird, you can use
Source of message on 17 September 2020 at 11:49 using Cybozu MailWise 5.4.7
Gmail doesn't mess up the characters.
Content-Type: application/x-zip-compressed; name="Sample PDF.zip"
Content-Disposition: attachment; filename="Sample PDF.zip"
Content-Transfer-Encoding: base64
Characters are garbled in Microsoft Office Personal 2019 version 2009 (build 13231.20262).
Content-Type: application/x-zip-compressed;
name="=?ISO-2022-JP?B?GyRCJTUlcyVXJWsbKEJQREYuemlw?="
Content-Disposition: attachment;
filename*0*=ISO-2022-JP''%1B%24B%255%25s%25W%25k%1B%28BPDF;
filename*1*=%2Ezip
Content-Transfer-Encoding: base64
It's the same email that I left on the server.
Microsoft Office Personal 2019 version 2005 (build 12827.20470) is not garbled.
So, at present, we recommend rolling back to version 2005 (build 12827.20470).
Currently, I think the above Beta Channel build 13001 or later is not good enough.
The Microsoft support chatbot won't solve the problem, and the first operator that came out didn't solve the problem either.
P.F. (Customer Advocate Microsoft Technical Support), who seemed to know more than the first operator who was passed the baton next.
I had him assist me with remote work.
The first thing he did was to roll back to version 2005 (build 12827.20470).
Because of my job, I'm using DeepMail to send out multiple mailers at once.
I receive 5-10 emails (from a certain local government) daily. The phenomenon is similar, though.
What we do know is that the same email to the sender was sent to the sender with a "request to resend individually because the attachment is garbled
If you do, for some reason, even from the same DeepMail is not garbled 100%.
So, I have a hunch that there may be some conditions on the sending side of the phenomenon.
After applying rollback to version 2005 (build 12827.20470), the phenomenon does not occur at all.
If you receive an encrypted email using an email client that cannot correctly decode (decrypt) attachment file names encoded in accordance with the latest RFC2231 standard, such as Outlook 2019, if the attachment file name is long, the attachment file name may be garbled or the sent Email attachments have a ".dat" extension.
This happens because Outlook 2019 does not support RFC2231: 3. Parameter Value Continuations.
https://tools.ietf.org/html/rfc2231#section-3 .
https://docs.microsoft.com/ja-jp/officeupdates/beta-channel
https://docs.microsoft.com/ja-jp/officeupdates/current-channel-preview
An attachment encoded in RFC 2231 format has the following format
Content-Transfer-Encoding: Base-64
Content-Type: image/jpeg
Content-Disposition: attachment;
filename*0=test1;
filename*1=.jpeg
This is the data encoded from "test1.jpeg".
Content-Transfer-Encoding: Base-64
Content-Type: image/jpeg
Content-Disposition: attachment;
filename*=iso-2022-jp''%24B%24%22%24%24%24%24%26%24%24%28%24%2A%28B%2Etxt
This is the data encoded from "AIUEO.txt".
Countermeasure on the sending side:.
In a Thunderbird 1.5 environment, the
http://kb.mozillazine.org/Attachments_renamed
In other environments, the
Encode filenames using the RFC2047 encoding method, which uses base64 UTF-8 encoding for all file names.
