web-dev-qa-db-ja.com

着信SMTPメッセージでSTARTTLSを要求することはまだ「間違っています」か

STARTTLS仕様 セクション5によれば、

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

ただし、この仕様は1999年に作成されたものであり、2014年を考慮して、ほとんどのSMTPクライアント、サーバー、およびリレーがSTARTTLSのなんらかの実装を備えていることを期待しています。

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

15
jackweirdy

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

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つの可能性のある手段を削除するので、実現可能な場合、つまり反対側もそれをサポートする場合は、それを使用することをお勧めします。

19
Joe Sniderman

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

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

10
Matt Sergeant