暗号化された電子メール-素晴らしいことのようですね。問題はすでに解決しましたよね？ええと...私はそうは思いません、そして私は私が間違っていることを望んでいます！
私が何を求めているのかを理解するには、私が何を求めていないのかを理解してください。パブリックネットワークを介して送信されるメッセージを暗号化して署名する方法を求めていません。これは少し異なります。
専用のソフトウェアや暗号化されたポートフォワーディングを必要とせずに、電子メールクライアントが双方向で暗号化されたメールサーバーへのメッセージの読み取りと投稿の両方ができるメールサーバーを設定したいと思います。 -laSSH。
ここで重要なのは、local-delivery-agentを使用してコミュニティに電子メールを配信できる信頼できるメールサーバーがあることです。その後、通信のセキュリティを気にすることなく、同じシステムを使用するすべての人との間で電子メールを送受信できます。すべての受信者の公開鍵を使用してすべてのメッセージを暗号化する必要はありません。-代わりに、ここで話しているのは、クライアントからこのシステムへの暗号化された双方向通信だけです。
もちろん、パブリックメッセージは、通常のポート25プロセスを介して、暗号化されずに電子メールサーバーのすべての参加者に送信されます。それらは、暗号化されている場合とされていない場合があります。私たちはそれらについて心配していません。電子メールクライアントはどこからでも接続でき、サーバーシステム上の応答コードは、パブリックネットワークを介して既にプレーンテキストで送信されているにもかかわらず、読み取り用にそれらのメッセージを暗号化します...これだけ、DovecotのようなIMAPサーバーを暗号化することでかなり簡単に取得できます。
これに追加したいのは、接続された電子メールクライアントは、暗号化された電子メールをクライアントであるシステムに送り返すことができ、そのシステムは暗号化されていない外部にどこにでも転送できるということです。ローカルメールボックスの場合、メッセージはローカル配信エージェントを介して配信されます。そこに関係するキーはありません。この設計の利点は、信頼できない外部のシステムやネットワークに電子メールがさらされることがなく、配信がローカルの場合、個々のメッセージを暗号化するというポイントツーポイントの手間をかけずに、エンドツーエンドで効果的に保護されることです。より一般的な使用法。
現在のように、パブリックインターネット上のクライアントを介して内部ネットワーク内の人々のグループに安全なメールを送信することは不可能であるため、これは「神の送信」になります。
私が求めていることを別の言い方で表現すると、IMAP（およびPOP？）サーバーがすでに行っている暗号化の残りの半分を提供するパッケージを誰かが作成しましたか？信頼できないネットワーク上の離れたクライアントが引き渡すことができます-暗号化されたリンクを介して、暗号化されていない電子メールを相手側のサーバーにバインドしますか？
別の代替案が私に起こりました：暗号化された形式でメールサーバーとメールサーバーを通信するSMTP/ESMTPサーバーの暗号化。（同様に、クライアントは、httpsが機能するのと同じように、暗号化されたリンクを介して暗号化されていない電子メールを渡すことができるはずです。）そのようなパッケージを知っている人はいますか？これはそれほど良くはありませんが、電子メールアーキテクチャの重要な部分です...
これが今日存在しない場合は、そうする必要があります。
あなたの考え、ポインタなどをありがとう。
