とりあえず報告。

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

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

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

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

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

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

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

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

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

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