2023/01/09(月)dovecot に謎のエラー

2023/01/08 18:21 サーバ運営・管理
このメールサーバのみに出る固有のエラーメッセージだが・・・
Jan  8 17:31:43 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:31:44 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:31:47 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:31:47 mx2 syslogd: last message repeated 1 times
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF
Jan  8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF
Jan  8 17:41:42 mx2 syslogd: last message repeated 3 times
Jan  8 17:51:42 mx2 syslogd: last message repeated 1 times
Jan  8 17:51:44 mx2 syslogd: last message repeated 6 times
どうやら、外国のWebサイトにて Apple Mail クライアントの行儀の悪さが原因だという記事を見かけました。
しかしながら、接続元情報が一切出てこない上に、関連付けが出来る他の情報も無いため、断定しきれないですね。

「電子メールの送受信が出来ないという不満が出て来なければ、気にする必要無い」と結論付けていて、それはその通りとも言えますが、原因がハッキリしないエラーメッセージはあまり気分のよいものではないです。

Mac 環境での電子メール設定は、時折問い合わせを受けるものの、問題特定できない内容ばかりで都度悩むのですが、一方で、問い合わせ側の試行錯誤でいつの間にか解決してしまうので、成功事例みたいなものが共有できないんです。

かといって、手本を示すのと、検証の為だけにMac を買うということには絶対にならないので、悩ましいところですね。

2023/01/08(日)whois に障害??

2023/01/08 17:45 サーバ運営・管理
本日 日本時間 17:00 くらいから、こんな感じ:
mx2-root[97]# whois basekernel.co.jp
whois: connect(): Operation timed out
mx2-root[98]# whois basekernel.co.jp
whois: connect(): Operation timed out
メンテナンス情報とか見当たらないし、こういう事態は初めて、、

〔2023/01/08 17:51 追記〕
 キャッシュDNS再起動したら復旧。。orz 何だったのだろう??

2023/01/06(金)fml4 → fml8 へのアップデート

2023/01/06 5:00 サーバ運営・管理
事前調査では、なんだか面倒くさそうな記述が結構多かったんですが、
本家のチュートリアルを見る限り、そんな印象は受けなかったので、本家のチュートリアルを参考に実施しています。
先ずは fml8 を新規インストールします。(2022/12/31(土) fml8 の新規インストール 参照)
fml4 既存MLの fml8 移行の場合は、改めて fml8 で新規ML作成の必要は基本的に無しです。勝手に fml4 環境を上書きされることも無く、fml4 が既存でも問題はありません。

https://www.fml.org/software/fml8/ にて、チュートリアル → レシピ一覧 fml4 のMLを fml8 形式のMLへ変換する のリンクを辿っても閲覧出来ない。
チュートリアルページの下の方に
『II. fml のセットアップ~MLの作成』の項目があって、その下の fml4 のMLを fml8 形式のMLへ変換する
https://www.fml.org/software/fml8/Documentation/ja/tutorial/mergeml.fml4to8.html のほうを参照ください。

とはいえ、本家のチュートリアルどおりでは成功しませんので、下記手順を参考にどうぞ:
※ fml4 → fml8 移行に関しては、root ユーザで実施するのが無難です。
# makefml newdomain example.com /var/mail/example.com/~ml
( makefml newdomain バーチャルドメイン名 バーチャルドメインML 格納ディレクトリ )
既存の fml4 で運用している、バーチャルドメインにおけるML一式を格納しているディレクトリを指定します。
既存環境に上書きされることはなく、fml8 環境設定ディレクトリに対応付けが設定されるのみです。
尚、これは該当バーチャルドメイン上に複数のMLがあっても、最初の一度だけ実施でよいです。
23/01/06 00:43:01 makefml[1766] warn: /var/mail/example.com/~ml already exist. reuse it.
といったメッセージが出ますが、このメッセージは無視して大丈夫です。
次に、
# makefml mergeml ml-name@example.com /var/mail/example.com/~ml/ml-name
# cd /var/mail/example.com/~ml/ml-name
# chown fmladmin *
# chown -R fmladmin var
makefml mergeml にて、既存の fml4 で運用している、バーチャルドメインにおけるメーリングリスト個別ディレクトリを指定します。
makefml mergemlで、fml8 に適応したコンバートが行われます。
ファイル・ディレクトリ所有者が、一部 root になってしまうので、全て fmladmin (fml8 の実行権限ユーザ) に変えます。
postfix の場合、 /etc/mail/aliases /usr/local/etc/postfix/virtualtbl などにML関係の設定をしている場合は、必ず、それらを削除することを忘れないでください。
《※ postfix の設定を変更》
# vi /usr/local/etc/postfix/main.cf

《下記の例のように、alias を追加》
alias_maps = hash:/etc/mail/aliases
             hash:/var/mail/example.com/~ml/etc/mail/aliases

virtual_alias_maps = hash:/usr/local/etc/postfix/virtualtbl/forwardlist
                     hash:/var/mail/example.com/~ml/etc/postfix/virtual
# vi /etc/mail/aliases
《下記を追加》
fmladmin:       root

《追加後、下記を実行》
# newaliases
上記、makefml mergeml の実行で、雛形ファイルが自動生成されますので、それを流用します。
ただし、そのままでは使えないため、一部変更します:
# cd /var/mail/example.com/~ml/etc/postfix
# vi virtual
----- 以下、変更 -----
# example.com is one of $mydestination
# CAUTION: DO NOT REMOVE THE FOLLOWING LINE.
# example.com     example.com         ← コメントアウトまたは削除

### <VIRTUAL test-ml@example.com ML> ###

# 以下の5行に、@realmx.example.jp (postfix main.cf で指定の myhostname で示す実ホスト名)を追加
test-ml@example.com               test-ml=example.com@realmx.example.jp
test-ml-ctl@example.com           test-ml-ctl=example.com@realmx.example.jp
test-ml-request@example.com       test-ml-request=example.com@realmx.example.jp
test-ml-admin@example.com         test-ml-admin=example.com@realmx.example.jp
test-ml-error@example.com         test-ml-error=example.com@realmx.example.jp

### </VIRTUAL test-ml@example.com ML> ###
----- 変更はここまで -----

※ MLごとの個別変更で、題名に通し番号を追加する(makefml mergeml を使用しても、環境によっては引き継がれない設定がある。弊社環境ではこれが発生した)

# cd /var/mail/example.com/~ml/text-ml
# vi config.cf

----- 以下を、変更または追加(位置的には =cut 行の前) -----
article_header_rewrite_rules += rewrite_article_subject_tag
article_subject_tag = [$ml_name:%05d]
----- 変更はここまで -----
※ この設定で[test-ml:12345] みたいなのがメールタイトルの先頭に自動追加されるようになります。

# postmap hash:virtual
# postfix reload
これで、元通り fml8 での運用が出来るようになりました。
このアップデートは、ML利用者側から見れば、特に利点はありません。
fml4 が運営側にとって、維持困難になってきているので、主な目的はその解消といったところですね。

2023/01/04(水)セカンダリメールサーバの再構築

2023/01/04 6:22 サーバ運営・管理
セカンダリメールサーバは通常、利用者に開放しているメールサーバ(通常、プライマリメールサーバと称す)が不意にサービス不能状態になった時や、メンテナンス等で一時停止した際など、外部からの電子メールを代わりに且つ一時的に受け取るメールサーバです。
プライマリメールサーバの負荷が高く、応答が遅い時などもセカンダリメールサーバが活用される場面があります。

最近はセカンダリメールサーバを用意していない組織もあるようですが、弊社ではセカンダリメールサーバを備えています。
セカンダリメールサーバは、実は色々な構成があり、プライマリメールサーバのように、電子メールの発信のみを出来るようにしているものもあります。

弊社では、セカンダリメールサーバから電子メールの発信を出来るようにしていませんが、今回はプライマリメールサーバの負荷軽減目的で、明らかなコンピュータウィルスや、確実な spam メールを捨てる仕組みを設けました。
20230103.png

※ この図は、Postfix やメールサーバの構成をそのまま示した図ではありません。

受信メッセージの流れを中心とすると、上記のように感じかなと考えています。
milter-manager で受信メッセージのコンピュータウィルス検査と spam チェックを行います。
実はこれ、Postfix のオンラインマニュアル等を読んでもどうもよく判らないんです。たぶん、こんな感じかなという想像図。。
「outbound」というのは、プライマリメールサーバなどへ送信する場面を想定しています。

上記セカンダリメールサーバ固有の設定

先ず、spamassassin を milter インタフェースで動作させるために、spamass-milter を導入します。
一応、http://savannah.nongnu.org/projects/spamass-milt/ が公式サイトのようで、ダウンロードも出来ますが、永らく更新されておりません。
Ver 0.4.0 をダウンロードしてインストールしましたが、Ver 4.0.0 の spamassassin との組み合わせでも使えるようです。
# tar xvzf spamass-milter-0.4.0.tar.gz
# cd spamass-milter-0.4.0
# setenv CPPFLAGS '-I/usr/local/include -I/usr/include'
# setenv LDFLAGS '-L/usr/local/lib -L/usr/lib'
# ./configure --localstatedir=/var
# gmake
# gmake install
とすると、インストール完了です。
milter 形式だと、サーバ単位での spam 判定になってしまうため、少し緩め閾値で spamassassin の挙動を設定しておきます。
サーバ単位での spamassassin の設定は、/etc/mail/spamassassin/local.cf で設定します:
※ /etc/mail/spamassassin/local.cf の内容(変更部分のみ抜粋):

rewrite_header Subject
report_safe 0
required_score 17.0
経験上、閾値 17.0 では、殆どの spam は通過してしまいます。15.0 未満が妥当ですが、運用しながら、様子見で少しずつ下げていくようにします。

以下、FreeBSD 固有の環境になりますが、下記のスクリプトを /usr/local/etc/rc.d 配下に spamass-milter と言う名前で作成しておきます:
#!/bin/sh

# PROVIDE: spamass-milter
# REQUIRE: LOGIN
# BEFORE: mail
# KEYWORD: shutdown

#
# Add the following lines to /etc/rc.conf to enable spamass-milter:
#
#spamass_milter_enable="YES"
#
# See spamass-milter(8) for flags.
#

. /etc/rc.subr

name=spamass_milter
rcvar=spamass_milter_enable

command=/usr/local/sbin/spamass-milter
required_dirs=/usr/local/share/spamassassin

start_postcmd=start_postcmd
stop_postcmd=stop_postcmd

start_postcmd()
{
  sleep 1

  /usr/sbin/chown ${spamass_milter_socket_owner}:${spamass_milter_socket_group} ${spamass_milter_socket}
  /bin/chmod ${spamass_milter_socket_mode} ${spamass_milter_socket}
}

stop_postcmd()
{
  rm -f ${spamass_milter_socket}
}

load_rc_config $name
: ${spamass_milter_enable="NO"}
: ${spamass_milter_socket="/var/run/spamd/spamass.sock"}
: ${spamass_milter_flags="-f -p ${spamass_milter_socket} ${spamass_milter_localflags}"}
: ${spamass_milter_socket_owner="spamd"}
: ${spamass_milter_socket_group="mailuser"}
: ${spamass_milter_socket_mode="660"}

run_rc_command "$1"
※注:このスクリプトは Postfix のみの対応です。sendmail が MTA だと、不具合起こすと思います。

上記スプリプトに実行権を与え、更に /etc/rc.conf へ
spamass_milter_enable="YES"
の1行を追加しておきます。

ClamAV と、milter-managerも、インストールしておきます。過去記事を参考にしてください。
milter-manager をインストール後、
# /usr/local/sbin/milter-manager -u milter-manager --show-config
とやってみて、
define_milter("clamav-milter") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44
  milter.connection_spec = "unix:/var/run/clamav/clmilter.sock"
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
  milter.enabled = true
  # default
  milter.fallback_status = "accept"
                  ・
                  ・
                  ・
define_milter("spamass-milter") do |milter|
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44
  milter.connection_spec = "unix:/var/run/spamd/spamass.sock"
  # default
  milter.description = nil
  # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37
  milter.enabled = true
  # default
  milter.fallback_status = "accept"

といった表示がされるのを必ず確認しておきます。

最後に、Postfix 側の設定で、milter と関連するもののみ抜粋すると、
milter_protocol = 6
milter_default_action = accept
milter_mail_macros = {auth_author} {auth_type} {auth_authen}
smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock
non_smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock

transport_maps = hash:/usr/local/etc/postfix/virtualtbl/transport.map
header_checks = pcre:/usr/local/etc/postfix/header_checks
※ /usr/local/etc/postfix/virtualtbl/transport.map の内容:

example.jp                 smtp:[primary1.example.net]
example.net                smtp:[primary2.example.net]

※ /usr/local/etc/postfix/header_checks の内容:

/^From:\s*<>/m                  DISCARD
/^X\-Spam\-Flag:\s+YES/m        DISCARD
/^X\-Virus\-Status:\s+Yes/m     DISCARD

/^X\-Spam\-Level:/m             IGNORE
/^X\-Spam\-Checker\-Version:/m  IGNORE
/^X\-Spam\-Status:\s+No/m       IGNORE
/^X\-Virus\-Scanned:/m          IGNORE
/^X\-Virus\-Status:\s+Clean/m   IGNORE
のような感じ。
# postmap hash:/usr/local/etc/postfix/virtualtbl/transport.map
を忘れずに実施しておきます。

上記の、/usr/local/etc/postfix/header_checks の簡単な説明ですが、
「DISCARD」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「配信しました」と送信元に返答しつつ「メッセージを捨てる」という処理を行い、
「IGNORE」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「そのヘッダ行は削除して最終配信先へ送る」という処理を行います。
このファイルに記述された内容は、上から下へ順番に処理しますが、「DISCARD」で記述した行は、「そこで打ち切る」という挙動になるらしいです。

この構成で稼働させているが・・・

どうやら、header_checks の設定が上手く反映できていないみたいなのです。
IGNORE で「ヘッダ行削除」の挙動がどうも上手く行っていない模様。
X-Virus.... は上手く行っているが、 X-Spam.... が上手く行かない。。

取り敢えず実害はないのですが、セカンダリメールサーバ経由で受信したメッセージは、
X-Spam... は、受信者から見ると2回出てくることになり、不自然なのでどうにかしたいのです。
バグなのか、設定の問題なのか、、、 困っているところです。