SMTPの暗号化を強制することは（まだ）良い考えですか？

メールを送受信するときに、可能であればTLSを使用するように現在設定されているメールサーバーを実行しています。

これについてのドキュメントを読むとき、TLSを実施し、電子メールのプレーンテキスト送信を受け入れないオプションもあります。また、一部のメールサーバーが暗号化をまだサポートしていない可能性があり、暗号化を強制するとこれらのサーバーがブロックされる可能性があることを警告します。

しかし、これはまだ考慮すべき問題ですか、暗号化を強制することはもう問題ではないと言うことは安全ですか？

おそらくこれをすでに行っている大手プロバイダーがいますか、または最近のベストプラクティスをどう思いますか？

実際的な問題は、すべてのSMTP準拠（RFCはかなり古い）サーバーがサーバーにTLSを話すことができないため、一部の電子メールメッセージを受信できない可能性があることです。

これに関する哲学的な問題は、メールがサーバーに到着した後（または到着する前）にどのようにリレーされるかを伝えることができないことです。

これは、電子メールがすでにリレーを介してプレーンテキストで送信されている可能性があることを意味します。

メールの内容の保護に真剣に取り組む人は、実際に本文を暗号化する必要があります。暗号化の途中で常にもっともらしいことは、すでに平文で送信されています。

したがって、SMTP層で暗号化を強制するという質問に答えるのは無意味であり、電子メールを見逃す可能性が高くなり、有益な見返りは保証されません。

編集：これは、電子メールの送信ではなく、リレーを目的としたSMTP施行を指します。メール送信では、実際のメールではなくSMTP会話に認証資格情報が含まれている可能性があるため、暗号化を実施する必要があります。

いや

RFC 821は33歳です。あなたはします STARTTLS notsupportingプログラムによって中継された電子メールを見つけます。時々、それらはスタブ電子メール送信者（例えば、内部スクリプト）であり、時には、古い完全なシステム、TLSが無効/コンパイルされていない、十分なエントロピーのないシステム…

受信側がSMTP over TLSのみを許可するように構成されていたため、発信メールが失敗するのはそれほど前ではありませんでした。これは送信側の問題でした（その構成を使用するべきではありませんでした）が、それが起こることを示しています。

手動で構成されたIPアドレスからの着信メッセージのみを制限します。クレジットカードプロセッサがSTARTTLSの起動に失敗した場合、おそらく（機密性の高い）データを暗号化せずに受信するよりも、接続を中止することをお勧めします（そして、ローカル管理者に警告してください）。アウトバウンドメッセージの場合、以前にSTARTTLSを使用してそのホストに接続したことがある場合は、安全でない可能性があるものとして扱い、それを再度安全に行わないようにすることができます。また、gmailやyahooなど、常に使用されることがわかっているSTARTTLSホストのリストがある場合もあります。

ありますhttps://www.eff.org/starttls-everywhereあなたは（？なければならない）自信を持っSTARTTLSの使用を強制することができたのSMTPサーバのリストを提供するプロジェクトが。

暗号化が不可能なピアからの電子メールを拒否することは、完全に無意味であり、おそらく積極的に有害です。

サーバーが提供するピアで日和見暗号化を行うように設定されている限り、利用可能な場合は暗号化、利用できない場合はプレーンテキストを介した電子メールの両方の長所を利用できます。

暗号化をサポートしていないサーバーがある限り、暗号化を義務付けるとは、単にあなたと通信できないことを意味します。良くないね。誰もがそれをサポートしたら、日和見暗号化と必須暗号化の間に違いはありません。

また、他の人が指摘しているように、ネットワーク上の暗号化とエンドツーエンドの暗号化はまったく異なるものであり、さまざまな脅威モデルに対応しています。2つを混同しないでください。

これは政策事項です。

一般に、TLSがインバウンドとアウトバウンドに適用される場合、ニーズを満たすために関係者によって合意された限られたドメインのセットに対して行われます（たとえば、ビジネスパートナーは会社間のすべてのメールを暗号化する契約を結んでいる場合があります）。

そのような合意が確立されていない限り、強制モードをオンにしないでください。

いいえ、それは非常に悪い考えです。

実際、判明したように、ほとんどのSTARTTLSサーバー/クライアントは、TLS接続がネゴシエートに失敗した場合、StartTLSなしで再試行アルゴリズムを実装しません。

そのため、オプションとしてSTARTTLSを宣伝しても、メールを取得（および送信）する可能性はすでに低くなっています！

検索するだけで、多くの人が* .protection.outlook.comクラスターによって処理されるMicrosoft Outlookドメインに電子メールを送信できないことがわかります。

TLSの使用時にMicrosoftから拒否されたSendmailメッセージ

理由：403 4.7.0 TLSハンドシェイクが失敗しました

上記の2つの投稿で提示された問題を要約するには：

• STARTTLSの有無にかかわらず、Outlookで処理されるホスト以外のホストにメールを送信できます。
• クライアント証明書なしでOutlookにSTARTTLSなしでメールを送信できます。
• または、長さゼロのクライアント証明書を使用して、
• ただし、Microsoftが好まない証明書ではなく、受信者のサーバーがSTARTTLSをアドバタイズする場合、失敗時にクライアント（クライアントモードで動作するサーバー）はSTARTTLSなしでメッセージを再送信しようとしません。

同様に、ホストがサーバーとして機能する場合、STARTTLSを有効にすると、制御外で同様の状況が発生する可能性があります。サーバーモードのサーバーがSTARTTLSを提供することをクライアントサーバーが確認すると、TLSのネゴシエーションを試みますが、ネゴシエーションが失敗した場合、彼らは単に待機し、同じステップを再試行し、メッセージが送信者に返送されるまで失敗し続けます！

そして、これはSTARTTLSランドのさまざまなドメインでかなり頻繁に発生します！

悲しいことに、過去にSTARTTLSサポーターだったのと同じように、私は日和見暗号化と考えられていたもののリスクのない広告に惑わされたことに非常に困惑しています。

STARTTLSを必要としないだけでなく、相互運用性を確保したい場合は、STARTTLSを完全に無効にすることをお勧めします。

私は日和見的TLSを使用するという考えに同意する必要があります。しかし、私もアイデアに追加する必要があります。しかし、ここでの私の提案は軽視されず、十分に考慮されていないため、判断を下す前に、添付のリンクから完全な議論を読んでください。

日和見的TLSを使用することは、断然広く最善のソリューションです。それに対する議論としてのMITM角度は赤いニシンです。結局、MHがコメントで述べたように、TLS接続を使用した「合法的な」SMTPでもMITMになり、メールクライアントの大半が証明書の検証に煩わされないため、エンドユーザーは賢明ではなくなります。 TLSを実行しているMTAの多くは、自己署名証明書を使用しています（少なくともDNSSECおよびTLSA / DANEを使用していない場合）。この要因およびおそらく他の要因の結果として、あなたと世界の両方がDANE / TLSAとDNSSECを実装しました。日和見TLSを実行している間、匿名diffie-hellmanも（PFSを使用しながら）有効にすることよりも優れています。少なくとも部分的ではないにしても、少なくとも部分的には、偶発的なオブザーバーから保護するトラフィックを暗号化するという事実によるものです。この構成をさらにサポートするには（私の構成よりはるかに詳細な説明が必要です）、Vixtor Dukhovniによるpostfixフォーラムのコメントを参照してください。http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

なぜViktorの提案を他の提案よりも引き継ぐことができるのかについて、彼は両方のDNSSECでIETFドラフトを書いたのに加えて、Postfix MTAのDNSSEC、TLSA / DANEコードと同様にTLSコードを書いたおよびTLSA / DANE。そのため、この件に関する彼の言葉は、おそらくほとんどの言葉よりもかなり大きな重みを持っていると思います。

お役に立てれば。

電子メールマーケティングの観点から見ると、TLSの使用は、配信チェーン全体で実装されていることがわかっている場合の優れた実践であり、安全です。ただし、セキュリティが最重要要件である場合、送信前に電子メール自体を暗号化することが最も安全なオプションです（たとえば、PGPを使用）。