Shuriken 2018ならShuriken TLS設定ツールで対応できるのだが、2016なので繋がらない。 なので、stunnelで、rocky linuxのサーバにproxyを立てて、TLS 1.0 <-->TLS 1.2のバージョン変換をすることにした。 stunnelはwindows版もあるので、サーバーではなくPCそのものにインストール・設定してもつかえるかもしれない。
参考にしたのは、このページ。
stunnelはパッケージがあるので、dnf install -y stunnelでインストール。 設定ファイルは、/etc/stunnelにおけば名前はなんでも良いようだが、慣例にしたがってstunnel.confとした。記述内容は以下のとおり。

# /etc/stunnel/stunnel.conf # Log settings output=/var/log/stunnel.log service=stunnel # connect to sonet [TLS_proxy_connector] client = yes accept = 127.0.0.1:2525 protocol = smtp connect = mail.so-net.ne.jp:587 sslVersion = TLSv1.2 # connect from shuriken [TLS_proxy_listener] accept = 9025 protocol = smtp key = /etc/letsencrypt/live/jp-oota.net/privkey.pem cert = /etc/letsencrypt/live/jp-oota.net/cert.pem CAFile = /etc/letsencrypt/live/jp-oota.net/fullchain.pem connect = 2525

[TLS_proxy_connector]のセクションは、so-netへ接続させるためのもの。参考にしたページは証明書のverifyをしていたが、ルート証明書の指定と管理が面倒なのでverifyは行わないこととした。
sslVersionの設定は最初はしていなかったが、接続できなかったので追加した。 しかしながら、接続できなかったのは後述の「STARTTLSを使用」の設定の問題かもしれず、不要の可能性もあるが未検証。現時点では実害はないはずなので、そのまま。
[TLS_proxy_listener]のセクションは、shurikenからの接続を受けるためのもの。9025ポートでlistenして、2525ポートにforwardしている。 このポート番号は[TLS_proxy_connector]セクションのAcceptで受けているポートと合わせる必要がある。
証明書ファイル類は、letsenvryptでwebサーバ用に作成したものを指定した。 なので本当のファイル名はちょっと違し、メールサーバらしからぬFQDN。
また、firewallで不要なポートは閉じていたので、/usr/lib/firewalld/serviceに、9025ポートのservice定義を書いてfirewall-cmdでポートを開けた。

これで、shurikenのアカウント登録設定の「送信(SMTP)サーバの名前」にstunnelが動作しているサーバ名(SSL証明書と一致するもの)、「送信サーバのポート番号」に9025を指定し、「SSLを使用」を「する」に、「STARTTLSを使用」を「しない」にすることで、メール送信が可能になった。

ここを参考に、/etc/cron.daily/clamdscanを修正。

--- /etc/cron.daily/clamdscan.orig 2023-08-15 09:15:11.496374765 +0900 +++ /etc/cron.daily/clamdscan 2023-08-15 09:05:23.429737649 +0900 @@ -5,7 +5,7 @@ CLAMSCANLOG=`mktemp` QUARANTINEDIR=/tmp/clamdscan-quarantine-$(date +%Y%m%d) mkdir -p ${QUARANTINEDIR} -clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} / > ${CLAMSCANLOG} 2>&1 +clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} -fdpass / > ${CLAMSCANLOG} 2>&1 # ウイルス検知時、root宛にメール通知 if [ -z "$(grep FOUND$ ${CLAMSCANLOG})" ]; then

追加したのは、fdpathオプション。このオプションは、manによると、

--fdpass ファイルディスクリプタの権限をclamdに渡します。 これは、clamdが異なるユーザーとして実行されている場合に役立ちます。 ファイルをclamdにストリーミングするよりも高速です。local(unix)ソケット経由でclamdに接続されている場合にのみ使用可能です。

元ネタは英文だったので、ChatGPTに翻訳してもらった。

redhatの公式Kkowledgebaseにある通りではあるが、それだけでは足りなかったので。
一通りRedhatのナレッジの通りやった後、以下を追加。

/etc/rsyslog.d/ignore-systemd-session-slice.confに下線部を追加。

if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of" or $msg contains ".scope: Succeeded.") then stop

一応念のため、redhat公式にあるtestuserは、以下のような実際にログを参照して、それぞれUIDのユーザ名に、user@1000.service.dの1000の部分はログに残っているUIDに読み替えが必要です。

Starting User Manager for UID 1001...

ついでに、clamdのSelfCheck: Database status OK.も大量に出るので、rsyslogdで抑止。 以下の内容で/etc/rsyslog.d/ignore-clamd-session.confを作成して、rsyslogdを再起動。

if $programname == "clamd" and ($msg contains "SelfCheck: Database status OK.") then stop

Aug 12 21:32:42 XXXXXX named[1488]: REFUSED unexpected RCODE resolving 'p.adsymptotic.com/A/IN': 172.64.32.241#53

などというログが大量に/var/log/messagesに残るので対処した。 といってもキャッシュをクリアしただけ。 コマンドは，以下。

ちなみに、rndc ユーティリティーは、ローカルとリモートマシンの両方から named サービスの管理を可能にするコマンドラインツール。 参考にしたページは、rndcをrdncと記述していてしばらく悩んだ。

# rndc flush # rndc reload

原因は、Apache2.4 から権限の記述法が変更になったため。以下のように直す。

• “Order allow,deny”, “Order deny,allow”の記述を全て削除。
• “Deny from all” の場合は “Require all denied”に変更
• “Allow from all” の場合は “Require all granted”に変更