すべての送信メールにTLSを適用するルールをProofpointで作成することを計画しています。受信者のSMTPサーバーがTLSをサポートしていない場合、ルールが機能し、メールがバウンスしていることをテストする必要があります。
問題は、TLSをサポートしていないSMTPサーバーをどこで見つけられるか、またはどのように作成できるかです。または、TLSを具体的に無効にできるSMTPサーバー?
どこを見ても見当たらなかった。
Proofpoint内で、外部ドメインへの手動メールルート(DNS/MXを上書きする)を設定して、SMTPのみを使用するようにする必要があります。 ESMTP。これを行うには、宛先の前に「SMTP:」を付けます。
gmail.com → SMTP:gmail-smtp-in.l.google.com.
これにより、新しい "EHLO"ではなく古いSMTP "HELO"が発行され、STARTTLSを実行できなくなります。 (これは、両方の側がプロトコルに準拠している必要があります。場合によっては、プレーンSMTP経由でSTARTTLSを試行することが可能です。)そのドメインに強制TLSルールがある場合、送信メールは失敗するはずです。
または、ネットワークソリューション、多くのTLSストリッピング/ MITMツール(例 striptls
)の1つを使用できます。これにより、トラフィックをインターセプトしてSTARTTLSがアドバタイズされないようにすることで上記と同等の機能を実行します/検出/有効化。
それ以外の場合、STARTTLSをサポートする最新のSMTPサーバーでは、RSA認証を必要とする暗号のセットのみを構成する場合(openssl ciphers -v aRSA
)ですがキーと証明書を構成しない場合、STARTTLSはサポートされません。
TLSと [〜#〜] starttls [〜#〜] の間には微妙な違いがあります。後者はプロトコル内アップグレードとして実行されます。SMTP交換内で「STARTTLS」動詞が発行され、次にTLSがネゴシエートされます(これがセキュリティ制限がある理由です)。
「通常の」TLSでは、TLSが最初に発生し、そのタイプのアップグレードをサポートするように拡張することなく、任意のプロトコルに使用できます。そこ です TLSを使用したSMTPの古い標準でしたが、ssmtpはその後smtpsを実行しました—キャッチされることはありません( STARTTLSを使用したHTTP のように)。 TCP/465上のSMTPS は RFC8314 で復活しましたが、SteffenがこれはMTA-to-MTA向けではなく、MUA(クライアント)送信用のみであることを指摘しています。
SMTPは手作業でテストできる本当にシンプルなプロトコルです! telnet
やnetcat
のような便利なツールがある場合は、コマンドを手動で入力するだけです。 Windowsを使用している場合は、[Windowsコンポーネントのインストールまたは削除]メニューからTelnetクライアントをインストールできます。 Linuxを使用している場合は、netcat -vC
(冗長性にはv
オプション、CRLF行末にはC
オプション)を使用することをお勧めします。
まず、接続を開きます。
nc -vC mail.example.com 25
or
telnet mail.example.com 25
次に、暗号化を使用せずにメールを送信してみます。
EHLO test
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Test
.
QUIT
単独で行の.
の後に、メールが配信のためにキューに入れられているというメッセージが表示されます。サーバーは外部ドメインから外部ドメインへの配信をほぼ確実に許可しないため、@example.com
を独自のドメインに置き換える必要があることに注意してください(これは オープンリレー になります)。
電子メールが受け入れられる場合、明らかに暗号化は強制されません。許可されていない場合、このプロセスのどこかにエラーメッセージが表示されます。
または、外部サービスを使用してテストすることもできます。 「smtp tester」または「starttls tester」をオンラインで検索すると、いくつかのサービスが見つかります。上位のいくつかの結果で有望に見える3つを見つけましたが、それらはTLSの実施をテストすることを明示的に主張していないため、その特定のテストも存在するかどうかはわかりません。