postfix TLS を修正するにはどうすればいいですか?

postfix TLS を修正するにはどうすればいいですか?

注記以下に記した内容はすべて教育的かもしれませんが、私の問題はすべて postfix ではなく、ISP に起因していることが判明しました。私は実際に問題の時期に ISP を変更しましたが、新しい ISP は暗号化されていない SMTP トラフィックを傍受して書き換え、STARTTLS を明示的に破壊していました。私はポート 465 で TLS のみの接続を設定することでこの問題を回避しました。


今日、STARTTLS は私のシステムで動作していました。システムを何ら変更していないのに、突然壊れてしまいました。数時間修復を試みていますが、成功していません。

サーバーに接続すると、次のようになります:

savanni@Orolo:~$ telnet apps.savannidgerinel.com 25
Trying 129.121.182.135...
Connected to apps.sasavanni@Orolo:~$ telnet apps.savannidgerinel.com 25
Trying 129.121.182.135...
Connected to apps.savannidgerinel.com.
Escape character is '^]'.
220 ***********************************************
ehlo dude
250-apps.savannidgerinel.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XXXXXXXA
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
^]close

telnet> close
Connection closed.

わかりました。明らかに、STARTTLS はこのリストに存在しません。そこで、設定ファイルを徹底的に調べ、チュートリアルをもう一度実行してみましたが、まったく役に立ちませんでした。これが私の tls 関連の設定です。

smtp_tls_CAfile = /etc/ssl/certs/savannidgerinel_com_CA.pem
smtp_tls_cert_file = /etc/ssl/certs/apps.savannidgerinel.com.pem
smtp_tls_key_file = /etc/ssl/private/apps.savannidgerinel.com.key.pem
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_tls_CAfile = /etc/ssl/certs/savannidgerinel_com_CA.pem
smtpd_tls_cert_file = /etc/ssl/certs/apps.savannidgerinel.com.pem
smtpd_tls_key_file = /etc/ssl/private/apps.savannidgerinel.com.key.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

tls_random_source = dev:/dev/urandom

すべての証明書ファイルが存在し、サーバーの秘密鍵が存在し、サーバーの CA が存在し、smtpd_scache.db ファイルと smtp_scache.db ファイルの両方が存在します。すべて postfix ユーザーがアクセスできます。そういえば、実行中のプロセスは次のとおりです。

savanni@apps:/var/lib/postfix$ ps aux | grep postfix
root      3525  0.0  0.1  25112  1680 ?        Ss   20:19   0:00 /usr/lib/postfix/master
postfix   3526  0.0  0.1  27176  1524 ?        S    20:19   0:00 pickup -l -t fifo -u -c -o content_filter= -o receive_override_options=no_header_body_checks
postfix   3527  0.0  0.1  27228  1552 ?        S    20:19   0:00 qmgr -l -t fifo -u
postfix   3528  0.0  0.4  46948  4144 ?        S    20:19   0:00 smtpd -n smtp -t inet -u -c -o stress= -s 2
postfix   3529  0.0  0.1  27176  1628 ?        S    20:19   0:00 proxymap -t unix -u
postfix   3530  0.0  0.3  38212  3176 ?        S    20:19   0:00 tlsmgr -l -t unix -u -c
postfix   3531  0.0  0.1  27176  1516 ?        S    20:19   0:00 anvil -l -t unix -u -c
postfix   3535  0.0  0.1  27188  1544 ?        S    20:20   0:00 trivial-rewrite -n rewrite -t unix -u -c

ログ ファイルには、次の内容を除いて TLS に関連する内容はまったく記載されていません。

Nov  6 02:19:45 apps postfix/master[3525]: daemon started -- version 2.9.6, configuration /etc/postfix
Nov  6 02:19:49 apps postfix/smtpd[3528]: initializing the server-side TLS engine
Nov  6 02:19:49 apps postfix/tlsmgr[3530]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Nov  6 02:19:49 apps postfix/tlsmgr[3530]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Nov  6 02:19:49 apps postfix/smtpd[3528]: connect from unknown[204.16.68.108]

syslogにもmail.errにも問題はありません。システム全体に関しては、すべて順調です。しかし、STARTTLSがないので、突然送信できなくなりました。どれでも電子メールは一切ありません。

ヘルプ???

答え1

main.cf から

詳細な TLS ログについては、以下を参照してください。 smtp_tls_note_starttls_offer = yes

コメントアウトまたは削除:

smtp_tls_CAfile = /etc/ssl/certs/savannidgerinel_com_CA.pem
smtp_tls_cert_file = /etc/ssl/certs/apps.savannidgerinel.com.pem
smtp_tls_key_file = /etc/ssl/private/apps.savannidgerinel.com.key.pem

「1 つ以上のサーバーにクライアント TLS 証明書を提示する必要がある場合を除き、クライアント証明書を構成しないでください。クライアント証明書は通常必要ありませんが、クライアント証明書がなくても正常に動作する構成では問題が発生する可能性があります。推奨される設定は、デフォルトのままにしておくことです。」

設定を再読み込みするか、postfix を再起動します。

サーバーをテストしました:

EHLO apps.savannidgerinel.com
250-apps.savannidgerinel.com
250-PIPELINING
250-SIZE 10240000
250-VRFY 250-ETRN
250-STARTTLS
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

提供されている250-STARTTLS。つまり、プロキシのような何かがポート25でトラフィックを傍受しているということだ。それは、ローカルコンピュータが接続する拡張機能を備えた、あらゆる種類のファイアウォールや高度なルーターである可能性がある。ファイアウォールや高度なルーターがない場合は、おそらく、ISPのIP範囲からのスパムを防ぐためのスパム対策ポリシーである。最悪の場合、誰かが中間者攻撃。

関連情報