メールサーバー間のメール転送が暗号化されないことが多いのはなぜですか？

多くの場合、ユーザーは安全なチャネル（HTTPS など）を使用して、Gmailなどの電子メールプロバイダーにアクセスするかどうかを選択できます。

ただし、私の知る限り、メールサーバー間の通信に関しては、ほとんどの電子メールは暗号化されずにプレーンテキストで転送されるため、ネットワーク上の誰でもコンテンツを読むことができます。

エンドツーエンドでメールが安全に送信されることをユーザーに保証する技術はありますか？暗号化がサポートされていないことをユーザーに知らせ、電子メールを引き続き配信するかどうかをユーザーに選択してください。

ただし、私の知る限り、メールサーバー間の通信に関しては、ほとんどの電子メールは暗号化されずにプレーンテキストで転送されるため、ネットワーク上の誰でもコンテンツを読むことができます。

正しい。HTTPと同様に、SMTPはデフォルトでプレーンテキストです。

最近では、多くのメールサーバーがSMTPのTLS（以前はSSLとして知られていました）をサポートしています。（これはGmailに含まれています。）しかし、それはHTTPと同じ問題を持っている[S]：よく知られているが発行した証明書のCAのコストのお金、および自己署名のものが無価値ある¹から保護するためのMITM攻撃。メールサーバーが受信者の証明書の厳密な検証を行う場合（Webブラウザーのように）、自己署名証明書または社内CAを使用しているサーバーへのメッセージの配信に失敗する可能性があります。そうでない場合、偽者ではなく適切なサーバーと通信していることを確認できません。

また、TLSはSMTPへの比較的最近の追加であるため、受信者のメールサーバーがTLSをサポートしている場合でも、送信者はTLSをサポートしていないか、デフォルトで無効になっている可能性があります。

¹（送信側サーバーがDANE（TLSA）をサポートし、受信側サーバーの管理者がDNSでTLSAレコードを公開する場合を除きます。これはめったに行われず、面倒です。）

エンドツーエンドでメールが安全に送信されることをユーザーに保証する技術はありますか？

最も一般的な2つの電子メールセキュリティ標準：

• OpenPGP、信頼の網に基づいており、無料で使用できます。オープンソースの実装はGnuPG（Windows用、Thunderbird用）であり、元のPGPは商用PGP Desktopに進化しました。

  Webベースの電子メールクライアントの場合、FireGPGは可能性がある - 畜生

• X.509インフラストラクチャに基づくS / MIME。ほとんどのデスクトップクライアント（Outlook、Thunderbird、Mail.appを含む）で実装されています。ただし、TLS / SSLと同じ権限ベースの構造のため、比較的人気がありません。署名付き証明書には費用がかかり、自己署名証明書は確実に検証できません。

どちらの場合も、暗号化では、受信者がすでにシステムを使用しており、キーペアを生成/取得している必要があります。（署名には、送信者のキーペアが使用されます。通常は、メッセージに署名して暗号化します。）

暗号化がサポートされていないことをユーザーに知らせ、電子メールを引き続き配信するかどうかをユーザーに選択してください。

通常、送信されたメッセージはキューに入れられ、ユーザーもMTAもネクストホップがTLSをサポートしているかどうかを知ることができません。メッセージが送信されるまで、ユーザーに確認を求める信頼できる方法はありません。（AFK、オフライン、スリープ、またはスクリプト/プログラムの可能性があります。メッセージを送信した場合は、できるだけ早く配信されるようにします。）

また、SMTPを使用すると、ネクストホップが最終的なものなのか、それとも別の場所にメールを中継するだけなのかがわかりません。バックアップMXがまったく異なるネットワーク上にあることは珍しくありません。

したがって。エンドツーエンドのセキュリティは、両側がOpenPGPまたはS / MIMEを使用している場合にのみ可能です。

実際の電子メールトラフィックは多くの場合暗号化（TLS）されますが、他にもいくつかの問題があります。

• HTMLメッセージを表示する一部のWebメールクライアントは、HTTPSを使用しますが、安全ではない場合があります。たとえば、HTMLのコードとデータの間に明確な分離はありません（視覚要素とjavascript->インジェクション攻撃）

  • ウェブメールは、ローカルコンピューターにダウンロードして保存するのではなく、サーバーにメールを保存します

• すべてのステップでTLS / SSLが使用されたかどうかを知る方法がありません。非常に小さなサーバーには適切な証明書がありません

  • 送信者は少なくとも、安全でないチャネルを使用した電子メールの送信を受け入れるか失敗するかを指定できる必要があります

• メールは、サーバーによって暗号化または暗号化されていないサーバーに置かれました

  • あなたと受信者の間のすべてのサーバーを信頼する必要があります

• 電子メールは任意のルートを使用して転送される可能性があり、信頼するサーバー（IPアドレス範囲、AS、国、ドメインなど）を指定することはできません。

• 大規模な電子メールサーバーは複数の異なる証明書を使用せず、十分な頻度でそれらを変更しません（？）

  • それらをブルートフォースする価値がある/可能性があります（USA / UKなどが試みたように？）

• 電子メールがいつ送信されたかを知るトラフィックと、受信者に関する情報（どのサーバーが相互に通信するか）を追跡することにより

  • ダークネットはこれらの相関を隠します

• opensslの実装は混乱でした

  • 多分バグがあります

• 証明書に署名する認証局に信頼する必要があります

彼らです。または非常に頻繁にあります。

SSLまたはTLSを介して。

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

または、あなたが本当に妄想しているなら、PGPまたはGPGがあります。