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にしてます。

zvolのvolblocksize

netatalkでの共有を止めて、zvol+iSCSIへ移行したわけですが、どうにもディスク消費量が大きすぎるのが気になってました。

zfs create -sVにて疎ボリュームで作成したんで、使用したら使用した分だけディスク消費するようにしてました。

すると、実容量に対し管理領域なんかで数%ふえるのはあり得る話しだけども、2TBのファイル置くだけで2.6TBも消費していて明らかにおかしい…。

そんなわけで、volblocksizeを疑ってテストしてみました。

用意した1GBiの書込みファイル。
dd if=/dev/random of=test.data bs=1048576 count=1024

今回は-sオプション使わず、普通にzfs create -V 2Gで確保しました。

blocksizeUSEDREFER
8kB2.06G1.35G
16kB2.03G1.01G
32kB2.02G1.00G
64kB2.01G1.00G
128kB2.01G1.00G
iSCSI経由APFSでmacOSから1GBi書込み後のzfs listの値

FreeBSDでzvolを作成すると、デフォルトではblocksizeは8kBに設定されます。

しかし結果を見てみると、8kBだけ明らかにREFERの上昇が激しいです。

REFERは実際に消費されているサイズというより「書込みで使用済みとなったサイズ」なので、CoW的な動きされると「書込んだけど今は使ってない」領域が存在し、それらがカウントされているのかと思います。

それでも8kBだけこれだけ差があると、ちょっと気持ち悪い…。

blocksizeによる実際のディスク消費量の違いは、USEDの値を見るのが妥当なところかな。それでも8kBだと約3%と、ちょい多い。

パフォーマンスについては、下記のサイトで検証されていて、あんまり影響は無い模様。

っていうか、FreeNASでは16kBがデフォルトなんですね。

ディスクケチりたいので128kBにしたいところですが、なんとなくビビって64kBに設定してzvol作り直しましたとさ。

APFS自体がCoWっぽい振舞するので、zfsの疎ボリューム機能使っても無駄にしかならないので、ギリギリサイズで確保して都度、volサイズを拡張することにしました。

おまけ:zvol/iSCSI/APFS運用でのvolサイズ拡張について

ディスク容量が手狭なんで、必要最低限のzvol確保しておいて、足りなくなったらちょっとづつ拡張していく作戦。

試しに# zfs set volsize=2T hddvol/scsivolみたいな感じで拡張してみましたところ、dmesgにこんな感じのログが。

GEOM_PART: zvol/hddvol/scsivol was automatically resized.
  Use `gpart commit zvol/hddvol/scsivol` to save changes or `gpart undo zvol/hddvol/scsivol` to revert them.

GEOM_PARTがサイズの変更を感知して、GPTを修正するかどうか?って聞いてるっぽい。因みに無視して進めようとすると、zvolが使用中とかでアクセス出来ません。

gpart commit zvol/hddvol/scsivolって実行すると、良きに計らってくれるようで。

追記:2020/12/16

容量拡張時には、FreeBSD側でgpart commitしておかないと、Mac側でのボリューム拡張に失敗する模様。

パーティションテーブルもMacの管理下だろう…と、volmode=devとかしてFreeBSD側からのgeom通したパーティション操作禁止したら嵌まった…。

いまどき(2019)のsamba/freebsd/zfsacl事情

あれから6年。いまどきのSamba 4.8.7/FreeBSD11.2で確認してみたところ、概ね期待通りに動作するようになっているっぽいです。但し幾つか注意点は有るようで。

POSIX準拠パーミッションのみは使用しない

NFSv4ACLが指定されておらず、従来のPOSIX準拠パーミッション(以下パーミッション)しかないファイルをそのまま使うと、下記のようなことが起こります。

FreeBSD(Samba4)でファイルサーバを構築で、Windows側のパーミッションがおかしい

原因は、パーミッションのACLへの変換がいけてないため。

パーミッションしか無いファイルに対してACL取得要求が有ると、パーミッションをACLの形に変換するわけですが、Write属性はこんな風に変換されます。

from POSIX permission
-w-p--a-R-c--s:-------

一方で、WindowsからACLで書込みのみ可と設定すると、こんな感じに。

from Windows ACL
-w-p---A-W----:-------

パーミッションから変換されたACLは、Windowsから書込んだACLと比較すると、A[write_attributes]とW[write_xattr]が足りない。

すると、Windowsから見て「書込みに必要な権限が足りない=書込み出来ない」という解釈になるわけです。

つまり、パーミッションから変換されたACLがおかしい…と。しかし困ったことに、このACL変換ルールは、zfsの仕様みたいなんですよね。

FreeBSDはzfsの仕様通りにパーミッションをACLに変換し、sambaは仕様通りOSから取得したACLをそのまま返し、Windowsは受け取ったACLを正しく解釈して「書込み不可」と。どないせぇっちゅうねんw

ま、とりあえずは、Samba共有で使用するファイルに、全てWindowsが期待するACLを付与しておけば回避出来るんじゃ無いかと思います。継承はちゃんと動作しているっぽいんで。

macOSから使えない

所有者以外の書込み権限が付与されたファイルに対し、Microsoft officeで上書きすると書込み権限が無くなったり、ACLがおかしくなります。

macOSのcifsクライアントがACL理解しないため、書込み時にパーミッションとして書込み可を指定するため、先のいけてない変換ルールが逆にACLとして書込まれてしまいます。

netatalkで代用しようにも、zfsacl扱えない為、論外。

AppleはAFP捨ててCIFS推しみたいですが、ならもう少しきちんと実装してくれよ…と。