STARTTLS仕様セクション5によると：

公的に参照されるSMTPサーバーは
、メールをローカルに配信するためにSTARTTLS拡張機能の使用を要求してはなりません（MUST NOT）。このルール
は、STARTTLS拡張がインターネットのSMTPインフラストラクチャの相互運用性を損なうことを防ぎます。公的に参照されるSMTPサーバーは
、インターネットメールアドレスの右側のドメイン名について、MXレコード（またはMXレコードが存在しない場合はAレコード）にリストされているインターネットホストのポート25で実行されるSMTPサーバーです。。

ただし、この仕様は1999年に書かれたものであり、2014年を考えると、ほとんどのSMTPクライアント、サーバー、およびリレーにSTARTTLSの何らかの実装があると予想されます。

受信メッセージにSTARTTLSが必要な場合、どれくらいのメールが失われると予想できますか？

はい、それはまだ悪い考えです。

3つの理由：

1. あなたが引用したRFC（RFC 2487）は実際には現在の標準RFC 3207によって廃止されていますが、現在の標準は質問で引用したMUST NOTの文言を保持しています。

2. SMTPクライアントは、STARTTLSを実装する必要はありません。そうしないことはまったく許容できます。STARTTLSはより一般的になりつつありますが、完全に普遍的ではありません。

3. 理由1および2の結果、すべての着信接続でSTARTTLSが必要な場合、メールが失われます。

しかしながら：

サーバー-ルール。何らかの理由でメールを任意に拒否したい場合、または理由がない場合でも-それがあなたの権利と特権です。（ただし、必ずしも素晴らしいアイデアであるとは限りません）

サイドノート：

相互STARTTLS認証が必要な場合でも、STARTTLSを要求することでスパムを防ぐことはできません。スパマーは証明書を取得することもできます-または自己署名証明書を作成します。自己署名クライアント証明書を拒否すると、正当なメールも失われます。

STARTTLSはポイントツーポイント暗号化です。接続システムは引き続き電子メールの内容を読み取ることができます。実際のプライバシーが必要な場合は、OpenPGPやS / MIMEなどのエンドツーエンドのものが必要です。

とはいえ、STARTTLSはインターセプトまたはMITMの可能性のある1つの手段を削除するため、実行可能な場合、つまり反対側もサポートする場合に使用することをお勧めします。

Googleは、受信メールと送信メールの両方で、暗号化されたメールの割合に関するオープンな統計を保持しています。この情報は、実装する価値があるかどうかを判断する際に非常に役立ちます。

http://www.google.com/transparencyreport/saferemail/