第１ メールサービスとメールソフトを区別する
メールが送れない，過去のメールが見つからないという場合には，メールサーバーと，閲覧・送信に使うソフトを分けて考える。
ThunderbirdやOutlookはメールソフトであり，アカウントを追加しただけでメールの保管場所や契約先がそのソフトの提供者に移るわけではない。
本記事は通信と安全管理の基礎を扱い，個別の設定値は契約先の公式案内に従うものとする。
第２ POP・IMAP・SMTPの役割
| 方式 | 基本的な役割 | 実務上の注意 |
|---|---|---|
| POP | サーバーからメールを取得する | サーバーに残すか削除するかは設定による |
| IMAP | サーバー上のフォルダー・メッセージ等を同期する | 削除も他端末へ反映され得る |
| SMTP | メールを送信・中継する | 受信設定とは別に送信認証等を確認する |
IMAPでも，本文を端末へ同期してオフラインで読む設定がある。
逆に，件名が表示されていても本文や添付ファイルがすべて保存済みとは限らない（出典①）。
POPとIMAPの違いを「必ず端末だけに保存」「必ずサーバーだけに保存」と単純化しない。
第３ ヘッダーから分かることと限界
１ 画面表示と原メール
原メールには，差出人・宛先・件名等のヘッダーと本文，添付ファイルに関する情報が含まれる。
画面の「差出人名」だけでは実際の送信主体は分からない。
転送や印刷では失われる情報もあるため，紛争が関係するメールは可能であれば原形式でも保存する。
２ Received・Message-ID・認証結果
Receivedは配送経路を検討する手掛かりとなるが，すべての行を無条件に信用できるわけではない。
自組織や信頼できる受信サーバーが付与した部分と，その手前から渡された部分を区別する。
IPアドレスやMessage-IDがあることだけで，特定人物による作成や本文の真実性が証明されるわけでもない。
SPF・DKIM・DMARCの結果は，送信ドメイン等の検証に役立つ。
しかし，正規アカウントの乗っ取り，表示名による詐称，内容が虚偽である場合まで排除する仕組みではない。
振込先変更など重要な依頼は，メールに書かれた連絡先だけに依存せず，既知の経路で確認する。
第４ TLS・STARTTLSとポート番号
TLSは通信経路を保護する仕組みである。
最初からTLSで接続する方式と，接続後にSTARTTLSでTLSへ切り替える方式があり，対応するポートや設定を組み合わせて使う。
代表例は，IMAP over TLSが９９３，POP over TLSが９９５，メール投稿用のImplicit TLSが４６５である（出典②）。
メールソフトから送信サーバーへの接続では５８７とSTARTTLSを使う構成もある。
ただし，「ポート番号が合う」だけでは不十分で，サーバー名，TLS，認証方式，証明書を確認する。
つながらないことを理由に証明書エラーを無視したり，保護されていない接続へ切り替えたりしない。
通信経路のTLS保護は，メールの保存先やすべての中継区間，受信者端末を自動的に保護するものではない。
エンドツーエンドの暗号化，アクセス制限，保存時の保護とは分けて検討する。
第５ PPAPとファイル共有
パスワード付きZIPとそのパスワードを別メールで送る方法は，宛先を同じように間違えたり，メールアカウント自体が侵害されたりした場合には，双方が第三者へ渡ることがある。
「別メールにした」ことだけで秘密を守れるとはいえない。
代替として共有リンクを使う場合も，リンクを知る者全員が見られる設定か，受取人を限定した設定かを区別する。
アクセス権，有効期限，再共有，ダウンロード後の管理，ログを検討し，送信前には宛先と添付対象を確認する。
いずれの方法でも，事務所の安全管理方針と依頼者情報の取扱条件が前提となる。
第６ 不達・異常時の確認
エラーメールが届いたら，宛先，発生時刻，エラーコード，拒否したサーバー，メール容量を記録する。
「Unknown user」は宛先の不存在等を疑う手掛かりであるが，転送先や別の配送経路での拒否もあり得る。
送信済みフォルダーにあることだけで相手方の受領まで確認したと扱わない。
証拠保全では原メール，添付ファイル，前後のやり取り，タイムゾーンを残す。
不審な添付ファイルは通常の業務端末で開かず，事故対応担当者と連携する。
期限のある連絡では，電話等の代替経路で相手方と状況を確認することが重要である。
第７ 関連記事と出典
Thunderbirdの設定・バックアップ・メール移行，GmailとGoogle Workspace，デジタル証拠の原本保全とハッシュ値を参照されたい。
① Mozilla「IMAP Synchronization」
https://support.mozilla.org/en-US/kb/imap-synchronization
② IETF RFC 8314（メール投稿・アクセス通信のTLS）
https://www.rfc-editor.org/rfc/rfc8314.html
③ IETF RFC 8997（メール投稿・アクセスにおけるTLS 1.1の非推奨化）
https://www.rfc-editor.org/rfc/rfc8997.html
④ IETF RFC 5322（電子メールのメッセージ形式）
https://www.rfc-editor.org/rfc/rfc5322.html