SMTPの暗号化を強制することは（まだ）良いアイデアですか？
メールの送受信時に、可能であればTLSを使用するように現在設定されているメールサーバーを実行しています。
これについてのドキュメントを読むと、TLSを強制し、電子メールのプレーンテキスト送信を受け入れないオプションもあります。また、一部のメールサーバーはまだ暗号化をサポートしていない可能性があり、暗号化を強制するとこれらのサーバーがブロックされる可能性があることも警告します。
しかし、これはまだ考慮すべき問題なのでしょうか、それとも暗号化の強制がもはや問題にならないと言っても安全でしょうか。
すでにこれを行っているいくつかの大きなプロバイダーはありますか、またはあなたは最近何をベストプラクティスと考えていますか？
実際の問題は、すべてのSMTP準拠（RFCはかなり古い）サーバーがサーバーにTLSを話すことができないため、一部の電子メールメッセージを受信できない可能性があるということです。
これに関する哲学的な問題は、メールがサーバーに到着した後（または前に）にメールがどのように中継されるかを伝えることが不可能であることです。
これは、電子メールがすでにリレーを介してプレーンテキストで送信されている可能性があることを意味します。
メールの内容を保護することを真剣に考えている人は、実際に本文を暗号化する必要があります。暗号化が進行中の場合、常にもっともらしいことはすでにプレーンテキストで送信されています。
したがって、SMTPレイヤーで暗号化を強制するという質問に答えることはおそらく無意味であり、電子メールを見失う可能性が高くなり、有益な見返りは保証されません。
編集：これは、リレーの目的でのSMTP強制、つまり電子メールの送信notを指します。メール送信では、SMTP会話（実際の電子メールではない）に認証資格情報が含まれている可能性があるため、暗号化を適用する必要があります。
いいえ
RFC 821は33歳です。 STARTTLSをサポートしないプログラムによってリレーされた電子メールを見つけます。時には、それらはスタブのメール送信者（例：内部スクリプト）になることもあれば、古くて本格的なシステムであり、TLSが無効になっている/組み込まれていない、十分なエントロピーがないシステムである…
受信側でSMTP over TLSのみを許可するように構成されているため、送信メールが失敗するのはそれほど前のことではありません。これは送信側の問題でしたが（その構成を使用するべきではありませんでした）、それが発生することを示しています。
手動で構成されたIPアドレスからの着信メッセージのみを制限します。クレジットカードプロセッサがSTARTTLSの開始に失敗した場合、暗号化されていない（機密情報である可能性がある）データを受信するよりも、接続を中止（およびローカル管理者に警告して警告することができます）することをお勧めします。アウトバウンドメッセージの場合、以前にSTARTTLSを使用してそのホストに接続したことがある場合は、それを再び安全に行わないようにして、代わりに潜在的な侵害として扱うことができます。また、gmailやyahooなどの、常に使用されることがわかっているSTARTTLSホストのリストがある場合もあります。
https://www.eff.org/starttls-everywhere プロジェクトには、自信を持ってstarttlsの使用を強制できる（すべきか）smtpサーバーのリストが用意されています。
暗号化できないピアからの電子メールを拒否することは、完全に無意味であり、おそらく積極的に有害です。
サーバーがそれを提供する任意のピアで日和見暗号化を実行するように設定されている限り、暗号化が利用できる場合は暗号化し、利用できない場合は平文でメールを送信するという両方の利点を利用できます。
暗号化をサポートしていないサーバーがある限り、暗号化を要求することは、サーバーがあなたと通信できないことを意味します。それは良くないね。誰もがそれをサポートしたら、日和見的暗号化と必須暗号化の間に違いはありません。
また、他の人が指摘したように、ネットワーク上の暗号化とエンドツーエンドの暗号化は2つのまったく異なるものであり、異なる脅威モデルに対応しています。 2つを混同しないでください。
これは政策問題です。
一般に、インバウンドとアウトバウンドにTLSが適用される場合、それは、ニーズを満たすために当事者によって合意された限られたドメインのセットに対して行われます（たとえば、ビジネスパートナーは、会社間のすべてのメールを暗号化することに同意する場合があります）。
このような合意がない限り、強制モードをオンにしないでください。
いいえ、それは非常に悪い考えです。
実際、結局のところ、TLS接続がネゴシエートに失敗した場合、ほとんどの [〜＃〜] starttls [〜＃〜] サーバー/クライアントは、StartTLSなしではいかなる再試行アルゴリズムも実装しません。
そのため、オプションとしてSTARTTLSをアドバタイズしても、電子メールを受信（および送信）する可能性はすでに減少しています。
検索するだけで、*。protection.Outlook.comクラスターによって処理されるMicrosoft Outlookドメインにメールを送信できない多くの人が見つかります。
TLSの使用時にMicrosoftから拒否された送信メールメッセージ
理由：403 4.7.0 TLSハンドシェイクが失敗しました
上記の2つの投稿で提示された問題を要約するには：
- sTARTTLSの有無にかかわらず、Outlookで処理されるもの以外の任意のホストにメールを送信できます。
- クライアント証明書なしでSTARTTLSなしでメールをOutlookに送信できます。
- または長さがゼロのクライアント証明書
- ただし、Microsoftが好まない証明書ではなく、失敗した場合、クライアント（まあ、クライアントモードで動作しているサーバー）は、受信者のサーバーがSTARTTLSをアドバタイズする場合、STARTTLSなしでメッセージを再送信しようとしません。
同様に、ホストがサーバーとして機能している場合、STARTTLSを有効にすることを決定すると、同様の状況が制御外に発生する可能性があります。クライアントサーバーがサーバーモードのサーバーがSTARTTLSを提供していることを確認すると、TLSのネゴシエーションを試みますが、ネゴシエーションが失敗した場合、単に待機し、同じ手順を再試行し、メッセージが送信者に返送されるまで失敗し続けます！
そして、これはSTARTTLSランドのさまざまなドメインでかなり頻繁に発生します！
悲しいことに、以前はSTARTTLSサポーターであったのと同じように、日和見主義的な暗号化であると思われていたもののリスクのない広告に惑わされたので、今では非常に権利を剥奪されています。
STARTTLSを必要としないだけでなく、相互運用性を確保したい場合は、完全に無効にすることをお勧めします。
日和見TLSを使用するという考えに同意する必要があります。ただし、アイデアに追加する必要があるものもあります。いくつかは提案に邪魔される可能性がありますが、ここでの私の提案は軽くそして十分な検討なしでは行われないため、判断を下す前に、添付のリンクから完全な議論を読んでください。
日和見的TLSを使用することが、最善の解決策です。それに対する議論としてのMITMの角度は赤いニシンです。結局のところ、MHがコメントで述べたように、TLS接続を備えた「正当な」SMTPでもMITM化でき、大多数のメールクライアントが大多数の証明書と組み合わせて証明書を検証する必要がないため、エンドユーザーは賢くなりません。 （少なくともDNSSECとTLSA/DANEを使用していない場合は）TLSを実行しているMTAの中で自己署名証明書を使用しています。これと、場合によっては他の要因の結果として、あなたと他の世界の両方まで、はDANE/TLSAとDNSSECを実装していますが、日和見TLSを実行している間は、匿名のdiffie-hellman（PFSも使用している）も有効にしておく方が良いです。少なくとも一部ではないにせよ、偶然の観察者から保護するトラフィックを暗号化するという事実が原因です。この構成をさらにサポートするには（私のものよりはるかに複雑な説明があります）、Postfixフォーラムのこの投稿にあるViktor Dukhovniのコメントを参照してください： http://postfix.1071664.n5.nabble.com/ Disabling-Anonymous-Diffie-Hellman-td67965.html
Viktorの提案が他の提案よりも優れている理由について、彼は両方のDNSSECでIETFドラフトを作成したことに加えて、Postfix MTAのTLSコードとDNSSEC、TLSA/DANEコードを書いたおよびTLSA/DANE。そのため、この件に関する彼の言葉にはかなりの重みがあり、おそらくほとんどの言葉よりも重いと思います。
お役に立てれば。
メールマーケティングの観点から見ると、TLSの使用は配信のチェーン全体で実装されていることがわかっている場合に、優れたプラクティスであり安全です。ただし、セキュリティが最も重要な要件である場合、送信前に電子メール自体を暗号化することが最も安全なオプションです（たとえばPGPを使用）。