検索条件
全4件
(1/1ページ)
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どうやら、外国のＷｅｂサイトにて Apple Mail クライアントの行儀の悪さが原因だという記事を見かけました。
しかしながら、接続元情報が一切出てこない上に、関連付けが出来る他の情報も無いため、断定しきれないですね。
「電子メールの送受信が出来ないという不満が出て来なければ、気にする必要無い」と結論付けていて、それはその通りとも言えますが、原因がハッキリしないエラーメッセージはあまり気分のよいものではないです。
Mac 環境での電子メール設定は、時折問い合わせを受けるものの、問題特定できない内容ばかりで都度悩むのですが、一方で、問い合わせ側の試行錯誤でいつの間にか解決してしまうので、成功事例みたいなものが共有できないんです。
かといって、手本を示すのと、検証の為だけにMac を買うということには絶対にならないので、悩ましいところですね。
2023/01/08(日)whois に障害？？
2023/01/08 17:45
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 追記〕
キャッシュＤＮＳ再起動したら復旧。。orz 何だったのだろう？？
2023/01/06(金)fml4 → fml8 へのアップデート
2023/01/06 5:00
本家のチュートリアルを見る限り、そんな印象は受けなかったので、本家のチュートリアルを参考に実施しています。
先ずは fml8 を新規インストールします。(2022/12/31(土) fml8 の新規インストール 参照)
fml4 既存ＭＬの fml8 移行の場合は、改めて fml8 で新規ＭＬ作成の必要は基本的に無しです。勝手に fml4 環境を上書きされることも無く、fml4 が既存でも問題はありません。
※ https://www.fml.org/software/fml8/ にて、チュートリアル → レシピ一覧 fml4 のＭＬを fml8 形式のＭＬへ変換する のリンクを辿っても閲覧出来ない。
チュートリアルページの下の方に
『II. fml のセットアップ～ＭＬの作成』の項目があって、その下の fml4 のＭＬを fml8 形式のＭＬへ変換する
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 で運用している、バーチャルドメインにおけるＭＬ一式を格納しているディレクトリを指定します。
既存環境に上書きされることはなく、fml8 環境設定ディレクトリに対応付けが設定されるのみです。
尚、これは該当バーチャルドメイン上に複数のＭＬがあっても、最初の一度だけ実施でよいです。
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 varmakefml mergeml にて、既存の fml4 で運用している、バーチャルドメインにおけるメーリングリスト個別ディレクトリを指定します。
makefml mergemlで、fml8 に適応したコンバートが行われます。
ファイル・ディレクトリ所有者が、一部 root になってしまうので、全て fmladmin (fml8 の実行権限ユーザ) に変えます。
postfix の場合、 /etc/mail/aliases /usr/local/etc/postfix/virtualtbl などにＭＬ関係の設定をしている場合は、必ず、それらを削除することを忘れないでください。
《※ 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> ### # 以下の５行に、@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> ### ----- 変更はここまで ----- ※ ＭＬごとの個別変更で、題名に通し番号を追加する（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 での運用が出来るようになりました。
このアップデートは、ＭＬ利用者側から見れば、特に利点はありません。
fml4 が運営側にとって、維持困難になってきているので、主な目的はその解消といったところですね。
2023/01/04(水)セカンダリメールサーバの再構築
2023/01/04 6:22
プライマリメールサーバの負荷が高く、応答が遅い時などもセカンダリメールサーバが活用される場面があります。
最近はセカンダリメールサーバを用意していない組織もあるようですが、弊社ではセカンダリメールサーバを備えています。
セカンダリメールサーバは、実は色々な構成があり、プライマリメールサーバのように、電子メールの発信のみを出来るようにしているものもあります。
弊社では、セカンダリメールサーバから電子メールの発信を出来るようにしていませんが、今回はプライマリメールサーバの負荷軽減目的で、明らかなコンピュータウィルスや、確実な spam メールを捨てる仕組みを設けました。
※ この図は、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"の１行を追加しておきます。
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... は、受信者から見ると２回出てくることになり、不自然なのでどうにかしたいのです。
バグなのか、設定の問題なのか、、、 困っているところです。