Mewの転送(f)で，転送メール全体を添付ファイルとせず，転送メールの本文を引用する形
422 views
Skip to first unread message
TECH-I松元隆二
Jun 9, 2021, 2:00:52 AM6/9/21
to Mew ユーザ
松元です．
(ちょっと困った事があり)以下の転送の動作はMewでは実現できないか調べています．
Mewでメールを転送(f)すると，新規メール作成モードになり，転送メール全体
を添付ファイル(Message/Rfc822)とした形になります．
------------------------------ attachments ------------------------------
Multipart/Mixed 1544/
1 Text/Plain(guess) *Cover.txt
2 Message/Rfc822 *1
3 .
--------0-1-2-3-4-5-6-7-8-9----------------------------------------------
この方式ではなくThunderbirdなどで転送した時と同じ形，具体的には，
転送メールの本文を「>」で引用し，転送メールに添付されていた画像や
MS-Wordなどは，新規メールの添付ファイルとする事はできないでしょうか．
具体的には以下のような感じです．
-------- Forwarded Message --------
From: mats...@example.ac.jp
Subject: 中庭
Date: Wed, 9 Jun 2021 14:23:52 +0900
>
> アジサイが咲いてたよ！
>
------------------------------ attachments ------------------------------
Multipart/Mixed 1544/
1 Text/Plain(guess) *Cover.txt
B 2 Image/Jpeg アジサイ.jpg
3 .
--------0-1-2-3-4-5-6-7-8-9----------------------------------------------
このような形での引用および転送はMewではできないでしょうか?
検索した限りこの引用および転送はできなさそうですが，可能でしたら今後のMewの
新版で追加していただけないでしょうか．
理由:
Mewの転送方法は転送メールの本文が正常に読めない環境が多いため。
職場(大学)で教員から学生に対してメールを転送したがメールの
本文が読めないという連絡があり調査したところ，
転送の元メールが以下のようになっていました．
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 8bit
Mewで上記メールを転送すると， 転送したメールのヘッダは
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: base64 (modified by Mew)
となり，Gmailで本文が文字化けして表示されないという報告はすでにされてい
ます．(2020/11/11 19:51:44に報告されています)
この現象は以下で確認しています．
Gmail Web版, Androidアプリ版
OutlookのiOSアプリ版, Androidアプリ版
AppleMailのiOSアプリ版, MacOS版
ヘッダを次のように書き換えると
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: base64
おおむね改善しますが，以下の一つは
AppleMailのMacOS版
MacOS 11.4, メール バージョン14.0(3654.100.0.2.22)
はまだダメで，「format=flowed」を削らないとダメのようです．以下の
ように書き換えると本文が表示できます．(なおちょっと古いMacOSの
AppleMailは正常らしいです．)
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
というように，どうも転送メール全体を添付ファイルとすると読めない環境が
多くて，小手先で改善したとしても別のアプリがダメだったりのようです．多
くの環境で読んでもらうには，Thunderbirdのように本文を「>」で引用する形
で引用した方が良いのではと考えています．
村田 隆
Jun 9, 2021, 2:56:07 AM6/9/21
to mew...@googlegroups.com
村田です。
> 転送メールの本文を「>」で引用し，転送メールに添付されていた画像や
> MS-Wordなどは，新規メールの添付ファイルとする事はできないでしょうか．
E (reedit)でドラフトを用意し、Subject に Fw: を付けたり、本文に C-x r t で
"> " を付けて、転送メールっぽくする、という方法もあります。
> 転送メールの本文を「>」で引用し，転送メールに添付されていた画像や
> MS-Wordなどは，新規メールの添付ファイルとする事はできないでしょうか．
"> " を付けて、転送メールっぽくする、という方法もあります。
TECH-I松元隆二
Jun 10, 2021, 2:47:00 AM6/10/21
to Mew ユーザ
松元です．
村田樣:
> E (reedit)でドラフトを用意し、Subject に Fw: を付けたり、本文に C-x r t で
> "> " を付けて、転送メールっぽくする、という方法もあります。
ありがとうございます．いろいろ試してみましたが，おおむねうまくいようです．
ほぼ同じ内容の方法をもうひと方より教えてもらいましたが，Webで見えない
ため引用は差し控えます．ありがとうございます。
ただ複雑なMultipart構成の場合，残念な事にうまくいかない例が多いようです．
いろいろ条件を覚える必要があるため，お手軽に転送といかないようです．
可能ならMewの機能でThunderbirdの転送と同様の方法が提供されうといいな
と思ったところです(^_^;
-----------------
以下参考情報．
メールを「E」で再編集すると次のヘッダがそのままになるので，手作業で
消した方が無難．
「ARC-Seal,ARC-Message-Signature,ARC-Authentication-Results,Thread-Topic,
Thread-Index,Accept-Language, User-Agent」
-----------------
*本文引用成功事例:
メールの文章部分が編集可能になり，「> 」などの挿入修正などが可能．Subject
の修正が可能になる事例．以下成功を確認したMultipart構成です．
-Plainテキスト(非Multipart)
本文Header
Content-Type: text/plain;
- Plainテキスト + 添付ファイル有り
本文Header
Content-Type: multipart/mixed
MultiPartHeader
Content-Type: text/plain
Content-Type: image/jpeg
- Plainテキスト + HTMLテキスト(Alternative) + 添付ファイル無し
本文Header
Content-Type: multipart/alternative; ...
MultiPartHeader
Content-Type: text/plain
Content-Type: text/html
※ メールの文章の編集可能になり「> 」などの挿入修正などが可能になるが，
HTMLパートは未編集になるため，HTMLは(d)で消す方が良い．
-----------------
*本文引用失敗事例:
メールの文章部分が編集出来ない事を確認したMultipart構成です．
- Plainテキスト + HTMLテキスト(Alternative) + 添付ファイル有り
本文Header
Content-Type: multipart/mixed
MultiPartHeader
Content-Type: multipart/alternative
(入れ子) Content-Type: text/plain
(入れ子) Content-Type: text/html
Content-Type: image/jpeg
「E」で以下のように再編集のメール全体が添付ファイルになる．メールの文
章部分の編集は不可．新たな文章挿入は可能．
-- Emacs の画面引用 --
Subject: Thunderbird+HTMLメール+添付ファイルあり。
From: matsumoto/Mew <mats...@example.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
X-Mailer: Mew version 6.8 on Emacs 24.3
----
(ここに新たな文章挿入可能)
------------------------------ attachments ------------------------------
Multipart/Mixed 1584/
1 Text/Plain(guess) *Cover.txt
2 Multipart/Mixed e/
B 2.1 Text/Plain(guess) *sx
B 2.2 Text/Html(guess) *de.html
2.3 .
B 3 Image/Jpeg アジサイ.jpg
4 .
--------0-1-2-3-4-5-6-7-8-9----------------------------------------------
-- Emacs の画面引用終わり --
上記で「2 Multipart/Mixe」を「T」で以下の修正をした方がよい．
x 2 Multipart/Mixed
o 2 Multipart/alternative
上記の形での転送は多くのメールリーダーで閲覧できたが，Outlook(iOSアプリ
版, Androidアプリ版)では転送したPlainテキスト/HTMLテキストが添付ファイ
ル扱いになる．そして添付ファイルを開こうとする場合，HTMLは正常表示でき
たが，Plainテキストは文字化けして読めなかった．(これはまぁよくある話で
Mewの問題ではない．)
「f」での転送とは異なり「Message/Rfc822」にはならず個々のファイルが
添付ファイルとなる．
「f」での転送時は元メールがContent-Transfer-Encoding:8bitだった場合は
base64に修正になるが，「E」の場合は 8bitのまま温存される．
というような感じです．
以上です．
2021年6月9日水曜日 15:56:07 UTC+9 村田 隆:
村田 隆
Jun 10, 2021, 5:45:32 AM6/10/21
to mew...@googlegroups.com
村田です。言うだけで実験とかしていません。すみません。
> メールを「E」で再編集すると次のヘッダがそのままになるので，手作業で
> 消した方が無難．
>
> 「ARC-Seal,ARC-Message-Signature,ARC-Authentication-Results,Thread-Topic,
> Thread-Index,Accept-Language, User-Agent」
変数 mew-field-delete-for-reediting に追加しておけば良さそうです。
> 「E」で以下のように再編集のメール全体が添付ファイルになる．メールの文
> 章部分の編集は不可．新たな文章挿入は可能．
> B 2.1 Text/Plain(guess) *sx
この行で T RET すると、* が取れて f で編集出来ませんか？
> メールを「E」で再編集すると次のヘッダがそのままになるので，手作業で
> 消した方が無難．
>
> 「ARC-Seal,ARC-Message-Signature,ARC-Authentication-Results,Thread-Topic,
> Thread-Index,Accept-Language, User-Agent」
> 「E」で以下のように再編集のメール全体が添付ファイルになる．メールの文
> 章部分の編集は不可．新たな文章挿入は可能．
この行で T RET すると、* が取れて f で編集出来ませんか？
Hideyuki SHIRAI
Jun 10, 2021, 7:16:29 PM6/10/21
to mew...@googlegroups.com
こんにちは、白井です。
一点だけ。。。
From: TECH-I松元隆二 <mats...@tech-i.kyutech.ac.jp> さん曰く
Subject: Re: [mew-ja] Mewの転送(f)で，転送メール全体を添付ファイルとせず，転送メールの本文を引用する形
Message-ID: <4431f81b-028a-4112...@googlegroups.com>
Date: Wed, 9 Jun 2021 23:47:00 -0700 (PDT)
> 「f」での転送時は元メールがContent-Transfer-Encoding:8bitだった場合は
> base64に修正になるが，「E」の場合は 8bitのまま温存される．
(setq mew-use-8bit t)
しておくと、'f' でも 8bit のままになるかようです。
# もう、8bitスルーじゃないところないよな。
一点だけ。。。
From: TECH-I松元隆二 <mats...@tech-i.kyutech.ac.jp> さん曰く
Subject: Re: [mew-ja] Mewの転送(f)で，転送メール全体を添付ファイルとせず，転送メールの本文を引用する形
Message-ID: <4431f81b-028a-4112...@googlegroups.com>
Date: Wed, 9 Jun 2021 23:47:00 -0700 (PDT)
> 「f」での転送時は元メールがContent-Transfer-Encoding:8bitだった場合は
> base64に修正になるが，「E」の場合は 8bitのまま温存される．
しておくと、'f' でも 8bit のままになるかようです。
# もう、8bitスルーじゃないところないよな。
TECH-I松元隆二
Jun 11, 2021, 5:46:15 AM6/11/21
to Mew ユーザ
白石樣:
> (setq mew-use-8bit t)
情報ありがとうございます．確認してみたところ，本文を閲覧可能で
あるという点だけでみると，すべての環境で閲覧できるようになりました．
ただし，一部環境で添付ファイルのファイル名が化けるという症状が
ありました．まぁこれは本文が読めない状況に比べると誤差．
# > もう、8bitスルーじゃないところないよな。
# お手軽対策するなら，これがいちばん楽のようです．ただ思わぬ
# ところで副作用がでてなければいいのですが．．
----
以下テストのログです．今回からはサンプルメールとして
Outlook2019(Win10)を追加しています．
テストに使った「転送ファイル」
1. Thunderbird + Plain(UTF-8) + 添付ファイル無し
2. Thunderbird + Plain(UTF-8) + 添付ファイル有り
3. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル無し
4. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル有り
5. Outlook2019 + Plain(JIS) + 添付ファイル無し
6. Outlook2019 + Plain(JIS) + HTML + 添付ファイル無し
7. Outlook2019 + Plain(JIS) + 添付ファイル有り
8. Outlook2019 + Plain(JIS) + HTML + 添付ファイル有り
確認したクライアント
Outlook/(Android版, iOS版, Web版)
gmail/(Web版, Android版)
AppleMail/iOS版
AppleMail/MacOS(11.4, メール バージョン14.0(3654.100.0.2.22))
Thunderbird(Win10)
*テスト環境
「f」 コマンドで転送．
Mewのコメント(Content-Transfer-Encoding)などは標準のまま．
** ~/.mew の設定: (setq mew-use-8bit nil)
- 転送ファイル(1,2,3,4)
表示NG: Outlook/(Android,iOS)版, gmail(Web,Andrid), AppleMail/iOS版, AppleMail/MacOS
- 転送ファイル(5,6,7,8)
すべて問題なし
** ~/.mew の設定: (setq mew-use-8bit t)
- 転送ファイル(1,3,5,6,7,8)
すべて問題なし
- 転送ファイル(2,4)
表示NG: Outlook/(Android,iOS)版(本文は読めるが添付ファイルのファイル名が文字化け)
以上です．
2021年6月11日金曜日 8:16:29 UTC+9 Hideyuki SHIRAI (白井秀行):
TECH-I松元隆二
Jun 11, 2021, 6:05:04 AM6/11/21
to Mew ユーザ
田村様：
>変数 mew-field-delete-for-reediting に追加しておけば良さそうです。ありがとうございます。 ~/mew に以下のように記載したら「E」で再編集時に
不要ヘッダがなくなりました(^_^)
-----------------------------------------------------
; ~/.mew に記載ください。~/.emacsに書くとエラーになります。
(setq mew-field-delete-for-reediting (append mew-field-delete-for-reediting '(
"ARC-Seal:"
"ARC-Message-Signature:"
"ARC-Authentication-Results:"
"Thread-Topic:"
"Thread-Index:"
"Accept-Language:"
"User-Agent:"
)))
------------------------------------------------------
> この行で T RET すると、* が取れて f で編集出来ませんか？
なるほど。すでに添付された状態になっているファイルを再度
編集する方法を知りませんでした。情報ありがとうございます。
この方法で今回試した全てのMultpartの組み合わせを「E」対応
できそうです。
2021年6月10日木曜日 18:45:32 UTC+9 村田 隆:
村田 隆
Jun 11, 2021, 12:44:05 PM6/11/21
to mew...@googlegroups.com
村田です。使えるようになったみたいで、良かったです。
> 白石樣:
>> (setq mew-use-8bit t)
これって、去年話題にあった以下の件の回避策でもあるんですね。
｜転送メールの GMail での表示
https://groups.google.com/g/mew-ja/c/QjtHEM98s3I
> ** ~/.mew の設定: (setq mew-use-8bit nil)
> - 転送ファイル(1,2,3,4)
> 表示NG: Outlook/(Android,iOS)版, gmail(Web,Andrid), AppleMail/iOS版,
> AppleMail/MacOS
これらのNGが CTE のコメントのせい、ということであれば、Mew 側で CTE のコメント
を止める、必要なら X-Mew-* 等で再エンコードした旨を記述する、という方向で対応
した方がいいのでは？と思います。開発側への要望、ということで。
> 白石樣:
>> (setq mew-use-8bit t)
これって、去年話題にあった以下の件の回避策でもあるんですね。
｜転送メールの GMail での表示
https://groups.google.com/g/mew-ja/c/QjtHEM98s3I
> ** ~/.mew の設定: (setq mew-use-8bit nil)
> - 転送ファイル(1,2,3,4)
> 表示NG: Outlook/(Android,iOS)版, gmail(Web,Andrid), AppleMail/iOS版,
> AppleMail/MacOS
を止める、必要なら X-Mew-* 等で再エンコードした旨を記述する、という方向で対応
した方がいいのでは？と思います。開発側への要望、ということで。
村田 隆
Jun 11, 2021, 1:18:18 PM6/11/21
to mew...@googlegroups.com
>> 白石樣:
>>> (setq mew-use-8bit t)
>
> これって、去年話題にあった以下の件の回避策でもあるんですね。
>
> ｜転送メールの GMail での表示
> https://groups.google.com/g/mew-ja/c/QjtHEM98s3I
2015年にも同じ話題がありました。
>>> (setq mew-use-8bit t)
>
> これって、去年話題にあった以下の件の回避策でもあるんですね。
>
> ｜転送メールの GMail での表示
> https://groups.google.com/g/mew-ja/c/QjtHEM98s3I
｜転送時の (modified by Mew) について
https://groups.google.com/g/mew-ja/c/Od4_vErcAAs
TECH-I松元隆二
Jun 14, 2021, 12:48:09 AM6/14/21
to Mew ユーザ
一点、補足します。
>** ~/.mew の設定: (setq mew-use-8bit t)
>- 転送ファイル(2,4)
> 表示NG: Outlook/(Android,iOS)版(本文は読めるが添付ファイルのファイル名が文字化け)
この8bitをtにしても転送ファイルに含まれる添付ファイルのファイル名が
文字化けする問題ですが、Mewに限った問題ではない事がわかりましたの
で、補足しておきます。
Thunderbird(78.11.0/win10)の設定を精査してたところ、Thunderbirdのメール転送方式は
２種類選べて「メール本文に含める」と「ファイルとして添付」
が選べました。前者がDefaultで、後者がMewと同じ挙動になります。
この設定変更後、Thunderbirdで転送してもやはりファイル名が化けてました。
補足：ご存じでしたら、メールの転送時に「ファイルとして添付」が可能な
ソフトが他にあったら試してみますので、教えてください。現在でもメンテが
行われているフリーソフト限定で(^_^;
2021年6月11日金曜日 18:46:15 UTC+9 TECH-I松元隆二:
Takahiro Kambe
Jun 14, 2021, 1:00:01 AM6/14/21
to mew...@googlegroups.com
In message <96d0ca1f-0222-4417...@googlegroups.com>
on Sun, 13 Jun 2021 21:48:08 -0700 (PDT),
みたことないので、厳密には未確認ですが。)
https://sylpheed.sraoss.jp/
https://claws-mail.org
--
神戸 隆博 (かんべ たかひろ) at 仕事場
on Sun, 13 Jun 2021 21:48:08 -0700 (PDT),
TECH-I松元隆二 <mats...@tech-i.kyutech.ac.jp> wrote:
> 補足：ご存じでしたら、メールの転送時に「ファイルとして添付」が可能な
> ソフトが他にあったら試してみますので、教えてください。現在でもメンテが
> 行われているフリーソフト限定で(^_^;
Sylpheedと、その派生のclausw-mail辺りでしょうか。(claws-mailは動かして
> 補足：ご存じでしたら、メールの転送時に「ファイルとして添付」が可能な
> ソフトが他にあったら試してみますので、教えてください。現在でもメンテが
> 行われているフリーソフト限定で(^_^;
みたことないので、厳密には未確認ですが。)
https://sylpheed.sraoss.jp/
https://claws-mail.org
--
神戸 隆博 (かんべ たかひろ) at 仕事場
村田 隆
Jun 16, 2021, 9:11:48 AM6/16/21
to mew...@googlegroups.com
村田です。長いです。ちょっとだけ、テストもしてみました。
> この8bitをtにしても転送ファイルに含まれる添付ファイルのファイル名が
> 文字化けする問題ですが、Mewに限った問題ではない事がわかりましたの
> で、補足しておきます。
一昔前、添付ファイルのファイル名をRFC2231に従ってエンコードしていた Mew や、
Thunderbird からのメールを Outlook 等で受信すると文字化けする、という問題が
ありましたが、2010年頃でも解消されていたと思います。ただ、その頃でも Outlook
から送信するメールは、B-encoding のままでした。
RFC2231
Content-Disposition: inline; filename*=iso-2022-jp''...
B-encoding
Content-Disposition: attachment; filename="=?iso-2022-jp?B?...?="
で、「転送メールの添付ファイル」のファイル名だけ Outlook で文字化けする、
という現象はどうやって起きるんだろう、と考えると、おそらく以下のような理由が
考えられると思います。
・Mew, Thunderbird での添付ファイルは RFC2231
・Outlook での添付ファイルは B-encoding (以前のままなら)
これらを Mew で転送すると、
・Mew, Thunderbird 作成メールは、ファイル名が RFC2231 のまま添付される
・Outlook 作成メールも、ファイル名が B-encoding のまま添付される (ここはテスト)
となり、Mew, Thuderbird 作成メールの転送で添付ファイルが化けるのであれば、
Outlook は「通常の添付ファイルは RFC2231 (の受信)には対応したが、
転送(添付)メールの添付ファイルは RFC2231 に対応していないのでは？」という
ことかと考えています。ずいぶん仮定が入っていますが…。
> この8bitをtにしても転送ファイルに含まれる添付ファイルのファイル名が
> 文字化けする問題ですが、Mewに限った問題ではない事がわかりましたの
> で、補足しておきます。
Thunderbird からのメールを Outlook 等で受信すると文字化けする、という問題が
ありましたが、2010年頃でも解消されていたと思います。ただ、その頃でも Outlook
から送信するメールは、B-encoding のままでした。
RFC2231
Content-Disposition: inline; filename*=iso-2022-jp''...
B-encoding
Content-Disposition: attachment; filename="=?iso-2022-jp?B?...?="
で、「転送メールの添付ファイル」のファイル名だけ Outlook で文字化けする、
という現象はどうやって起きるんだろう、と考えると、おそらく以下のような理由が
考えられると思います。
・Mew, Thunderbird での添付ファイルは RFC2231
・Outlook での添付ファイルは B-encoding (以前のままなら)
これらを Mew で転送すると、
・Mew, Thunderbird 作成メールは、ファイル名が RFC2231 のまま添付される
・Outlook 作成メールも、ファイル名が B-encoding のまま添付される (ここはテスト)
となり、Mew, Thuderbird 作成メールの転送で添付ファイルが化けるのであれば、
Outlook は「通常の添付ファイルは RFC2231 (の受信)には対応したが、
転送(添付)メールの添付ファイルは RFC2231 に対応していないのでは？」という
ことかと考えています。ずいぶん仮定が入っていますが…。
matsumoto/Mew
Jun 16, 2021, 8:45:37 PM6/16/21
to mew...@googlegroups.com
松元です．
村田 隆樣:
Date: Wed, 16 Jun 2021 22:11:10 +0900 (JST)
> 村田です。長いです。ちょっとだけ、テストもしてみました。
>
>> この8bitをtにしても転送ファイルに含まれる添付ファイルのファイル名が
>> 文字化けする問題ですが、Mewに限った問題ではない事がわかりましたの
>> で、補足しておきます。
>
> 一昔前、添付ファイルのファイル名をRFC2231に従ってエンコードしていた Mew や、
> Thunderbird からのメールを Outlook 等で受信すると文字化けする、という問題が
> ありましたが、2010年頃でも解消されていたと思います。ただ、その頃でも Outlook
> から送信するメールは、B-encoding のままでした。
ありがとうございます．調べた限り最後に引用したように，まだB-encodingが
残ってるようです．これを色々なメールリーダーで転送したらどうなるか調査
してみたいと思います．
神戸樣:
Date: Mon, 14 Jun 2021 13:59:07 +0900 (JST)
----------
以下は「調査途中」ですが，転送の対象となる元のメールを調査した資料です．
これから色々なメールリーダーで転送したらどうなるか調べてみたいと思いま
す．
調査途中ですがOutlook(Android/iOS版)はMicrosoftにバグレポート出そうかと
思ってます．
-----------------------------------------------------------
*転送の対象となる元のメールの作成環境
補足:
Ref:
https://www.atmarkit.co.jp/ait/articles/0104/10/news002.html
https://www.mew.org/~kazu/doc/newsletter/3.html
Content-Transfer-Encoding: [base64|quoted-printable|7bit|8bit]
Subject: 「エンコード形式」
Content-Type, name: 「エンコード形式」
-> Content-Typeのparameter「name」のエンコード形式
Content-Disposition, filename: 「エンコード形式」
-> Content-Dispositionのparameter「filename」のエンコード形式
ファイルを保存した時の名前．
エンコード形式: [UTF-8|iso-2022-jp], [B|Q|RFC2231]
B: Base64形式 (=?charset?B?.....?=)
Q: Quoted Printable形式 (=?charset?Q?=16進数...?=)
RFC2231: RFC2231形式(filename*=charset''%%16進数) / 英語の場合は「*」不要
base64の幅: 何文字で改行しているか．
ここから．
1. Thunderbird + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
2. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
3. Thunderbird + Plain(JIS) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
補足:
ThunderbirdはDefaultはUTF-8だがJISに変更する方法
https://www.cc.yamaguchi-u.ac.jp/guides/mail/setting/wizardwithssl/thunderbird78.phtml
実際に試すと本文はJISになるがSubjectや添付ファイル名はUTF-8.
4. Thunderbird + Plain(JIS) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
5. Outlook2019 + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 76
本文:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, B
6. Outlook2019 + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, Q <- なんでこれだけ?
base64の幅: 76
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, B
7. Outlook2019 + Plain(JIS) + 添付ファイル
Subject: iso-2022-jp, B
base64の幅: 76
本文
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: iso-2022-jp, B
Content-Disposition, filename: iso-2022-jp, B
8. Outlook2019 + Plain(JIS) + HTML + 添付ファイル
Subject: iso-2022-jp, B
base64の幅: 76
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: iso-2022-jp, B
Content-Disposition, filename: iso-2022-jp, B
9. Sylpheed + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 76
本文:
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, RFC2231
Content-Disposition, filename: ISO-2022-JP, RFC2231
10. Sylpheed + Plain(JIS) + 添付ファイル(ファイル名BASE64エンコード)
Subject: ISO-2022-JP, B
base64の幅: 76
本文:
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, B
補足:
ファイル名BASE64エンコード指定は
設定 -> 全般の設定 -> 送信 -> エンコーディング
-> 「RFC2231」から「MIMEヘッダ」に変更
11. Rainloop + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: utf-8, B
Content-Disposition, filename: utf-8, B
12. DeepMail + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, RFC2231
Content-Type: image/pjpeg (属性が変わってる: jpeg -> pjpeg)
* メール転送方式(以下すべてMessage/Rfc822で転送)
(以下で調査予定)
a. 転送:Thunderbird + Plain(JIS)
b. 転送:Thunderbird + Plain(UTF-8)
c. 転送:Sylpheed + Plain(JIS)
d. 転送:DeepMail + Plain(JIS)
e. 転送:Mew + Plain(JIS)
f. 転送:Mew + Plain(JIS) + Mewコメント除去
g. 転送:Mew + Plain(JIS) + 8bit
h. 転送:Mew + Plain(UTF-8) + 8bit
Mew注釈
8bit: (setq mew-use-8bit t)
Mewコメント除去: (setq mew-field-comment "")
Thunderbird注釈
Thunderbirdはメール転送のDefaultは「メール本文に含める」だが「ファイルとして添付」
に変更した．
以上です．
村田 隆樣:
Date: Wed, 16 Jun 2021 22:11:10 +0900 (JST)
> 村田です。長いです。ちょっとだけ、テストもしてみました。
>
>> この8bitをtにしても転送ファイルに含まれる添付ファイルのファイル名が
>> 文字化けする問題ですが、Mewに限った問題ではない事がわかりましたの
>> で、補足しておきます。
>
> 一昔前、添付ファイルのファイル名をRFC2231に従ってエンコードしていた Mew や、
> Thunderbird からのメールを Outlook 等で受信すると文字化けする、という問題が
> ありましたが、2010年頃でも解消されていたと思います。ただ、その頃でも Outlook
> から送信するメールは、B-encoding のままでした。
残ってるようです．これを色々なメールリーダーで転送したらどうなるか調査
してみたいと思います．
神戸樣:
Date: Mon, 14 Jun 2021 13:59:07 +0900 (JST)
>> 補足：ご存じでしたら、メールの転送時に「ファイルとして添付」が可能な
> Sylpheedと、その派生のclausw-mail辺りでしょうか。(claws-mailは動かして
> みたことないので、厳密には未確認ですが。)
情報ありがとうございます．Sylpheedで試してみたいと思います．
> みたことないので、厳密には未確認ですが。)
----------
以下は「調査途中」ですが，転送の対象となる元のメールを調査した資料です．
これから色々なメールリーダーで転送したらどうなるか調べてみたいと思いま
す．
調査途中ですがOutlook(Android/iOS版)はMicrosoftにバグレポート出そうかと
思ってます．
-----------------------------------------------------------
*転送の対象となる元のメールの作成環境
補足:
Ref:
https://www.atmarkit.co.jp/ait/articles/0104/10/news002.html
https://www.mew.org/~kazu/doc/newsletter/3.html
Content-Transfer-Encoding: [base64|quoted-printable|7bit|8bit]
Subject: 「エンコード形式」
Content-Type, name: 「エンコード形式」
-> Content-Typeのparameter「name」のエンコード形式
Content-Disposition, filename: 「エンコード形式」
-> Content-Dispositionのparameter「filename」のエンコード形式
ファイルを保存した時の名前．
エンコード形式: [UTF-8|iso-2022-jp], [B|Q|RFC2231]
B: Base64形式 (=?charset?B?.....?=)
Q: Quoted Printable形式 (=?charset?Q?=16進数...?=)
RFC2231: RFC2231形式(filename*=charset''%%16進数) / 英語の場合は「*」不要
base64の幅: 何文字で改行しているか．
ここから．
1. Thunderbird + Plain(UTF-8) + 添付ファイル
base64の幅: 72
本文:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
2. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付HTML(Content-Type: multipart/alternative)
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
3. Thunderbird + Plain(JIS) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
補足:
ThunderbirdはDefaultはUTF-8だがJISに変更する方法
https://www.cc.yamaguchi-u.ac.jp/guides/mail/setting/wizardwithssl/thunderbird78.phtml
実際に試すと本文はJISになるがSubjectや添付ファイル名はUTF-8.
4. Thunderbird + Plain(JIS) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
5. Outlook2019 + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 76
本文:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, B
6. Outlook2019 + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, Q <- なんでこれだけ?
base64の幅: 76
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, B
7. Outlook2019 + Plain(JIS) + 添付ファイル
base64の幅: 76
本文
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: iso-2022-jp, B
Content-Disposition, filename: iso-2022-jp, B
8. Outlook2019 + Plain(JIS) + HTML + 添付ファイル
base64の幅: 76
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: iso-2022-jp, B
Content-Disposition, filename: iso-2022-jp, B
9. Sylpheed + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 76
本文:
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, RFC2231
Content-Disposition, filename: ISO-2022-JP, RFC2231
10. Sylpheed + Plain(JIS) + 添付ファイル(ファイル名BASE64エンコード)
Subject: ISO-2022-JP, B
base64の幅: 76
本文:
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, B
補足:
ファイル名BASE64エンコード指定は
設定 -> 全般の設定 -> 送信 -> エンコーディング
-> 「RFC2231」から「MIMEヘッダ」に変更
11. Rainloop + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: utf-8, B
Content-Disposition, filename: utf-8, B
12. DeepMail + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, RFC2231
Content-Type: image/pjpeg (属性が変わってる: jpeg -> pjpeg)
* メール転送方式(以下すべてMessage/Rfc822で転送)
(以下で調査予定)
a. 転送:Thunderbird + Plain(JIS)
b. 転送:Thunderbird + Plain(UTF-8)
c. 転送:Sylpheed + Plain(JIS)
d. 転送:DeepMail + Plain(JIS)
e. 転送:Mew + Plain(JIS)
f. 転送:Mew + Plain(JIS) + Mewコメント除去
g. 転送:Mew + Plain(JIS) + 8bit
h. 転送:Mew + Plain(UTF-8) + 8bit
Mew注釈
8bit: (setq mew-use-8bit t)
Mewコメント除去: (setq mew-field-comment "")
Thunderbird注釈
Thunderbirdはメール転送のDefaultは「メール本文に含める」だが「ファイルとして添付」
に変更した．
以上です．
matsumoto/Mew
Jun 25, 2021, 1:13:03 AM6/25/21
to mew...@googlegroups.com
松元です．
各種メールリーダーが8bitで作成したメールをMewがMessage/Rfc822形式で転送
すると，転送したメールの本文が化ける問題(BASE64のdecodeに失敗する)です
が，時間が開いた時に調査してたのですが，だいたいまとまったので，まとめ
て報告しておきます．
BUGを誘発するメールリーダー
gmail(Web, Android)
Outlook(Android, iOS)
AppleMail(iOS, MacOSX)
これについてはコメントを除去する命令を
~/.mew
(setq mew-field-comment "")
を記載すると概ね改善します．ですが，以下のメールリーダまだダメです．
AppleMail(iOS, MacOSX)
上記 ~/.mewの設定では最後に余白がはいります．この余白を除去すると改善し
ます．
初期状態
"Content-Transfer-Encoding: base64 " (最後に空白あり)
すべての環境で改善(ソースファイルを直接書き換え)
"Content-Transfer-Encoding: base64" (最後に空白無し)
最後の余白を取り除くには~/.mewへの加筆では難しくMewのソースコードの修正
が必要です．
Mew開発者の皆様:
可能でしたら 次期リリースでは ~/.mew の記述のみで最後の空白を取り除くの
を対応可能にしていただけないでしょうか．もしくは書き換えたという事を別
のヘッダ「X-ホゲホゲ」に記述するなど．(ソースコードの差し替えは可能なら
職場への周知としては使いたくないので．)
よろしくお願いします．
補足: 別解ですが，8bitスルーにするという方法についても教えていただきま
した．
~/.mew
(setq mew-use-8bit t)
この設定する事により，8bitスルーになり，Mewが引用メールを修正しなくなる
という副作用による，改善策です．
補足2: 最初の私のメール2021/6/9で「format=flowed」が誘発するBUGの件につ
いて記載していましたが，きちんと記録してなかったので，よくわからないの
ですが再現しなくなりました．
------------------------------------------------------------------
次に，転送したメール(Message/RFC822)の本文は読めるが，転送ファイル内に
(入れ子状態で)添付されている(日本語の)ファイル名が化ける問題です．
(※メールリーダーの組み合わせ数が多すぎて，限定的にしか調査してません．
調査が漏れてたらすいません．)
以下のメールリーダーで閲覧するとファイル名が文字化けします．
文字化けA. Outlook(iOS, Android): ファイル名が全部化ける
文字化けB. AppleMail(iOS): ファイル名の後半が化ける．
この件，文字化けAとBでは原因が違いました．
「文字化けA」についてはヒントを教えていただきましたが，ご指摘の通り，エ
ンコーディングの問題で，引用したメールの(入れ子状態の)ファイル名が
RFC2231だと文字化けするようです．具体的にはContent-Dispositionの
parameter「filename」のエンコードがRFC2231だと文字化けします．BASE64だ
と化けません．
注意: 入れ子状態の場合のみです．普通に添付されていた場合はRFC2231のファ
イル名は解釈できます．
なので，引用元のメールのContent-Dispositionのparameter「filename」のエ
ンコードがBASE64の場合は，ファイル名が文字化けしません．
(新規に作成する添付ファイルの)
ファイル名がRFC2231のメールリーダ
Mew
Thunderbird
Sylpheed(デフォルト設定)
DeepMail(Webメール/有償ソフト/職場で提供されてる)
ファイル名がBASE64のメールリーダ
Outlook2019
Rainloop
Sylpheed(オプションで変更可能),
となっています．ですが，いろいろな組み合わせで確認してみると，ファイル
名がRFC2231のメールを引用して転送してもファイル名が文字化けしない場合が
あります．
引用に用いるメールリーダーですが，Message/Rfc822で引用できるメールリー
ダーはあまりないのですが，以下で確認しました．
Thunderbird 78.11.0
Sylpheed 3.7.0(JIS)
DeepMail (JIS/Webメール/有償ソフト/職場で提供されてる)
Mew6.8
このうち，Sylpheed とDeepMailだと引用して転送してもファイル名が文字化け
しません．
差分比較(diff)などで調査したところ，Sylpheed とDeepMailは引用したメール
の(入れ子状態の)ファイル名をRFC2231からBASE64に修正していました．それで
ファイル名が文字化けしなかったようです．
ここで注意点ですが，Sylpheed とDeepMailは平時はファイル名をRFC2231にし
ます．ですが，引用したメールの(入れ子状態の)添付ファイルのファイル名は
RFC2231からBASE64に書き換えます．何らかのバグ対策をおこなっているようで
す．
補足: RFC822で引用したときに，どのような加工が行われるかですが，おそら
くThunderbirdは内容を一切変更しません．Mewは8bitをbase64などに加工する
場合があります．Sylpheed とDeepMailは色々書き換えます．(詳細省略．)
次に，「文字化けB」のファイル名の途中から文字化けする問題です．これにつ
いてですが，引用でなくても発生します．普通に添付されていても長いと文字
化けします．
Content-Dispositionのparameter「filename」が長い時は複数行にする事がで
きますが，複数行になった場合のみ文字化けするようです．ですが，Mewは文字
化けしないので不思議に思い調べたところMewはfilenameが長くなっても改行し
ないようです．この文字化けの件についてはこちらにまとめてます．
Ref: https://qiita.com/qiitamatumoto/items/40cf965a5ef1bb2dd1a0
電子メール添付の日本語ファイル名の名前の後半が化ける
(RFC2231形式の長いファイル名)
以上です．
---
補足資料．内容が重なりますが，調査の全データ．雑多なメモ書きなので，
誤記などあると思います．
*転送の対象となる元のメールの作成環境
補足:
Ref:
https://www.atmarkit.co.jp/ait/articles/0104/10/news002.html
https://www.mew.org/~kazu/doc/newsletter/3.html
http://www.emaillab.org/essay/japanese-filename.html#rfc2231
Content-Transfer-Encoding: [base64|quoted-printable|7bit|8bit]
Subject: 「エンコード形式」
Content-Type, name: 「エンコード形式」
-> Content-Typeのparameter「name」のエンコード形式
Content-Disposition, filename: 「エンコード形式」
-> Content-Dispositionのparameter「filename」のエンコード形式
ファイルを保存した時の名前．
-> Mewのみ画像ファイルを添付すると「inline」属性になる．それ以外は「attachment」
エンコード形式: [UTF-8|iso-2022-jp], [B|Q|RFC2231]
B: Base64形式 (=?charset?B?.....?=)
複数行の場合は行頭に空白入れる．
Subjectの時はダブルクオート不要だが，Content-Type,nameではダブル
クオート「name="xxxx"」でくくる．
Q: Quoted Printable形式 (=?charset?Q?=16進数...?=)
RFC2231: RFC2231形式(filename*=charset''%%16進数)
英語の場合は「*」不要だがダブルクオート「filename="xxxx"」でくくる．
長くて二行にする場合は filename*0*, filename*1*．英語の場合は filename*0, filename*1．
継続行の後ろには「セミコロン改行空白」つける．
ここから．
添付ファイルは日本語ファイル名のjpgとpdfを付けてます．
1. Thunderbird + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
2. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
3. Thunderbird + Plain(JIS) + 添付ファイル
Subject: UTF-8, B (BUG: JISではない)
補足:
ThunderbirdはDefaultはUTF-8だがJISに変更する方法
https://www.cc.yamaguchi-u.ac.jp/guides/mail/setting/wizardwithssl/thunderbird78.phtml
4. Thunderbird + Plain(JIS) + HTML + 添付ファイル
Subject: UTF-8, B (BUG: JISではない)
BUG: 添付ファイルの Content-Disposition, filenameがBASE64．
12. DeepMail + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, RFC2231
Content-Type: image/pjpeg (属性が変わってる: jpeg -> pjpeg)
13. Mew + Plain(JIS) + 添付ファイル
Subject: utf-8, B
base64の幅: 76
本文:
Content-Type: Text/Plain; charset=utf-8
Content-Disposition, filename: utf-8, RFC2231
---------------------------------------------------------------
* メール転送方式(以下すべてMessage/Rfc822で転送)
a. 転送:Thunderbird + Plain(JIS)
実装: 転送時は加工しない．
Bug:転送メール本文が8bit/UTF-8であっても
添付ファイルのヘッダが7bit．
Content-Type: message/rfc822;
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
Content-Type:nameは基本はBだが時々Qが混ざる。
b. 転送:Thunderbird + Plain(UTF-8)
実装: 転送時は加工しない．
転送メール本文によりContent-Transfer-Encoding:7 or 8bitが切り替わる．
Content-Type: message/rfc822;
Content-Transfer-Encoding: 7bit or 8bit
Content-Disposition: attachment;
Content-Type:nameは基本はBだが時々Qが混ざる。
c. 転送:Sylpheed + Plain(JIS)
実装: 転送メールを多数加工する．
添付ファイルのヘッダが，転送メール本文がJISの時は7bit
転送メール本文がUTF-8の時は7bit
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit or 8bit
Content-Disposition: inline"
添付ファイルを多数加工する．
1.転送時にBASE64のlen=72をlen=76にresizeする。
2.転送ファイル内のjpg/PDFにContent-IDを追加する。
3.添付ファイル内のContent-Disposition:filenameがRFC2231の場合はBに修
正する。
4.HTMLの書換が行われる。DeepMailとSylpheedと同じ修正のため、何等かの
ライブラリ？ 空白の位置や改行が変わる．
5.Thunderbirdが付けるContent-Type: format=flowedを削除する。
6.Thunderbirdが本文JISでも添付ファイル名やSubjectをUTF-8にするバグは、
全てJISに修正される。
d. 転送:DeepMail + Plain(JIS)
実装: 転送メールを多数加工する．
添付ファイルのヘッダが，転送メール本文がJISでもUTF-8でも
転送メールのファイル名はJIS．
Content-Type: message/rfc822; name=JIS,B
Content-Disposition: attachment; filename=JIS,RFC2231
(無し Content-Transfer-Encoding: )
添付ファイルを多数加工するが，修正内容は「Sylpheed + Plain(JIS)」と
同じ．同じライブラリ?
e. 転送:Mew + Plain(JIS)
転送時に8bitメールをBエンコーディングにする．Mewコメント追加．
f. 転送:Mew + Plain(JIS) + Mewコメント除去
転送時に8bitメールをBエンコーディングにする．
g. 転送:Mew + Plain(JIS) + 8bit
転送時は加工しない．
h. 転送:Mew + Plain(UTF-8) + 8bit
転送時は加工しない．
Mew注釈
8bit:
~/.mew に(setq mew-use-8bit t)加筆
Mewコメント除去
~/.mewに(setq mew-field-comment "")加筆
Plain(UTF-8)
~/.mewに
> (setq mew-cs-database-for-encoding
> `(((ascii) nil "7bit" "7bit")
> (nil utf-8 "base64" "B")))
加筆．
Thunderbird注釈
Thunderbirdはメール転送のDefaultは「メール本文に含める」だが「ファイルとして添付」
に変更した．
* 閲覧確認メールリーダー
Outlook/(Web版),
Outlook2019(Win10),
Thunderbird(78.11.0/Win10),
DeepMail(Web)
Sylpheed(3.7.0/Win10),
GOOD: すべてのメールの本文/添付ファイル名が問題なし．
Rainloop(1.15.0/Web)
NG: RFC822の添付ファイルはダウンロードになるので直接閲覧できない．
gmail/(Web版)
NG: [1,2]-e(本文NG, ファイル名OK)
原因: 本文NGはMewのコメント
gmail/(Android版)
NG: [1,2]-e(本文NG, ファイル名OK)
原因: 本文NGはMewのコメント
Outlook/(Android版)
NG: [1,2,3,4,9,12]-a (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-b (本文OK, ファイル名NG)
NG: [1,2]-e (本文NG, ファイル名NG)
原因: 本文NGはMewのコメント
NG: [3,4,9,12]-e (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-f (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-g (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-h (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
Outlook/(iOS版)
NG: [1,2,3,4,9,12]-a (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-b (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
NG: [2,4,6,8]-c (本文OK，ファイル名OK．添付ファイルの画像ファイルが消える)
NG: [2,4,6,8]-d (本文OK，ファイル名OK．添付ファイルの画像ファイルが消える)
原因不明．
NG: [1,2]-e(本文NG, ファイル名NG)
原因: 本文NGはMewのコメント
NG: [3,4,9,12]-e (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-f (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-g (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-h (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
AppleMail/iOS版
NG: 12-a,12-b(本文OK, ファイル名途中から文字化け)
NG: [1,2,3,4,5,7,8,11,12]-d (本文OK, ファイル名OKだが，RFC822の添付ファイル名が途中から文字化け)
NG: 12-e(本文OK, ファイル名途中から文字化け)
NG: 12-f (本文OK, ファイル名途中から文字化け)
NG: 12-g (本文OK, ファイル名途中から文字化け)
NG: 12-h (本文OK, ファイル名途中から文字化け)
-> MEMO: AppleMailのバグ．
Ref: https://qiita.com/qiitamatumoto/items/40cf965a5ef1bb2dd1a0
NG: [1,2]-e (本文NG,ファイル名OK)
NG: [1,2]-f (本文NG,ファイル名OK)
原因: 本文NGはMewのコメント.ただし， 最後の空白1個も消さないといけない．
「setq mew-field-comment ""」では最後に空白が１個入る．
ORGNAL: "Content-Transfer-Encoding: base64 (modified by Mew)"
NG: "Content-Transfer-Encoding: base64 " (最後に空白あり)
OK: "Content-Transfer-Encoding: base64" (最後に空白無し)
AppleMail/MacOS(11.4, メール バージョン14.0(3654.100.0.2.22))
NG: [1,2]-e(本文NG,ファイル名OK)
NG: [1,2]-f(本文NG,ファイル名OK)
原因: 本文NGはMewのコメント．ただし，最後の空白1個も消さないといけない．
以上．
各種メールリーダーが8bitで作成したメールをMewがMessage/Rfc822形式で転送
すると，転送したメールの本文が化ける問題(BASE64のdecodeに失敗する)です
が，時間が開いた時に調査してたのですが，だいたいまとまったので，まとめ
て報告しておきます．
BUGを誘発するメールリーダー
gmail(Web, Android)
Outlook(Android, iOS)
AppleMail(iOS, MacOSX)
これについてはコメントを除去する命令を
~/.mew
(setq mew-field-comment "")
を記載すると概ね改善します．ですが，以下のメールリーダまだダメです．
AppleMail(iOS, MacOSX)
上記 ~/.mewの設定では最後に余白がはいります．この余白を除去すると改善し
ます．
初期状態
"Content-Transfer-Encoding: base64 (modified by Mew)"
概ね改善「(setq mew-field-comment "")」
"Content-Transfer-Encoding: base64 " (最後に空白あり)
すべての環境で改善(ソースファイルを直接書き換え)
"Content-Transfer-Encoding: base64" (最後に空白無し)
最後の余白を取り除くには~/.mewへの加筆では難しくMewのソースコードの修正
が必要です．
Mew開発者の皆様:
可能でしたら 次期リリースでは ~/.mew の記述のみで最後の空白を取り除くの
を対応可能にしていただけないでしょうか．もしくは書き換えたという事を別
のヘッダ「X-ホゲホゲ」に記述するなど．(ソースコードの差し替えは可能なら
職場への周知としては使いたくないので．)
よろしくお願いします．
補足: 別解ですが，8bitスルーにするという方法についても教えていただきま
した．
~/.mew
(setq mew-use-8bit t)
この設定する事により，8bitスルーになり，Mewが引用メールを修正しなくなる
という副作用による，改善策です．
補足2: 最初の私のメール2021/6/9で「format=flowed」が誘発するBUGの件につ
いて記載していましたが，きちんと記録してなかったので，よくわからないの
ですが再現しなくなりました．
------------------------------------------------------------------
次に，転送したメール(Message/RFC822)の本文は読めるが，転送ファイル内に
(入れ子状態で)添付されている(日本語の)ファイル名が化ける問題です．
(※メールリーダーの組み合わせ数が多すぎて，限定的にしか調査してません．
調査が漏れてたらすいません．)
以下のメールリーダーで閲覧するとファイル名が文字化けします．
文字化けA. Outlook(iOS, Android): ファイル名が全部化ける
文字化けB. AppleMail(iOS): ファイル名の後半が化ける．
この件，文字化けAとBでは原因が違いました．
「文字化けA」についてはヒントを教えていただきましたが，ご指摘の通り，エ
ンコーディングの問題で，引用したメールの(入れ子状態の)ファイル名が
RFC2231だと文字化けするようです．具体的にはContent-Dispositionの
parameter「filename」のエンコードがRFC2231だと文字化けします．BASE64だ
と化けません．
注意: 入れ子状態の場合のみです．普通に添付されていた場合はRFC2231のファ
イル名は解釈できます．
なので，引用元のメールのContent-Dispositionのparameter「filename」のエ
ンコードがBASE64の場合は，ファイル名が文字化けしません．
(新規に作成する添付ファイルの)
ファイル名がRFC2231のメールリーダ
Mew
Thunderbird
Sylpheed(デフォルト設定)
DeepMail(Webメール/有償ソフト/職場で提供されてる)
ファイル名がBASE64のメールリーダ
Outlook2019
Rainloop
Sylpheed(オプションで変更可能),
となっています．ですが，いろいろな組み合わせで確認してみると，ファイル
名がRFC2231のメールを引用して転送してもファイル名が文字化けしない場合が
あります．
引用に用いるメールリーダーですが，Message/Rfc822で引用できるメールリー
ダーはあまりないのですが，以下で確認しました．
Thunderbird 78.11.0
Sylpheed 3.7.0(JIS)
DeepMail (JIS/Webメール/有償ソフト/職場で提供されてる)
Mew6.8
このうち，Sylpheed とDeepMailだと引用して転送してもファイル名が文字化け
しません．
差分比較(diff)などで調査したところ，Sylpheed とDeepMailは引用したメール
の(入れ子状態の)ファイル名をRFC2231からBASE64に修正していました．それで
ファイル名が文字化けしなかったようです．
ここで注意点ですが，Sylpheed とDeepMailは平時はファイル名をRFC2231にし
ます．ですが，引用したメールの(入れ子状態の)添付ファイルのファイル名は
RFC2231からBASE64に書き換えます．何らかのバグ対策をおこなっているようで
す．
補足: RFC822で引用したときに，どのような加工が行われるかですが，おそら
くThunderbirdは内容を一切変更しません．Mewは8bitをbase64などに加工する
場合があります．Sylpheed とDeepMailは色々書き換えます．(詳細省略．)
次に，「文字化けB」のファイル名の途中から文字化けする問題です．これにつ
いてですが，引用でなくても発生します．普通に添付されていても長いと文字
化けします．
Content-Dispositionのparameter「filename」が長い時は複数行にする事がで
きますが，複数行になった場合のみ文字化けするようです．ですが，Mewは文字
化けしないので不思議に思い調べたところMewはfilenameが長くなっても改行し
ないようです．この文字化けの件についてはこちらにまとめてます．
Ref: https://qiita.com/qiitamatumoto/items/40cf965a5ef1bb2dd1a0
電子メール添付の日本語ファイル名の名前の後半が化ける
(RFC2231形式の長いファイル名)
以上です．
---
補足資料．内容が重なりますが，調査の全データ．雑多なメモ書きなので，
誤記などあると思います．
*転送の対象となる元のメールの作成環境
補足:
Ref:
https://www.atmarkit.co.jp/ait/articles/0104/10/news002.html
https://www.mew.org/~kazu/doc/newsletter/3.html
Content-Transfer-Encoding: [base64|quoted-printable|7bit|8bit]
Subject: 「エンコード形式」
Content-Type, name: 「エンコード形式」
-> Content-Typeのparameter「name」のエンコード形式
Content-Disposition, filename: 「エンコード形式」
-> Content-Dispositionのparameter「filename」のエンコード形式
ファイルを保存した時の名前．
エンコード形式: [UTF-8|iso-2022-jp], [B|Q|RFC2231]
B: Base64形式 (=?charset?B?.....?=)
Subjectの時はダブルクオート不要だが，Content-Type,nameではダブル
クオート「name="xxxx"」でくくる．
Q: Quoted Printable形式 (=?charset?Q?=16進数...?=)
RFC2231: RFC2231形式(filename*=charset''%%16進数)
長くて二行にする場合は filename*0*, filename*1*．英語の場合は filename*0, filename*1．
継続行の後ろには「セミコロン改行空白」つける．
ここから．
添付ファイルは日本語ファイル名のjpgとpdfを付けてます．
1. Thunderbird + Plain(UTF-8) + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
本文:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
2. Thunderbird + Plain(UTF-8) + HTML + 添付ファイル
Subject: UTF-8, B
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
3. Thunderbird + Plain(JIS) + 添付ファイル
base64の幅: 72
本文:
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
BUG: 本文はJISになるがファイル名はUTF-8.
本文:
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
補足:
ThunderbirdはDefaultはUTF-8だがJISに変更する方法
https://www.cc.yamaguchi-u.ac.jp/guides/mail/setting/wizardwithssl/thunderbird78.phtml
4. Thunderbird + Plain(JIS) + HTML + 添付ファイル
base64の幅: 72
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
BUG: 本文はJISになるがファイル名はUTF-8.
添付テキスト(Content-Type: multipart/alternative)
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
添付HTML(Content-Type: multipart/alternative)
Content-Type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: UTF-8, B
Content-Disposition, filename: UTF-8, RFC2231
12. DeepMail + Plain(JIS) + 添付ファイル
Subject: ISO-2022-JP, B
base64の幅: 72
本文:
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, RFC2231
Content-Type: image/pjpeg (属性が変わってる: jpeg -> pjpeg)
Subject: ISO-2022-JP, B
base64の幅: 76
本文:
Content-Type: Text/Plain; charset=iso-2022-jp
base64の幅: 76
本文:
Content-Transfer-Encoding: 7bit
添付ファイル:
Content-Transfer-Encoding: base64
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, name: ISO-2022-JP, B
Content-Disposition, filename: ISO-2022-JP, RFC2231
14. Mew + Plain(UTF8) + 添付ファイル + 8bit
Content-Disposition, filename: ISO-2022-JP, RFC2231
Subject: utf-8, B
base64の幅: 76
本文:
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: 8bit
添付ファイル:
Content-Transfer-Encoding: base64
Content-Type, inline, name: utf-8, B
添付ファイル:
Content-Transfer-Encoding: base64
Content-Disposition, filename: utf-8, RFC2231
---------------------------------------------------------------
* メール転送方式(以下すべてMessage/Rfc822で転送)
a. 転送:Thunderbird + Plain(JIS)
Bug:転送メール本文が8bit/UTF-8であっても
添付ファイルのヘッダが7bit．
Content-Type: message/rfc822;
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
Content-Type:nameは基本はBだが時々Qが混ざる。
b. 転送:Thunderbird + Plain(UTF-8)
転送メール本文によりContent-Transfer-Encoding:7 or 8bitが切り替わる．
Content-Type: message/rfc822;
Content-Transfer-Encoding: 7bit or 8bit
Content-Disposition: attachment;
Content-Type:nameは基本はBだが時々Qが混ざる。
c. 転送:Sylpheed + Plain(JIS)
添付ファイルのヘッダが，転送メール本文がJISの時は7bit
転送メール本文がUTF-8の時は7bit
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit or 8bit
Content-Disposition: inline"
添付ファイルを多数加工する．
1.転送時にBASE64のlen=72をlen=76にresizeする。
2.転送ファイル内のjpg/PDFにContent-IDを追加する。
3.添付ファイル内のContent-Disposition:filenameがRFC2231の場合はBに修
正する。
4.HTMLの書換が行われる。DeepMailとSylpheedと同じ修正のため、何等かの
ライブラリ？ 空白の位置や改行が変わる．
5.Thunderbirdが付けるContent-Type: format=flowedを削除する。
6.Thunderbirdが本文JISでも添付ファイル名やSubjectをUTF-8にするバグは、
全てJISに修正される。
d. 転送:DeepMail + Plain(JIS)
添付ファイルのヘッダが，転送メール本文がJISでもUTF-8でも
転送メールのファイル名はJIS．
Content-Type: message/rfc822; name=JIS,B
Content-Disposition: attachment; filename=JIS,RFC2231
(無し Content-Transfer-Encoding: )
添付ファイルを多数加工するが，修正内容は「Sylpheed + Plain(JIS)」と
同じ．同じライブラリ?
e. 転送:Mew + Plain(JIS)
f. 転送:Mew + Plain(JIS) + Mewコメント除去
g. 転送:Mew + Plain(JIS) + 8bit
h. 転送:Mew + Plain(UTF-8) + 8bit
Mew注釈
8bit:
~/.mew に(setq mew-use-8bit t)加筆
Mewコメント除去
~/.mewに(setq mew-field-comment "")加筆
Plain(UTF-8)
~/.mewに
> (setq mew-cs-database-for-encoding
> `(((ascii) nil "7bit" "7bit")
> (nil utf-8 "base64" "B")))
加筆．
Thunderbird注釈
Thunderbirdはメール転送のDefaultは「メール本文に含める」だが「ファイルとして添付」
に変更した．
Outlook/(Web版),
Outlook2019(Win10),
Thunderbird(78.11.0/Win10),
DeepMail(Web)
Sylpheed(3.7.0/Win10),
GOOD: すべてのメールの本文/添付ファイル名が問題なし．
Rainloop(1.15.0/Web)
NG: RFC822の添付ファイルはダウンロードになるので直接閲覧できない．
gmail/(Web版)
NG: [1,2]-e(本文NG, ファイル名OK)
原因: 本文NGはMewのコメント
gmail/(Android版)
NG: [1,2]-e(本文NG, ファイル名OK)
原因: 本文NGはMewのコメント
Outlook/(Android版)
NG: [1,2,3,4,9,12]-a (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-b (本文OK, ファイル名NG)
NG: [1,2]-e (本文NG, ファイル名NG)
原因: 本文NGはMewのコメント
NG: [3,4,9,12]-e (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-f (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-g (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-h (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
Outlook/(iOS版)
NG: [1,2,3,4,9,12]-a (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-b (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
NG: [2,4,6,8]-c (本文OK，ファイル名OK．添付ファイルの画像ファイルが消える)
NG: [2,4,6,8]-d (本文OK，ファイル名OK．添付ファイルの画像ファイルが消える)
原因不明．
NG: [1,2]-e(本文NG, ファイル名NG)
原因: 本文NGはMewのコメント
NG: [3,4,9,12]-e (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-f (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-g (本文OK, ファイル名NG)
NG: [1,2,3,4,9,12]-h (本文OK, ファイル名NG)
Bug: Message/Rfc822で引用した時のみRFC2231が解釈できない．
AppleMail/iOS版
NG: 12-a,12-b(本文OK, ファイル名途中から文字化け)
NG: [1,2,3,4,5,7,8,11,12]-d (本文OK, ファイル名OKだが，RFC822の添付ファイル名が途中から文字化け)
NG: 12-e(本文OK, ファイル名途中から文字化け)
NG: 12-f (本文OK, ファイル名途中から文字化け)
NG: 12-g (本文OK, ファイル名途中から文字化け)
NG: 12-h (本文OK, ファイル名途中から文字化け)
-> MEMO: AppleMailのバグ．
Ref: https://qiita.com/qiitamatumoto/items/40cf965a5ef1bb2dd1a0
NG: [1,2]-e (本文NG,ファイル名OK)
NG: [1,2]-f (本文NG,ファイル名OK)
原因: 本文NGはMewのコメント.ただし， 最後の空白1個も消さないといけない．
「setq mew-field-comment ""」では最後に空白が１個入る．
ORGNAL: "Content-Transfer-Encoding: base64 (modified by Mew)"
NG: "Content-Transfer-Encoding: base64 " (最後に空白あり)
OK: "Content-Transfer-Encoding: base64" (最後に空白無し)
AppleMail/MacOS(11.4, メール バージョン14.0(3654.100.0.2.22))
NG: [1,2]-e(本文NG,ファイル名OK)
NG: [1,2]-f(本文NG,ファイル名OK)
原因: 本文NGはMewのコメント．ただし，最後の空白1個も消さないといけない．
以上．
matsumoto/Mew
Jun 25, 2021, 2:49:12 AM6/25/21
to mats...@tech-i.kyutech.ac.jp, mew...@googlegroups.com
松元です．
申し訳ない．検証時のミスに気がつきました．
先ほどの文字化けの調査結果ですが，間違ってる可能性高いです．特に後半の
ファイル名の文字化けの件の検証は間違ってるとお考えください．
Subject: Re: [mew-ja] Mewの転送(f)で，転送メール全体を添付ファイルとせず，転送メールの本文を引用する形
Date: Fri, 25 Jun 2021 14:12:54 +0900 (JST)
書き換えが行われませんでした．
どうもテストの方法が悪かったようです．
そういえば，Outlook2019にIMAPを二つ設定して，Outlook2019でIMAPサーバ間
のファイルコピーしたな．．その時が怪しい．
--
松元隆二. 九州工業大学 飯塚キャンパス技術部
メールアドレス: matsumoto(AT)tech-i.kyutech.ac.jp
申し訳ない．検証時のミスに気がつきました．
先ほどの文字化けの調査結果ですが，間違ってる可能性高いです．特に後半の
ファイル名の文字化けの件の検証は間違ってるとお考えください．
Subject: Re: [mew-ja] Mewの転送(f)で，転送メール全体を添付ファイルとせず，転送メールの本文を引用する形
> 補足: RFC822で引用したときに，どのような加工が行われるかですが，おそら
> くThunderbirdは内容を一切変更しません．Mewは8bitをbase64などに加工する
> 場合があります．Sylpheed とDeepMailは色々書き換えます．(詳細省略．)
特にSylpheed とDeepMailの件は間違いです．再確認したところ，上記の中身の
> くThunderbirdは内容を一切変更しません．Mewは8bitをbase64などに加工する
> 場合があります．Sylpheed とDeepMailは色々書き換えます．(詳細省略．)
書き換えが行われませんでした．
どうもテストの方法が悪かったようです．
そういえば，Outlook2019にIMAPを二つ設定して，Outlook2019でIMAPサーバ間
のファイルコピーしたな．．その時が怪しい．
--
松元隆二. 九州工業大学 飯塚キャンパス技術部
メールアドレス: matsumoto(AT)tech-i.kyutech.ac.jp
Reply all
Reply to author
Forward
0 new messages