SPFによるspam対策をしようとして挫折した話

SPF対策を思いついた経緯

SPFと言っても豚肉じゃ無いです。木材でもありません。Sender Policy Frameworkの略でSPAMメール対策の一種のほう。

近頃、とあるサイトの流出事故によってメインのメールアドレスにもSpamが来るようになりました。それらの中身を見たところ、差出人のアドレスを堂々と詐称。これならSPFではじけそうじゃない?と思ったのがきっかけ。

bsfilterで十分にフィルタリングは出来ているんですが、エラーメール返して「てめぇのSPAMなんぞ受け取らねぇぞ」とやりたいのです。

SendmailのSPF対応

ググってみたところ、思った以上に情報が少ない…。とりあえず参考になったのが以下の情報。

ちょっと古いですが、ちゃんとFreeBSDの情報。今ではspfmilterに関してはports化されてるので、pkg/portsからインストール可能です。

しかしこれ、設定ファイルも何も無い…。そもそもspfmilterの情報が非常に少ないと思ったら、ほぼほぼFreeBSD専用っぽい扱い。Linux界隈ではsmf-spfなるものが主に使用されているっぽいんですが、FreeBSDのportsには無し。

本当に設定必要ないのか?と思案…。

SPFの問題点

「転送メールやメーリングリストどうすんだ?」と今更ながらに気付く。特に、うちではfetchmail使っていくつかのアカウントのメールを集約してたりします。

調べてみるたところ、SRS(Sender Rewriting Scheme)という対策案はあるが、送信側で対策が必要なの上、MTAの改変も大変だそうで殆ど普及してない…と。

そのほかに有効な対策もないっぽい…詰んでるやん。

結局使えないSPF

転送メールを問題無く扱う為の手段が、現実的に機能してない為、結局受信側のチェックでは殆ど使用されていない…というのが現状っぽいです。

そのわりには「DNSにSPFを設定しましょう」的な記事が多いんですが、まぁ無駄と言うことですね。

今時はDKIMやDMARCなどの、メール自体に署名を付ける方向みたいです。ただ、まだSPFほど普及はしてないからもうちょっと時間がかかるかな…。

いまどきのSamba/freebsd/zfsacl事情(2021版)

ぶっちゃけ詳しいことはこっち↓を見てください、って感じで。

FreeBSD ZFS で Samba
https://www.nslabs.jp/freebsd-zfs-samba.rhtml

FreeBSD13でこの通り設定すれば、ようやく使えそうです。また、macOS Catalina(10.15.7)からのアクセス(excelでの上書き保存)も大丈夫っぽい?

相変わらずmacOSからは開いた共有のACLがさっぱり見えないんですが、試しに同じ設定を施した11.4の環境で試してみると、さっぱりダメダメ。12は知らない。

どうも、aclmode=passthroughを設定してもdiscardっぽい振る舞いをするみたい?

macOSからのアクセスでダメダメになるのは、このせいなんかな?unix extensionsはもちろんNoにしてます。

FreeBSDのPorts collection運用

FreeBSDにはpkgというパッケージシステムがあるんですが、更新が遅いのとmakeオプションを変えられないので長年Portsで運用してきました。

また、一時期portsのビルドが面倒になってpkg運用一本に切り替えようかともしたのですが、長期運用で少しづつ各パッケージのバージョンを上げていこうとすると、パッケージ間で参照しているライブラリのパッケージバージョンが不一致で、どちらかしかインストールできないなんて状態になったりで結局あきらめました。
※バイナリpkgが導入された直後の昔のことなんで、今は良くなってるんでしょうかね?

そもそもFreeBSDのports/pkgの更新も「portsコード→バイナリパッケージ(pkg)」の順番に更新される訳なんですが、このタイムラグが結構あって、最新のセキュリティパッチとか、ただでさえportsコードに取り込まれるのが遅かったりするので、pkgだと相当遅かったりします。

そんなわけでひたすらPorts運用一筋。教科書?に載ってないようなPorts運用のノウハウをちょっと書いてみたいと思います。

更新作業について

各パッケージは日々バージョンアップされていきます。昨今ではセキュリティ関連の更新が多く「安定稼働しているから」と、古いバージョンのまま放置するわけにもいきません。

そんなわけで定期的に各portsの、アップデート作業を行うのがPorts運用の基本となります。

とりあえず/usr/ports/UPDATEは読みましょう。大規模なアップデートが有る時に、必要な作業が載ってます。読んでないと嵌まることあります。

基本的にportupgradeを使ってます。rubyのいらないportmasterが好まれるようですが、あっちは良く分かりません。

portupgrade -R <port name>

とか、-Rオプションおすすめです。

依存パッケージも更新してくれるのですが、依存パッケージが古くてコンパイル通らないとか良く有るので。

make uninstall or pkg delete/make installとかすると、ちょいちょい大変な目に遭います。と言うのも、新しいPortsのビルドが通らないことが、困ったことに「結構良く」あります。

原因は様々ですが、その原因の一つが、以下に挙げる/usr/local/lib/comat/pkgだったりします。

/usr/local/lib/compat/pkgの管理

昔は共有ライブラリのバージョンを上げたら、ライブラリのI/Fが変わってて、依存しているパッケージが軒並み動作がおかしくなるなんて事がありました。

今では共有ライブラリのパッケージを更新すると、古いバージョンがこのディレクトリに置かれて、そして新しいバージョンがインストールされるようになっています。

それはそれで互換性の面でありがたいのですが、古いライブラリは自動的には消してくれないんですよね。さらに、残った古いライブラリが悪さして、別のパッケージのビルドが通らないなんて事も起こります。

ライブラリのパッケージ自体を削除しても、移動された古いライブラリはそのまま残ってしまうんですが、それが悪さをすることもしばしば…。

なので、定期的にチェックして手動で消す必要があります。

pkg shlib <shard library>

ってすると、その古いライブラリを参照しているパッケージを教えてくれます。依存しているパッケージを再ビルドすると新しいパッケージを参照するようになります。

それらのパッケージを一つずつ、portupgrade -fで再ビルドしましょう。全てのパッケージを再ビルドして、古いライブラリを参照しているパッケージが無くなったら、ようやく消すことが出来ます。

portupgrade -f `pkg shlib -qR <shard library>`

ってやって、一括してアップデートするのも手です。

それでも新しいportsがビルドできない

ports運用上の最大の障害がこれ。クリーンインストールなら問題なくても、長年アップデートを繰り返してきた環境だと、わりと遭遇します。

組み合わせると動かないパッケージがある

よく似た機能のパッケージで、普通はどちらかしか使わないのを両方入れてたら、それらに依存しているパッケージがビルドできないパターンがあります。

netatalkとavahi/mdnsあたりだったかな。

機能のかぶるパッケージが入ってないかチェックしましょう。

依存関係が機能不全

依存パッケージが入ってるのに「無い」って言われてビルドできなかったり、逆に無いのに自動的にインストールされずにビルドエラーで終わってしまうパターン。

ports側で依存関係が変わったりとか、パッケージの構成変更や、ports名の変更とかだったりします。

普通は/usr/ports/UPDATEをよく見てると注意喚起が載ってたりするんですが、載ってないこともあります。

関連するパッケージを一度消してから、再インストールすると上手くいくことが多いです。

それでもどうしてもビルド出来ない

まだ古いパッケージをアンインストールしていないなら、とりあえず待ちましょう。ports側で修正されることがあります。

依存関係を疑って、一度消しちゃった場合は、portsを古いバージョンに戻してビルドします。

そのために、portsはportsnapではなくSubversionで更新するのがおすすめです。該当するportsのディレクトリだけ古いバージョンに戻してビルドします。

いつの間にかFreeBSDのportsからdatabases/db6が消えていた

全てはOracleのせい。BerkeleyDBを買収した後、今年の6月くらいにはver.6は登録しないとダウロードできなくなった模様。結果としてportsから更新できず。

databases/db5を使えと。

いやまぁ仕方ないのは分かるんだけど、ports/UPDATEのログにも一切記述が無くてさっぱり分からねぇよ…。

portsのsubversionログ追っかけてやっと分かったんだけど。

BerkeleyDBに依存してるオープンソースソフトウェア、そのうち軒並み死亡するかBerkeleyDB外しが進むのか…。

結局、Oracleの買収っていつもオープンソース(競合)潰しだよなぁ。