キャプチャ画像を目で見て手打ちするのはしんどいので2行程度だけですが、こんな具合ですね。

先頭：

末尾：

なぜこうなったのかはわかりませんが、ソース表示から何が起きているかは推測できます。

• 末尾の「--------------j1zvPiIqVfgT8aAQZgGkV9AA--」というのは、最初見てピンときましたがやっぱりMIMEマルチパートの境界行でした。
  その行の上の部分はおそらく添付ファイルの内容をBase64エンコードしたものと思われます。
• ポイントは先頭の「>From」です。ここにこういう文字列が登場することは異常です。Base64でエンコードされているとして、エンコード結果に「>」という文字が出力されることはありません。また次の行が66文字しかないのも気になります。エンコード結果に規格違反の「>」と「CR(0x0D)」が含まれていた（もしくは後から置換された？）とすれば辻褄が合います。
• メッセージの格納形式が「フォルダー単位 (mbox 形式)」の場合、フォルダーの名前の拡張子無しのファイルにフォルダーのすべてのメールのソースが連結されて保存されます。
  その際、各メールの区切りとして先頭に「From 」という行（もしくは「From 」で始まる行）が挿入されます。したがって想定外の箇所に「From 」行が現れたため、メールの区切りと誤認してしまったということが推測できます。（ただし実際にどうかは検証が必要です）
• 先頭部分から最初に空白行が現れる部分をヘッダー情報として読み飛ばし、次の行の「--------------j1zvPiIqVfgT8aAQZgGkV9AA--」を本文として表示したのでしょう。

kawara さんが新たな投稿をされたようですのでここで区切ります。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

それでしたら、本文が表示されたメールをemlファイルに保存してソースを取っておいてください。
そして問題の「>From」が含まれていないか確認をお願いします。
そしてその直前に「空白行」があるかも。


ConohaのレンタルサーバーとIMAPで同期させているわけですよね。
そして今までの状況からして再発する可能性は否定できません。
原因究明が必要だと思います。

該当のメールをIMAPの影響を受けない「ローカルフォルダー」アカウント下のフォルダーにもコピーしておいてください。
そうすることで問題が再発した際にIMAPの影響かどうかが判断できると思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

直ってよかったです

>（PC-1 ●12年/PC-2 ●10年/PC-3 1年）古いPCならあり得るかな

これでいいんですよね？

否定しなかったので

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

kawara さん、maji です。

viewtopic.php?f=3&t=22771#p78608

不思議、ですね。

発覚ついでに、もう1点だけテスト確認してもらえますか？
その「改めて別フォルダに移動したところ改善しました」のメールですが、
その「改善したメール」を
もう一回だけ受信トレイに戻したら、どうなりますか？

質問の意図は
メールが受信トレイにある状態でのみ表示不正になるのかどうかを確認したい、
です。

では。



.

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

kawara さん
せっかく本文が表示されたメールを受信トレイに移動する必要はありません。
確認ということなら、ローカルフォルダー（IMAP外）と受信トレイ（IMAP内）にコピーしておきましょう。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

kawara さん、maji です。


そうですね。
せっかくちゃんと表示されたので、
移動ぢゃなくてコピーで確認してみてください。

EarlgreyTea さん、
アドバイスありがとうございます。

では。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 Edg/128.0.0.0

Inboxファイルを編集して途中に「From 」行を挿入して試してみたのですが、そういう簡単な話ではなかったようです。
しかも、該当メールの先頭に出てきた「>From 」はソース表示で表示されたということはそれ自体はメール区切りではない（表示に含まれない）わけで、現象が発生している時点のInboxファイルとかを直接調べないとちょっとわからないですね。
※つまり、kawara さんご自身が調べる必要があるということです。

検証をしている際に気になったことがありました。
Ver.115まではmbox形式のメール区切りは
「From - Sat Aug 17 17:32:25 2024」
というようにmboxに書き込まれる際のタイムスタンプ（ほぼ受信日時）が記録されていたのですが、Ver.128の現在では
「From 」
だけになっています。
いつから変わったのか調べてみると下記チケットでの変更（Nightlyに2023-12-03 22:15 PSTにpush）によるものでした。

Bug 1719121 Confine "From " line handling to mbox-specific code

そして上記によるリグレッションとして登録されている下記が興味深いです。

Bug 1911916 After "Repair Folder" I see 81 old messages appearing at the date/time of the repair ! (Date: header missing)

あくまで漠然とした印象レベルですが、

• Bug 1719121 による「From 」行関連の変更
• 「From」→「>From」のエスケープ処理
• フォルダーを修復
• IMAPサーバーとの通信
• 該当メールのヘッダー情報の癖

こういったものが関係しているような気がしています。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

Bug 1911916 に関連すると思われるバグが追加されました。

Bug 1911477 Since v128 the inbox/message view shows all new mail as having no subject, no sender and date 1970-01-01 (pop)

なお、上記と同じことをYahoo!メールのPOPアカウントでやってみましたが再現はしていません。
特定のメッセージソースで起こることなのかもしれません。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0