ぼくのかんがえたさいきょうのPostfix（設計編）

このブログが動いてるサーバのPostfixの設定について何回かに分けて書きます。それ自体がセキュリティ上のリスクであることは承知していますが、いくつか思うところがあって晒します。

ひとつはPostfixの設定方法を調べようとググってみるとわかりますが、それなりに古い記事が引っかかることも多く、必ずしも現状のトレンドに合わせたベストプラクティスではないという印象を抱いたということ。それから冴えたスパム対策を意識した内容のものがそんなに多くもないという2点ですね。

企業向けの利用だったりすると、Google AppsとかOffice365を使ったり、はたまたメール配信系のASPやクラウドサービスを使うというシチュエーションも最近はありがちだとは思いますし、古式ゆかしいMS Exchangeを使ってるとかも未だにあるとは思いますが、最新技術もそれなりに追っていかないといけなかったりもしながら、この辺の話については一家言あるつもりなので、それはまた別エントリーかな。

目指すのは意識高い系MTAの運用です。それなりにセキュリティとしてはガチガチの目論見なので、これで突破されるくらいなら世のPostfixのサーバはどこでも悪用されるんじゃないかという気はしますし。

さていくつかの前提や方針、というか要件定義に相当する事項を列挙します。

○ディストリビューションやパッケージ

・とりあえずDebian Jessieを想定。バージョンは2.11.3がターゲットで、その他のパッケージもJessieに準拠。

・インストールしてるパッケージとしてはpostfix,postfix-policyd-spf-python,opendkim,opendmarc,sasl2-bin,opensslなど。

Debian党なので、これらをまるっとaptitudeでインストールします。Ubuntuでも同等の設定で行けると思いますし、RedHat系でもよっぽどバージョンが古くなければ大丈夫だと思いますが、特にOpenDMARCとかSPF関連のパッケージがどういう構造なのかは未確認。

○想定するメーラー

・MUAはMac版のThunderbirdがターゲット。まあMac固有のことはないのでWindows版やLinux版でも動くとは思うけど。

まあSMTPSとIMAPSがそれぞれクライアント認証で使えるメーラーならなんでもOK。WindowsならThunderbirdとBeckyくらいは使えるかなと思ってる。Apple Mailもキーチェーンアクセスに証明書を突っ込めば行けるはずです。

○サーバ構成

・受信サーバ・送信サーバとメールを保存するサーバの全部入り。また他サーバへのリレーは考えません。

・今回は触れませんが、IMAP4での運用をメインにし、POP3は利用しません。

流量やユーザ数によってはこの辺を分散するアプローチはありだとは思いますが、そこまでの負荷はない想定。なおIMAP4はDovecotで受けています。またフォルダ分けはMUAではなくてProcmailでやってたりします。

○受信ポリシー（TCP25/SMTP）

・25番は外部から自ドメイン宛の送信のみのサービスとします。

・SMTP-Authを試みたり、存在しないユーザ宛はSMTPセッション中でRejectします。またIPアドレスやEHLOホスト名などでのブラックリストも運用できるようにします。

・またEHLO後にSTARTTLSを宣言し、SMTP over SSLに対応しているMTAからはSSLでの送信を受け付けます。

基本中の基本で、第三者リレーは許可しません。また特にGmailなど海外のサービスを中心にSSLでのメール送信をしてくれる場合がありますので、これはありがたくSSL通信で受け付けます。本来であればちゃんとした認証局の証明書を取得するべきですが、Gmailを始め今のところオレオレ証明書でも送信してきてるのでひとまずそれに甘えることにします。

○送信ポリシー（TCP465/SMTP over SSL）

・MUAからの送信接続は465番でSMTP over SSL with SMTP-Authとします。またSSLは自己認証局を立ててしかもクライアント認証を利用。

・送信量についてはあまり考慮しない。

外部への送信に関しては、超えるべきハードルを高めに用意します。クライアント認証を突破しないとそもそもセッションも張れないし、その後にはSMTP-Authも超えなくてはならないので、悪用される可能性は皆無に近いものと思います。ちなみに平常時はiptablesで送信元IPアドレスを縛ってたりもします。

送信量については考えません。むしろ実質的に一人利用なので、必要十分な感じに絞りたいところです。

○送信元認証など

・メール送信時はDKIM署名を付加します。またメール受信時はDKIM署名の検証結果をヘッダに追記させます。

・さらにDMARCの判定結果もヘッダに付記しつつ、統計情報を収集してレポートを送信できるようにしておきます。

・同時にメール受信時にSPF判定の結果も追記し、また一定条件を満たした場合はRejectします。

一昔前まではスパム対策といえばRBLとベイジアンフィルタだったと思いますが、これからの時代はSPFとDKIMとDMARCなんじゃないかなというのが個人的見解。この辺の技術には早めにしっかり対応しておきたいところです。ちなみにSPF判定をスパム除去の要素として使うと、かなりの量のスパムを減らすことができています。

○スパム対策

・スパムメールに対してはMUA側での判定に頼らず、極力MTA側で500番台エラーを返せるような運用を可能とする。

・それでも撃ち漏らしたものを一定数貯めてから、ヘッダ情報などでブラックリストに登録する。

・RBLやグレイリストはひとまず利用しない。受信メールを解析しながら、自前ブラックリストを簡単にやりくりできる枠組みとする。

メーラーでのスパム判定技術は進歩していますが、「迷惑メールフォルダに振り分けられる」というのは送信者側から見れば「（読まれるかどうかは別にして）とりあえず届いてる」という状況に変わりません。確実にそうだと言い切れる条件を満たしているのであれば、迷惑メールフォルダに入れるどころか、SMTPセッション中で500番台かせめて400番台のエラーを返して拒否してやるのが世のため人のためではないか、という信念によります。

ただそれと同時に誤判定リスクとどう向き合うのかというのも重要な側面ですので、その辺りはバランスの取れた運用をしていきたいところです。RBLやグレイリストを使うという手もありますが、幸いにして流量が少ないのと実質個人用でしか使っていないので、誤判定リスクや効率を考えると自力運用でいいかなと思います。企業などでユーザや流量が多い場合はそれなりに手軽で有用かなとも思いますが。

ちなみにしばらく運用してみると、迷惑メールに対してSMTPレベルで500番台エラーを返すようにしていると、継続的な送信は止まるという状況にぼちぼち遭遇しますので、迷惑メールに振り分けるよりは効果的なのかなと思っています。

前フリだけでこんなに長くなってしまいました。ただ新規にメールサーバを立てる人も漫然と構築をするのではなく、ちゃんとポリシーなどを決めてから立てた方が後々のためになるんじゃないかなと思います。

次回から具体的な設定の紹介に移ります。