一度きりのパスワードや鍵をメール本文に書いて送ったあと、送信済み・バックアップ・管理者側に何が残るか

送信は「ひとこと知らせる」ではない。平文を保管システムへ渡すこと

仕事のメールは、手元の会話欄に見えやすいです。字は自分の画面にあり、相手は「見ているだけ」だと思える。送信したあと、その段落は今のタブを出て、事業者が配送し、索引し、残すメッセージになります。データベースのパスワード、クラウドのアクセスキー、GitHubの個人アクセストークン、共有Wi-Fi、アカウントの復旧コードは、OWASPのログ・チートシートが、共有の平文記録へ残すなと書く桶と同じです。送信済み、受信トレイ、下書き、スマホのIMAP複製は、社内で「形式ばらない鍵庫」になりがちです。検索は楽で、パスワードマネージャより権限が緩く、保持は長い。

HTTPSや「このメールは暗号化されています」が守るのは、伝送中の盗聴です。相手のメールボックスが本文を何日持つか、管理者に検索させるか、バックアップディスクにまだ一通あるかは決めません。前のノートで書いたとおり、モデルの会話へ鍵を貼ると、原文は履歴と、学習へ入ることがある複製になります。メールで秘密を送るのは、同じ種類の露出です。受け手が「モデル提供者」から「少なくとも2つのメール保管と、途中の中継」へ変わっただけです。送る前に問うのは「このクライアントは賢いか」ではありません。「この段落に、検索できるメール本文へしてはいけない秘密があるか」です。

本稿は Gmail、Exchange Online、Google Vault、Microsoft Purview を主にします。保持日数と管理者検索の範囲が、公開ヘルプに数字で書いてあるからです。自前のPostfixや、ほかのホスト型メールも、ストアアンドフォワードです。製品を変えたら、その削除と保管のページをもう一度歩いてください。下に書くゴミ箱の約30日や、回復可能なアイテムの既定14日を、別サービスへそのまま当てないでください。

鍵マークと STARTTLS が守るのは1区間であり、端から端ではない

ブラウザやメール画面の鍵マークは、「相手まで端から端まで暗号化されている」と読まれやすいです。SMTPの伝送暗号化は、そう動きません。RFC 3207 第6節は率直です。SMTPは端から端の仕組みではない。1組のSMTPクライアントとサーバがTLSを付けると決めても、送信者のメールユーザエージェントから受信者まで守ったことにはならない。1通は2台以上のSMTPサーバを通れます。1組のTLSは、配送路の全体を秘密にはしません。

そこで、見た目が矛盾する現場が出ます。自分のクライアントから社内の出ゲートはTLS、ゲートから相手のMXもSTARTTLS、でも各区間の終わりで、中継は封筒を読み、迷惑メール判定をし、次へ渡すためにメッセージを開けます。そのディスク上の本文は、既定で読めます。「途中の誰も読めない」が要るなら、S/MIMEやOpenPGPのような内容の暗号化であり、伝送の鍵マークではありません。仕事の作成欄へ書いたパスワードが、この層を通ることはほとんどありません。

IMAPとスマホのクライアントは、もう一通を複製します。メールは、ウェブのタブで眺める通り道ではありません。サーバ上のオブジェクト保管です。受信トレイ、送信済み、下書き、ゴミ箱は、それぞれオブジェクトです。別のログイン済みPC、会社支給のスマホ、デスクトップのオフラインキャッシュは、同じ平文を読めます。伝送暗号化が止めるのは、線路上の傍観者です。すでに保管へ入った複製は止めません。

送信済みと受信トレイ：送った瞬間に、読める複製は少なくとも2通

送信のあと、削除の話をする前に、通数を数えてください。1通目は自分側です。Gmailの「送信済み」、Outlookの「送信済みアイテム」、多くのIMAPのSentです。ブラウザの取り消しバッファではありません。保管へ書いた正式なオブジェクトです。2か月後に自分でそのパスワードを検索できます。そのメールボックスを検索できる管理者もできます。2通目は相手側です。受信トレイと、「すべてのメール」やアーカイブへしまった1通です。どちらも本文です。「件名だけ」ではありません。

CcとBccは通数を増やします。プロジェクト全員へのCcは、各自の受信トレイに1通ずつ残します。Bccが隠すのは、ほかの宛先からの住所であり、保管の通数ではありません。自動転送、ジャーナリング、「Teamsやチャットにも送る」ゲートウェイは、メール製品の外へもう1通を落とせます。これらの複製は、削除ボタンを共有しません。自分の送信済みを空にしても、相手の受信トレイは動きません。ゲートウェイがすでに書いた1通も動きません。

日本の現場では、パスワード付きZIPを1通目、解除パスワードを2通目で送る、いわゆるPPAPがまだ残っています。総務省の国民向け事例は、添付とパスワードメールが同じ誤った宛先へ届いた、と書いています。別送は盗聴対策にも、誤送信対策にもなりません。本稿が足すのは、その先です。2通目のパスワードメール自体が、本文に平文を残す同じ問題です。送信済みと受信トレイに、解除文字列が検索できるオブジェクトとして残ります。ZIP側に何が残るかは、パスワード付きZIPの既定暗号化・ファイル名・未暗号化の項目です。ここでは、2通目の本文がメール保管へ入った、という事実だけを数えます。

検索欄が証拠です。Gmail、Outlook、多くのウェブメールは本文を索引します。カナリアを検索へ入れてください。当たれば、そのメールボックスを持つ人には読めます。クラウドの重複排除ハッシュや、クリップボード履歴と同じ種類の残りです。製品が平文を残すのは、検索が便利だからであり、秘密を忘れさせるためではありません。

双方が削除しても、猶予はたいていまだ残っている

「自分も消した、相手も消した」は、秘密が戻った、と聞かれやすいです。各社が書く削除の道は、もっと長いです。Gmailの削除ヘルプは、削除したメールはゴミ箱へ入り、その後最大約30日はゴミ箱で見つけ、受信トレイへ戻し、または完全に削除できる、と書いています。30日が過ぎるとアカウントから完全に削除され、ゴミ箱からは戻せません。アーカイブは削除ではありません。受信トレイから外すだけです。「すべてのメール」の検索は、まだ当たります。

Google Workspaceは、その利用者側の期限のあとに、管理者の猶予を足します。Workspaceの復元ヘルプは、ゴミ箱の30日が終わったあと、管理者はさらに約25日、管理コンソールからメールを復元できる、と書いています。この約25日は、削除から30日後に始まります。送信日や受信日ではありません。終わると、Workspaceアカウントから完全に削除され、管理者もGoogleも戻せない、と書いてあります。Vaultの保持と記録保持は、この復元ボタンの外です。別の複製です。

Exchange Onlineは、「消えた」のあとに隠れたフォルダを持ちます。Microsoftの完全削除アイテムの説明は、削除済みアイテムからさらに消す、削除済みを空にする、またはShift+Deleteで完全削除すると、オブジェクトは回復可能なアイテムの「削除」へ移り、既定で14日残る、と書いています。管理者は最長30日まで延ばせます。利用者はOutlookの「削除済みアイテムの復元」で戻せます。メールボックスが訴訟ホールドなら、この保持期限は無視され、14日では掃除されません。

送信の取り消しは、すでに出た秘密を回収しません。Gmailの送信取り消しが用意するのは、5、10、20、または30秒のキャンセル窓です。本当の配送を遅らせます。相手のサーバから本文を掘り戻しません。窓が過ぎれば、普通の送信済みです。Outlookのメッセージの回収は、特定のExchange組織内で、相手がまだ読んでいないときに限り得ます。汎用の回収ボタンではありません。

企業の保管と管理者検索は、別の複製であり、利用者は消せない

個人のゴミ箱の期限と、会社のコンプライアンス保管は、同じスイッチではありません。Google WorkspaceのVaultによるGmail検索は、本文と添付のキーワード検索として作られています。Googleは、メッセージ本文と添付を合わせて最初の約1MBを索引する、と書いています。管理者はプレビュー、印刷、添付のダウンロードができます。下書きと自動保存の下書きも範囲です。既定の保持ルールがあれば、利用者がゴミ箱を空にしたあとも検索できます。製品の仕事は、「社員が消したあとも見つける」です。

Microsoft Purviewの電子情報開示も、メールボックスを同じ向きで扱います。メールボックス内のコンテンツ検索は、キーワードを使うとき、件名、本文、参加者に関する多くのプロパティを含める、と書いています。索引されるプロパティには、送受信日、差出人と宛先、添付のファイル名、本文のテキストがあります。設計の目標は「利用者が削除を押したあとも見つけられる」であり、「送信者の後悔を尊重する」ではありません。

だから「私たち二人だけが知っている」は、会社のメールではたいてい成り立ちません。Vaultを開ける人、電子情報開示を走らせる人、メールボックスを書き出せる人は、職務としてそのパスワードを読めます。ある事業者が趣味で覗いている、という主張ではありません。ヘルプが書く権限です。個人のGmailにWorkspace管理者はいません。それでも、すでにログインしたPCの前に座る人には、送信済みの平文は読めます。

機密モードが止めるのは誤転送であり、保管とスクリーンショットではない

Gmailの機密モードは、「一度読めば消えるメール」にされやすいです。公式の範囲は、もっと狭いです。Gmailの機密モードは、期限を付け、あとからアクセスを取り消し、転送・コピー・印刷・ダウンロードを止め、SMSコードを要求できる、と書いています。同じページは、受信者はスクリーンショットや写真を撮れる、マルウェアの入った受信者はコピーやダウンロードができることがある、と注意します。Workspace側の実装もはっきりしています。受信者の1通から本文と添付を外し、内容へのリンクに置き換えます。SMTPで出るのは、主に件名とそのリンクです。

期限や取り消しは、受信者へ本文を閉じられます。送信側組織の中の複製は消しません。Vaultの対応データと、Vault日本語ヘルプの情報保護モードは、組織がこの機能を有効にしているとき、2018年11月30日より後に組織内の利用者が送ったそのメールを、Vaultは記録保持、保持、検索、書き出しできる、と書いています。利用者が有効期限を付けたり、受信者のアクセスを取り消したりしても、Vaultはそれらを扱えます。検索は label:confidentialmode です。プレビューでは内容が既定で隠れ、操作者が表示を選べます。焼いたのではありません。受信者への門と、コンプライアンス入口への開いた扉です。

したがって機密モードは、誤転送を減らす制御です。一度きりの鍵の通路ではありません。本文を預かるのは、同じメール事業者です。件名は普通のSMTPを走ります。スクリーンショットは、Google自身のページが対象外です。目標が「サーバは暗号文だけを持ち、既定回数で消し、鍵はHTTPに入らない」なら、それは別の分割です。同じ1通に機密の印を付けたことではありません。

その場で確かめる：カナリアは試験用アカウントだけに入れ、送信済みを検索する

「このメールは暗号化されています」という標語は、自分では証明できません。その場で見えるのは四つです。送信済みに原文があるか、受信側の試験箱に原文があるか、削除のあとゴミ箱または回復可能なアイテムにまだあるか、鍵マークを「サーバも読めない」と取り違えていないか。この手順が証明するのは、この試験メールが残した読める複製です。ある事業者の保管方針は証明しません。そちらは公式ヘルプとの照合だけです。Networkは、その代わりにはなりません。

自分で管理できる試験用メールボックスを2つ用意してください。本番の宛先帳は使わないでください。本物のパスワードとぶつからない、一目で分かるカナリアを書いてください。例は canary-mail-2026-do-not-reuse です。件名は普通の通知のまま。本文にはカナリアだけ。マイナンバーや本物のホスト名は入れないでください。送信直後に、送信側アカウントでその文字列を検索します。送信済みが当たるべきです。受信側の試験アカウントへ入り、もう一度検索します。受信トレイも当たるべきです。2箇所当たれば、少なくとも2通の平文です。送信側の1通をゴミ箱へ入れてください。30日以内にゴミ箱を開きます。Gmailなら、まだあるべきです。削除が回収ではない、という証拠です。

鍵がHTTPに入ったかを見るときは、鍵をメールへ書かないでください。ワンタイムリンクへ切り替えてください。作成後のアドレスバーは s.html?id= と # の鍵です。開発者ツールのNetworkを開きます。リクエスト行に出るのは番号だけです。ハッシュの後ろは出ないべきです。この照合が証明するのは、リンクの形です。メール本文については何も証明しません。本文が出たあと、Networkは、すでに入った保管を引き戻せません。

1. 試験用の2箱から、本文にカナリアだけを入れて送る。例は canary-mail-2026-do-not-reuse。本物の鍵は使わない。
2. 送信側の送信済みと、受信側の受信トレイでその文字列を検索する。両方当たるべき。
3. 送信側を削除し、ゴミ箱または「削除済みアイテムの復元」を開き、期限内にまだあることを確認する。
4. 本物の鍵を人へ渡すときは、ワンタイムリンクへ切り替える。メールは、鍵を含まない通知か、すでに暗号化した添付だけにする。

証明の範囲は狭いです。この1回で、平文がメール本文として少なくとも2つの保管へ入り、削除は送信側の複製をすぐには消しませんでした。拡張機能が3通目を残していないことは証明しません。相手の会社がVaultを開いていることも証明しません。メール製品を変えたら、その削除と保管のページへ向けて、カナリアをもう一度走らせてください。

開いてすぐ使えるワンタイムリンクで、通知と鍵を分ける

「本文をメール保管へしない」を繰り返せる動作にしたいなら、MakePwdのワンタイムリンクから入れてください。開いてすぐ使え、登録もログインも不要です。平文は作成側のタブにだけ出ます。ブラウザはWeb CryptoでAES-256-GCMにします。外へ出る欄は、暗号文、期限、閲覧回数です。サーバは暗号文だけを一時保存し、番号を返します。ページは鍵をフラグメントへ付けます。s.html?id={番号}#{鍵} です。RFC 9110では、対象URIにフラグメントは入りません。リクエスト行に、ハッシュの後ろは出ないべきです。

練習はカナリアだけにしてください。捨てられるフレーズを作り、完全なリンクを試験相手へ送り、メール本文には「リンクを開く。ハッシュを含む文字列は転送しない」だけを書いてください。相手が確認して取ったあと、同じ番号を開くと、また読める本文ではなく、すでに焚けた状態になるべきです。チャットやメールに青いリンクは残ります。それは位置を示す印です。暗号文が設定回数で消えたあと、その文字列は何も開けません。詳細はワンタイムリンクを一度開いたあと、サーバーに残るのは何かと、URLのハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるときです。

鍵を含むファイル一式を、「パスワード付きZIPを添付する」へ戻さないでください。ファイル暗号化は、今のタブでAES-256-GCMにより .lock / .enc にします。単一ファイルは5GBまでです。暗号文はメールやドライブを通れます。パスフレーズは別経路です。すでにメールで出したログインパスワードは、先に発行元で失効させ、パスワードジェネレーターでこの端末から6–128文字の新しい列を引いてください。既定は16です。8未満は弱いと出ます。これらの手順に、ログインは要りません。

よくある質問

メールがHTTPSなら、パスワードは宛先だけが読めますか？

いいえ。RFC 3207は、SMTPは端から端の仕組みではない、と書いています。1組のサーバがTLSを付けても、送信クライアントから受信者まで守ったことにはなりません。各区間は復号し、見て、次へ渡せます。送信済み、受信トレイ、サーバ上の保管は、既定で読める本文です。

双方がこのメールを削除したら、パスワードは消えますか？

残ることがあります。Gmailは削除をゴミ箱へ移し、約30日は戻せます。Exchange Onlineは完全削除のあと、回復可能なアイテムに既定14日、最長30日残します。Workspace管理者はゴミ箱の30日のあと、さらに約25日コンソールから復元できることがあります。訴訟ホールドはこの期限を無視します。組織が保管を開いていれば、管理者は本文を検索し、書き出せます。

Gmailの機密モードが切れたら、本文はシステムから消えますか？

受信者は、期限切れやアクセス取り消しのあと本文を開けません。送信側組織のVaultについては、Googleの日本語ヘルプ（情報保護モード）が、利用者が期限を付けたり受信者のアクセスを取り消したりしても、Vaultは組織内から出したそのメールを保持・検索・書き出しできる、と書いています。スクリーンショットと撮影は、同じ製品説明の対象外です。

どうしても同僚へパスワードを渡すとき、メールはまだ使えますか？

メールは、鍵を含まない通知か、すでに暗号文になった添付に向きます。本物のパスワードはワンタイムリンクで一度送り、鍵はURLの # フラグメントに置いてください。作成も閲覧も開いてすぐ使え、サーバが一時保存するのは暗号文だけです。同じ平文をメール本文へ重ねて書かないでください。

次のメールを書く前に覚える三つのこと

第一に、送信はディスクへ書くことです。送信済み、受信トレイ、同期端末、中継は、それぞれ読める本文を持てます。今のページを直しても、すでに入った複製は戻りません。第二に、削除は猶予を始めるだけです。Gmailのゴミ箱は約30日、Exchangeの回復可能なアイテムは既定14日、Workspace管理者はゴミ箱のあと約25日を持てます。企業の保管とVaultは別セットであり、利用者は消せません。第三に、機密モードと送信取り消しが止めるのは誤操作です。端から端ではありません。届ける本物の鍵はワンタイムリンクへ。漏れたパスワードは、先に失効させてから換えてください。

一度開いたあとサーバに何が残るかを続けるなら、ワンタイムリンクを一度開いたあと、サーバーに残るのは何かを読んでください。ハッシュの後ろの鍵がHTTPに入るかを照合するなら、URLのハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるときを読んでください。本文が扱うのは、「パスワードをメール本文へ書いたあと、送信済み、バックアップ、管理者側にまだ何が残るか」を、結論に書ける範囲へ落とすことだけです。