ホーム » 「postfix」タグがついた投稿
タグアーカイブ: postfix
spamhaus のDQSキー取得
spamhaus はパブリックDNSを拒否
自宅メールサーバでの運用で、spamassassin などの設定をしていても、迷惑メールがそれなりに届く。
傾向としては、Google や Amazon のクラウドサーバから、SPF や DKIM を正規に取得した使い捨てドメインから送られてくる。このため、OpenDMARC などを設定してもダメ。Gemini に聞いたら、使い捨てドメインからの RBL のデータベースが得意な、spamhaus を薦めてくれる。
ただ、spamhaus は、以前にも設定したけど問い合わせを拒絶されたので、設定から外していた。改めて確認すると spamhaus は、無料サービスだけど大量の問い合わせをさばききれないので、8.8.8.8 や 1.1.1.1 のような パブリックDNS を経由した問い合わせには、答えを返さない運用をしているらしい。私の拒絶経験もコレが原因。
んで、色々調べると、無償サービスだけどユーザ登録して DQS キーを使えば、パブリックDNS経由での問い合わせでも拒否されないらしい。(最初、ユーザ登録とか嫌いなので、パブリックDNSを使わないキャッシュDNSサーバを立てようか…とも思ったけどシステムが複雑になるだけ)
spamhaus のユーザ登録とDQSキー生成
spamhaus の登録ページにアクセス(Spamhaus DQS Sign Up )し、DQS キーの発行を行う。
postfix に登録
postfix の main.cf の smtpd_recipient_restrictions に 以下のように登録。xxx…xxx の部分に発行した DQS キーを記載する。
((( /etc/postfix/main.cf )))
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client xxxxxxxxxxxxxxxxxxxxxxxxxx.zen.dq.spamhaus.net=127.0.0.[2..11],
check_policy_service unix:private/policy-spf,
permit
追記 2026-05-07 spamhausの効果覿面
spamhaus を RBD に登録してから、効果覿面。使い捨てドメインからのメールがきれいさっぱり止まっていて、最近は spam なしが続いている。
dmarc=fail p=none の受け取り拒否
自宅メールサーバでは、Postfix + Postgrey + amavisd + OpenDMARC + Spamassassin で運用しているが、
From 偽装は OpenDMARC で reject などができるようになった。
しかしながら、spammer は dmarc=fail 判定されても相手にメールが届くようにするため、ポリシー p=none のドメイン名探し、そのドメイン名を From にして、しつこく何度も送ってくる。
特定ドメインの dmarc=fail, p=none は受け取り拒否
しかたがないので、Postfix の OpenDMARC判定後に Postfix の header_checks の機能で p=none で送られてきたドメインは REJECT するようにしてみた。
((( /etc/postfix/main.cf )))
header_checks = regexp:/etc/postfix/header_checks
((( /etc/postfix/header_checks )))
/^Authentication-Results:.*dmarc=fail.*p=none.*header\.from=monex\.com/ \
REJECT DMARC authentication failed for specific domain.
spammerは怪しいドメインを次々みつけてくる
header_checks で運用してたけど、spammer は次々と怪しいドメイン(p=noneのドメイン)を見つけてきて、すり抜けてくるメールを送ってくる。このままじゃ、header_checks ファイルを日々更新することになりそう。
しかたがないので、dmarc=fail, p=none は SpamAssassin で Spam スコアを上げて、迷惑メールに確実に落とすことを目標にしたほうが良さそう。
((( /etc/spamassassin/local.cf の末尾に追記 ))) # DMARC失敗 (p=none) を検知するルール header LOCAL_DMARC_FAIL_NONE Authentication-Results =~ /dmarc=fail \(p=none/ describe LOCAL_DMARC_FAIL_NONE DMARC validation failed with p=none score LOCAL_DMARC_FAIL_NONE 3.5 # (参考) DMARC失敗 (p=quarantine) の場合もスコアを上げたい場合 header LOCAL_DMARC_FAIL_QUAR Authentication-Results =~ /dmarc=fail \(p=quarantine/ describe LOCAL_DMARC_FAIL_QUAR DMARC validation failed with p=quarantine score LOCAL_DMARC_FAIL_QUAR 5.0
openDMARCの設定
gemini cli で設定確認
最近の自宅サーバでの暇つぶしは、gemini-cli を使って設定の見直し。
gemini が確認する際には、sudo 付きで systemctl restart やら LOGファイルにエラーが記録されていないか見たうえで、次々と問題点の提案&改善&実行してくれる。
openDMARCが動かなかった原因
んで、自サバで動かしているメールサーバで、メール受信時の確認として、openDMARC を導入しようとしてたけど、うまくいってなかった。そこで、「”/etc/postfix”を確認して、”/etc/opendmarc.conf”を確認して」を連発してみた。
openDMARC については、opendmarc のグループに postfix ユーザが含まれていなかったのが原因。
これで、受信メールの正当性チェックで spam が減らせるかな。
saslauthd のトラブル
saslauthdが起動しない
メールの送信機能が動いていない。色々と調べたら、”systemctl start saslauthd” を実行しても起動しない。
正確に言うなら、systemctl が終わらない。1,2分ほど待つとタイムアウトが発生して強制終了となっている。
# systemctl start saslauthd # --- 1,2分で強制終了となる # journalctl -xeu saslauthd # journalctl で確認できるとのメッセージがあるので The job identifier is 21448. 3月 15 08:51:27 xxxx saslauthd[33874]: : master pid is: 33874 3月 15 08:51:27 xxxx saslauthd[33874]: : listening on socket: /var/spool/postfix/var/run/saslauthd/mux 3月 15 08:51:27 xxxx systemd[1]: saslauthd.service: Can't open PID file /run/saslauthd/saslauthd.pid (yet?) after start: No such file or directory 3月 15 08:52:57 xxxx systemd[1]: saslauthd.service: start operation timed out. Terminating. 3月 15 08:52:57 xxxx saslauthd[33874]: : master exited: 33874 3月 15 08:52:57 xxxx systemd[1]: saslauthd.service: Failed with result 'timeout'. ░░ Subject: Unit failed
postfix の smtp認証の設定の影響
色々調べると、こちらの記事を見つける。
postfix の中で、smtpd の起動はデフォルト(非chroot)では、/var/run/saslauthd の中にパイプなどを作る。しかし、postfix で SMTP認証を使えるように設定するための設定では、smtpd を chroot で起動するために、/etc/default/saslauthd の中の設定で、/var/spool/postfix/var/run/saslauthd を使うように指定しないといけない。
((( /etc/default/saslauthd ))) # See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information. # See the saslauthd man page and the output of 'saslauthd -h' for general # information about these options. # # Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd" # Example for non-chroot Postfix users: "-c -m /var/run/saslauthd" # # To know if your Postfix is running chroot, check /etc/postfix/master.cf. # If it has the line "smtp inet n - y - - smtpd" or "smtp inet n - - - - smtpd" # then your Postfix is running in a chroot. # If it has the line "smtp inet n - n - - smtpd" then your Postfix is NOT # running in a chroot. OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
しかし、何らかの更新の中で 非chroot の /var/run/saslauthd を参照する設定となり、この中にパイプなどを作っても反応がないために、起動に失敗している様子。
ということで、元記事に書いてあるように、/var/spool/postfix/var/run/saslauthd を使わせるために、シンボリックリンクを設置する。saslauthd パッケージの更新で chroot 起動の判定が不十分なのではないかな。
# rm -rf /var/run/saslauthd # ln -sf /var/spool/postfix/var/run/saslauthd /var/run/saslauthd # systemctl start saslauthd
(追記) 次は Permission denied
無事に saslauthd は起動するようになったけど、次はパスワード認証が受け付けない。LOG を確認すると下記のエラーがでるようになった。
2024-03-15T11:59:10.543324+09:00 xxxxx postfix/smtpd[46317]: warning: xxxxxx[xxx.xxx.xx.xx]: SASL PLAIN authentication failed: generic failure, sasl_username=xxxx@xxxx.xxx 2024-03-15T11:59:10.560548+09:00 xxxxx postfix/smtpd[46317]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied
これまた、調べてみたけど /var/spool/postfix/var/run/saslauthd 配下のファイルのパーミッションが原因っぽい。
配下のファイルに、下記の制限を設定して無事にメールが出せるようになった。
# chmod -R +x /var/spool/postfix/var/run/saslauthd/
postfixの設定見直し
自宅サーバに届く迷惑メールの設定はそれなりにやってるつもりだけど、相変わらず届く。
迷惑メールの送信側も、DKIM や SPF といった迷惑メールに誤認されない対策をして送ってきている。そこで改めて postfix の設定を見直す。
RBLサイトの整理, 正引き・逆引きチェック
迷惑メール送信者のデータベース(RBL)の設定をしていたけど、all.rbl.jp, zen.spamhaus.org はサービスを停止しているようで、nslookup all.rbl.jp とかも失敗するし設定を削除。
Dynamic DNS サイトのような迷惑メールサイトからのメールを拒否するために、reject_unknown_reverse_client_hostname を設定していたけど、DKIM, SPF まで設定した迷惑メールサーバも多いので、設定をさらに厳しく reject_unknown_client_hostname に変更。
この設定を変更すると、逆引きと正引きが一致しない Dynamic DNS サイト(まさに自サイト tsaitoh.net はこの状態)からのメールを拒否することになる。しかし、迷惑メールの制限を強化したいし、身の回りの 逆引きと正引きが一致しない所からのメールは、smtpd_client_regexp で受信許可するようにしよう。
((( /etc/postfix/main.cf )))
smtpd_client_restrictions = permit_mynetworks,
check_client_access regexp:/etc/postfix/smtpd_client_regexp
- reject_rbl_client all.rbl.jp, # サービス停止
- reject_rbl_client zen.spamhaus.org, # サービス停止
reject_rbl_client bl.spamcop.net,
- reject_unknown_reverse_client_hostname, # 逆引きだけをチェック
+ reject_unknown_client_hostname, # IP->name->IPのチェックあり
permit
postgreyの更新トラブル
postgrey に更新があった(1.36-5.2 ⇒ 1.37-1)ため、外部からのメールが届かなくなり、設定の変更が必要となった。
postgrey trouble
職場で動かしている WordPress の2段階認証メールを自宅サーバに転送しているが、2段階認証のメールが届かなくなった。原因は、怪しいメールは一旦拒絶することで spam を拒否してくれる postgrey がうまく機能していないと思われる。
/var/log/mail.log を見ると、下記のようなエラーで postgrey が起動していない。
May 5 16:53:15 ...: warning: problem talking to server 127.0.0.1:10023: Connection refused
エラーを探すと /var/log/syslog に以下のメッセージを残して、postgrey 起動に失敗しているので、
May 5 17:11:53 ... postgrey[974882]: Option greylist-text requires an argument
/etc/default/postgrey の POSTGREY_TEXT のオプションをコメントアウト。
((( /etc/default/postgrey ))) - POSTGREY_TEXT="" + # POSTGREY_TEXT="reject by postgrey"
しかし、この変更後も職場からのメールが reject されている。
May 5 17:19:20 ... postfix/smtpd[975541]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 450 4.2.0 <t-saitoh@tsaitoh.net>: Recipient address rejected: reject by postgrey; from=<www-data@...> to=<...@...> ...
たぶん、職場のサーバは Azureで動かしているが、今回の更新による拒否判定が厳しくなったんだろう。仕方がないので、/etc/postgrey/whitelist_clients.local に、自分の管理している Azure サーバのIPアドレスを書き並べる
((( /etc/postgrey/whitelist_clients.local ))) xxx.xxx.xxx.xxx 職場のWordPressサーバのIPアドレス
でも、postgrey-1.37 の更新は本家の changelog を見ると 2016年 みたいだけど、debian パッケージでは随分遅れての 更新だな。手法的にも、もっと確実な、SPF とか DKIM の対応がすすんで、postgrey は時代遅れなのかな。自宅サーバでは、postgrey で reject しそうな接続元は GEOIP で SMTP 拒否しまくりだし、あまり役に立ってないかも。
postfix backward compatibility
今回のトラブルで改めて、postfix のエラーログを見ているとpostfixの再起動時に以下のようなメッセージが出ている。
May 5 19:06:07 ...: Postfix is running with backwards-compatible default settings May 5 19:06:07 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details May 5 19:06:07 ...: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
設定ファイルでは、compatibilty_level が 2 とかになっていたので、書いてある通り 3.6 に上げておく。
((( /etc/postfix/main.cf ))) compatibility_level = 3.6
逆引きできないホストからのメール拒否
自宅サーバのメールに、よくできた偽装メールが届く。
国別IPアドレスで接続制限しているから、それなりに拒否しているはずだが、今回の JCB を語った偽装メールは、From: が *.cn で、ホスト名は逆引きできない、国ドメインではアメリカの IP アドレスだった。
どちらにしろ、我が家に *.cn からのメールが届く段階でヤバい。
ということで、逆引きできないホストからの接続自体怪しいので、smtpd_client_restriction に、reject_unknown_client を加える。
さらに smtpd_sender_restrictions を追加。
# SMTP接続相手がRBL登録されていれば受け取らない
smtpd_client_restrictions = permit_mynetworks,
reject_rbl_client bl.spamcop.net,
reject_rbl_client all.rbl.jp,
reject_unknown_client,
permit
# 送信者が怪しいものは拒否
smtpd_sender_restrictions = permit_mynetworks,
reject_non_fqdn_sender,
reject_invalid_hostname,
reject_unknown_sender_domain
dovecot が動かない Let’s Encrypt 証明書問題
数日前から、iphoneで自宅サーバのメールを見ると証明書が有効期限切れとのエラーが表示される。パソコンから Thunderbird で見るのには影響がないようだ。設定を色々と確認しても改善しない。
/var/log/mail.log を見ると、”SSL issue: alert number 46″ などのエラーメッセージが残っていて、dovecot と合わせてググると、Let’s Encrypt のルート証明書が、2021/09/30 で切れるといった記事が見つかり、これが影響しているようだ。
dovecot の設定の修正
さらに検索すると、ようやく対応記事が見つかった。ssl_cert の cert.pem を fullchain.pem に替えるだけ。こちらの資料を見ても、dovecot とか postfix なら fullchain.pem を使うような説明がある。
((( /etc/dovecot/conf.d/10-ssl.conf ))) # ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/cert.pem ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem ((( restart dovecot ))) $ sudo systemctl restart dovecot
postfix の設定の修正
同じような設定は postfix も使っていたはず。試しに、iphone でメールを出そうとすると、dovecot と同じような証明書が信用できないとのメッセージでメールが送れない。
((( /etc/postfix/main.conf ))) # smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/cert.pem smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem ((( restart postfix ))) $ sudo systemctl restart postfix
サーバ原因不明のフリーズ
休みののんびりする中、自宅サーバがフリーズ。出先だったのでママが恐る恐るリセット。
普通に起動したけど、icinga, munin を見ても予兆の変な雰囲気は無かった。
自宅に帰って改めてフリーズ時間の履歴を見ると、以下のようなところで syslog が途切れていた。
Apr 29 09:49:53 perrine postfix/smtpd[1325089]: connect from unknown[185.143.xx.xx] ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
この後、このIPアドレスから以下のような接続が続いている。postfix の脆弱性でもあるのかな。侵入には失敗しているようだが、なんか不気味。あまりにも不気味だし、繰り返し login を試しているし、iptables で接続をブロックする。
Apr 29 10:27:08 perrine postfix/smtpd[1943]: connect from unknown[185.143.xx.xx] Apr 29 10:27:10 perrine postfix/smtpd[1937]: warning: unknown[185.143.xx.xx]: SASL LOGIN authentication failed: authentication failure
postfixのサーバ間暗号化
DKIM, DMARC などの設定をしていたが、gmail 宛のメールの状態を確認していたら、DMARC p=quarantine に変更したのを確認できたけど、サーバ間のメール転送で暗号化がされていない様子。
この手の暗号化はデフォルトで行われているものと思っていたが甘かった。
postfix に以下の設定を追加する。
(((/etc/postfix/main.cf ))) smtp_tls_security_level = may
上記の状態の確認をしていたけど、外部サイトと25番ポートで繋がるんだな。プロバイダのファイアウォールで OP25 などの対策で、smtp(25番ポート)って接続禁止で、starttls(587) とか、smtps(over SSL:465) とかを優先的に使うと思っていたけど、google さんの smtp と 25 番ポートと繋がるな…。




