Bug 1650626 は18年前に出されていた Bug 196584 の重複ということでクローズになりましたが、
Bug 196584 で mail.server.default.dot_fix = false をデフォルトにする提案がされています。
これが通れば、outlook.office365.com からPOPで受信しても、余分なドットを見なくて済むようになるでしょう。

ようやく Bug 1650626 が NEW になりました。
それによると、 mail.server.default.dot_fix = false を設定すればいいそうです。

Bug 1650626 ですが、バージョン聞かれたので追加情報書いておいたのですがまた一週間放置です。
さらに追加情報書いたのですが…なんというか Wayne Mery さんに受け付けてもらえないと何も始まらないので…どうしたらあの人の気を引けるんですかね？

ログの最後のドット行の辺りに注目して、outlook.office365.com だと空白行を挟んできてるんじゃ？と考えてたのですが、そうじゃないかもしれません。
openssl で outlook.office365.com:995 に接続してPOPのコマンドを打って（実際にはコマンド書いたテキストファイルをパイプで流して）試してみたのですが、少なくとも CRLF が連続（空行）してるようなことはありませんでした。
もちろん、端末上で見えない文字が挟まれていてもわからないわけですが。

そこで、それ以外の違いというと RETRコマンドの応答の一行目の「+OK」に「5247 octets.」みたいにオクテット数が付いていないのに気がつきました。
ただ、これは RFC 1939 だと必須じゃないみたいなんで、もしこれが原因だとすると サーバー側は悪くないということになります。

とりあえず報告。

Bug 1650626 が一週間経過してやっとトリアージ受けました。
でもまだUNCOのまま、今スタートしたところです
POPの処理を修正（できればベストですが）はリスクがあると思うので、
なんとかMicrosoft側に働きかけて改善してもらう流れになればいいなと思っています。

[quote="koshi"]メール本文最後と終端のピリオドの間にも(null)があるなんて
C言語での処理に便利そう（逆にC言語で1バイト多く処理してしまってる？）[/quote]
あれはあくまでログの表示であって、生データにnullポインターやNUL文字が入っているわけではありません。
実際のソースコードは見ていませんが、1行（<CRLF>で区切られた）データを受信する関数が返値としてnullポインターを返したというのを出力しているだけかと。
生データの該当箇所で<CRLF>が連続して長さ0の空行になっているのか、それともいったん途切れてしまっているのか、それは私にはわかりません。
あと、C言語じゃなくて主にC++です。あとRustとかJavaScriptとか…

[quote="koshi"]申し訳ありません。他のメールソフトでは確認できていません。[/quote]
バグ報告の前に私が確認してます。
Windows 10標準のメールアプリ、Sylpheed、Becky! です。

[quote="koshi"]スマホにも配信されたメールにピリオドが無かったということです。[/quote]
普通に設定したらIMAPのはずです。

[quote="EarlgreyTea"]これが他のメールソフトで現象が発生しない原因ということになるでしょう。[/quote]申し訳ありません。他のメールソフトでは確認できていません。
スマホにも配信されたメールにピリオドが無かったということです。

EarlgreyTeaさん

解析ありがとうございます。
すごいですね。

メール本文最後と終端のピリオドの間にも(null)があるなんて
C言語での処理に便利そう（逆にC言語で1バイト多く処理してしまってる？）

昨年のメールサーバ変更時にIMAPをすすめられたのですが
IIJ上で容量大きいためかIMAPでの接続に失敗しまして
受信フォルダとかそのまま使いたかったので
POPのままoutlook.office365.comに移行していました。

そんなわけで、この組み合わせで使用してるのが私ぐらいで
なおかつ、プレーンテキストでbase64などの変換かかっていない場合のみ
見える現象なので、本当にレアですね。

実際、昨年から発生していたのですが
ピリオドに何の違和感もありませんでした。

とにかくスッキリしました。
ありがとうございました。

IMAPへの移行検討します。

バグ報告してみました。
Bug 1650626 A dot is added to the end of messages received from outlook.office365.com using POP

POP受信した際の動作ログを出力させて調べてみました。
方法は下記で、モジュール指定は「timestamp,POP3:5」としました。
[list][*][url=https://www.clear-code.com/blog/2013/6/25.html]問題の原因調査のためのログ収集のセオリー - ククログ(2013-06-25)[/url][/list]

outlook.office365.com と比較対象として pop.zoho.com から
同じプレーンテキストのメール本文[code].
..
...[/code]を受信した際のログを取得したところ、以下となりました。

outlook.office365.com[code]2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV:

2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ..

2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ...

2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ....

2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: (null)
2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering NET_ProcessPop3 3
2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering state: 19
2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: .

2020-07-05 03:05:51.826000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: (null)
2020-07-05 03:05:51.841000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering state: 15
2020-07-05 03:05:51.841000 UTC - [(null) 18696: Main Thread]: D/POP3 sink: [this=2CA3FD30] Calling ReleaseFolderLock from EndMailDelivery
2020-07-05 03:05:51.841000 UTC - [(null) 18696: Main Thread]: D/POP3 sink: [this=2CA3FD30] ReleaseFolderLock haveSemaphore = TRUE
2020-07-05 03:05:51.857000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering state: 22
2020-07-05 03:05:51.857000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] SEND: QUIT[/code]
pop.zoho.com[code]2020-07-05 03:05:29.739000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV:

2020-07-05 03:05:29.739000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ..

2020-07-05 03:05:29.739000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ...

2020-07-05 03:05:29.739000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: ....

2020-07-05 03:05:29.739000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: .

2020-07-05 03:05:29.792000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] RECV: (null)
2020-07-05 03:05:29.792000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering state: 15
2020-07-05 03:05:29.855000 UTC - [(null) 18696: Main Thread]: D/POP3 sink: [this=11C731F0] Calling ReleaseFolderLock from EndMailDelivery
2020-07-05 03:05:29.855000 UTC - [(null) 18696: Main Thread]: D/POP3 sink: [this=11C731F0] ReleaseFolderLock haveSemaphore = TRUE
2020-07-05 03:05:29.877000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] Entering state: 22
2020-07-05 03:05:29.877000 UTC - [(null) 18696: Main Thread]: I/POP3 [this=05010D60] SEND: QUIT[/code]
本来、メール本文と終端のピリオドまで続けて受信した後に(null)となるはずが、outlook.office365.com の場合は、メール本文最後と終端のピリオドの間にも(null)を受信してしまっていることに注目してください。
この outlook.office365.com がPOP3のRETRコマンドの応答を返してくる際の挙動の違い、これが最初の原因です。

そして、その際になぜか Thunderbird は終端のピリオドを受信メッセージに追記してしまっている、ように見受けられます。
これが他のメールソフトで現象が発生しない原因ということになるでしょう。

したがいまして、outlook.office365.com のPOPゲートと Thunderbird どちらもおかしい、というのが私の結論です。
outlook.office365.com は素直にIMAPで利用されることをおすすめします。

試してみました。
outlook.office365.com から POPでメールをダウンロードすると、終端のピリオドがメールソースに含まれていました。
これは IMAPでは起こりません。
詳細は後で調べてみようと思いますが、取り急ぎ結果だけお知らせしました。

有料です。

Thunderbirdを疑ってしまいましたが
メールサービスの問題かもしれませんね。

会社のなので
週明けに確認してみます。

[quote="koshi"]ところが受信したすべてのメールの最後に
「<CRLF>.<CRLF>」がついたままになっています。[/quote]
特定の差出人や特定のメールソフトで送信されたメールではなく、すべてのメールなのですね？
そうすると、ご利用メールサービス由来の挙動の可能性が高いと思われます。

[quote="koshi"]outlook.office365.com(POP)[/quote]
私は無料の Outlook.com (hotmail) を利用していますが、サーバーは同じです。
koshi さんご利用のメールサービスは、有料の Office365 でしょうか。
夜に帰宅したら、一応 POPのアカウントを作成して試してみることにします。

[quote="EarlgreyTea"]本文にピリオドを打ったのでなければ、ありません。[/quote]普通そうですよね。
ところが受信したすべてのメールの最後に
「<CRLF>.<CRLF>」がついたままになっています。

アカウント：
[list]
[*]outlook.office365.com(POP)[/list]

本来であれば、存在しない「<CRLF>.<CRLF>」があり
表示されているようです。

Content-Type: text/htmlや
Content-Transfer-Encoding: base64の場合
本文の終わりが明確なので、本文以降の文字として無視され
表示されないようです。

昨年メールサーバーをIIJからoutlook.office365に変えたのですが
IIJ時に受信したメールには「<CRLF>.<CRLF>」はついていませんでした。

outlook.office365の仕様なのか設定なのか
それともThunderbird上の設定なのか
わかれば教えてほしいです。

[quote="koshi"]最後にピリオドはありますでしょうか？[/quote]
本文にピリオドを打ったのでなければ、ありません。
環境：
[list]
[*]Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0[/list]
アカウント：
[list]
[*]Gmail(IMAP)
[*]Yahoo!メール(POP)
[*]Outlook.com(IMAP)
[*]Zoho Mail(IMAP)[/list]
です。

ところで気になっていることがあるのですが、[quote="koshi"]SMTPのメールではメール本文の最後を示すため
半角ピリオド文字があります。[/quote]こちらは何を指してそういっているのでしょう。

最後を示すピリオドですが、これは正確には、
SMTPにおけるDATAコマンドの終わりは「<CRLF>.<CRLF>」で示されるということです。
ちなみに、メール中に「<CRLF>.<CRLF>」が含まれていた場合に区別がつかなくなりますので、行頭にピリオドがあったら送信側ではもう一つピリオドを追加し、 受信側では行頭のピリオドを一つ削除する、ということを行います。
参考: https://www.softel.co.jp/blogs/tech/archives/2277

こういったことは、SMTPサーバーにtelnetで入って、直にコマンドを打っているとかでなければ意識する場面はないはずです。

EarlgreyTea様

プレーンテキストのみのメールが少なく
調査に時間がかかり、確証が得られていません。

EarlgreyTea様のテストで一つ確認したいことがございます。
Thunderbirdで受信メールをファイル保存(xxxx.eml）します。
このファイルをテキストエディターで開くと
最後にピリオドはありますでしょうか？