このサーバーで運用しているMailman 3のメーリングリスト参加者からどうも一部の会員にメールが届いていないのではないかという苦情。Mailman 3のバウンスログが/var/log/mailman3/bounce.logにあるのでチェックしてみると確かにぞろぞろとバウンスされたという記録が並んでいる。しかし、妙なことにその大半がgmail.comかhotmail.comのアドレスだ。これは、gmail.comがこのサーバーからのメール受け取りを拒否してるのではないか？しかし返ってくるエラーメールについてはMailman 3が自動で破棄してしまうため、実際にどう拒否されてるのか分からない。そこでサーバーから手動で自分のgmail.comなアドレスに向けてテストメールを送ってみると、その理由が判明した。
Reason: 550 5.7.26 This message does not pass authentication checks (SPF and DKIM both
つまるところ発信者認証であるSPFとDKIMのどちらでも発信元が認証できないとはなっから受け取ってくれないという挙動をgmail.comが始めたということらしい。SPFは発信元の情報をDNSのTXTレコードから検証してIPアドレスの比較を行って確認する仕組みで、DKIMはサーバーの公開鍵をこれまたDNSのTXTレコードから取得して、メールがその鍵で署名されているかを検証して確認する仕組みだ。後者はPostfixにさらに小細工をして通過するメールがすべてDKIMで署名されるようにする必要があってとても面倒だ。そこでSPFで認証するために必要な情報をDNSのTXTレコードに登録することにする。幸いなことにこのサーバーが利用しているダイナミックDNSはTXTレコードの書き換えに対応しているので、とりあえずSPFで解決することは可能なようだ。
さて、このサーバーは接続しているプロバイダーが非固定IPからのOutbound Port 25 Blockingを行っているために、SMTPサーバーが直接外部にメールを送信することができない。そこでASAHI-NETのメールサーバーをリレーサーバーにしてすべてのメールをASAHI-NET経由で送信している。なので、SPFレコードに書く内容もこのリレーサーバーが正しく認証されるようにしなければならない。
さて、gmail.comにSPFなしで送ったメールのエラー情報を見ると検証しようとした送信元IPアドレスがこのサーバーのFQDNからのSPF情報で検証できなかったとご丁寧に検証対象になったIPアドレスが記載されている。そこでこのIPアドレスを逆引きしてドメイン名を確認するとhsmtpd-dty.xpsmail.jpというFQDNのようだ。ここから順引きするとAレコードが5つ表示されて、そのうちの一つがエラー情報に書かれていたIPアドレスと一致していたので、ASAHI-NETのSMTPサーバーはAレコードの多重化でラウンドロビンしているタイプのようだ。
今度はこのhsmtpd-dty.xpsmail.jpのSPFレコードを調べてみよう。
dig hsmtpd-dty.xpsmail.jp TXT
これでTXTレコードからSPFの情報を取得できる。詳細はこうだ。
v=spf1 include:spf.xpsmail.jp ~all
どうやらSPFの情報は別のDNSレコードで一括して管理しているようだ。メールサーバーのIPアドレスはいつ変更されるか分からないので、それをカバーできるようなSPFレコードを別に用意してあるということだろう。実際、このspf.xpsmail.jpのTXTレコードを取得してみるとSPFにAレコードの参照がずらずらと書いてある。
ここまで分かれば、あとはこのSPFレコードをこのサーバーのTXTレコードに書き込んで取得できるようにしてあげれば問題ないはずだ。というわけで、このSPFをダイナミックDNSのTXTレコード更新ツールを使って書き込んでからキャッシュされた情報が消えるタイミングであるTTLに書かれた秒数が経過するのをじっと我慢して待つ。そして、おもむろに先ほどやった手動のgmail.comへのメール送信をやってみると、あにはからんや、無事にメールが届いたのでこの対処法で完了である。
やれやれ。(まだhotmail.comにも無事に届くかは確認できていないw)