SPF、DKIM、DMARCのDNSレコードを公開すれば自サイトにスパムなどが来なくなるわけではありません。そうではなく、公開した情報をもとに他のサイトではあなたのメールアドレスで送られてきたものが本当にあなたのサーバから送られてきたのかどうかを検証できるようになるので、あなたのメールアドレスを騙るメール送信者からのメールを拒否できるようになります。その間接的な結果として、あなたが出すメールが他のサイトからスパムと間違えられる可能性が減ります。
つまり、上記のDNSレコードを公開しただけではご質問のようなメールは止まりません。上で述べたような検証などの対策を何もしていないからです。
#1
ひとつの方法としては、他のサイトと同様に外部から送られてくるメッセージをSPFやDMARCの情報に基づいて検証することが考えられます。これには追加のソフトウェアが必要になります。
いずれの場合も、自サイトを騙る送信者だけではなくほかのサイトを騙るものも拒否できます。
ただし、これらの送信認証技術は万能ではありません。単純にSPFやDMARCの結果だけに従うと受け取るべきメッセージを拒否してしまう可能性があります。そのため一般的にはホワイトリストを用意してメンテナンスする必要があります (特にメーリングリストなどで転送されてくるものは誤って拒否されがちです。このような場合はARCへの対応が必要ですがまだあまり普及していません)。
また当然ですが、スパム送信者自身が正しいDNSレコードを公開していればこれらの検証は無力です。
ですので通常は、これらの送信者ドメイン認証の検証結果だけを見てメッセージを拒否したり受け入れたりするのではなく、DNSブロックリスト (DNSbl) などほかのさまざまな指標を組み合わせて判定します。
#2
上記のようなものではなく、当面「自ドメインの送信者を騙るものだけを拒否できればいい」ということなら、Postfixの設定だけで可能だと思います。(書きかけ。しばらくお待ちください)
(つづき)
ちょっと考えすぎだったようで、次のようにしてできました。
reject_final_destinations.hash
1mail.example.org reject
2...
main.cf
1...
2smtpd_recipient_restrictions =
3 permit_mynetworks,
4 permit_sasl_authenticated,
5 reject_non_fqdn_recipient,
6 reject_unauth_destination
7 check_sender_access hash:/etc/postfix/reject_final_destinations.hash
8...
mail.example.org
は自分のドメインです。自分のドメインが複数あるときは行を追加します。
Postfix 3.x以降ならインラインテーブルを使って次のようにも書けると思います。
main.cf
1...
2smtpd_recipient_restrictions =
3 permit_mynetworks,
4 permit_sasl_authenticated,
5 reject_non_fqdn_recipient,
6 reject_unauth_destination
7 check_sender_access inline:{ mail.example.org = reject, ... }
8...
permit_mynetworks
で、自サイト内のリレーには制限がありません。
permit_sasl_authenticated
で、認証が成功したユーザによる送信も制限がありません (ただし、このままだと認証できたユーザはなりすましが可能なのでreject_sender_login_mismatch
などでチェックしたほうがいいと思いますが)。
- 最後の
reject_unauth_destination
でオープンリレーも防げています。
- このあとに今回のルールを追加しています。ここまででsenderが自分のドメインであるようなものは上のいずれかのルールでokになっているはずなので、このルールまでたどり着いたものはrejectします。
#3
上の#2で当初の目的は達しているのですが、設定内容について若干補足します。
-
smtpd_client_restrictions
、smtpd_helo_restrictions
、smtpd_sender_restrictions
、smtpd_recipient_restrictions
のルールはそれぞれコネクション確立、EHLO (HELO) コマンド、MAILコマンド、RCPTコマンドの実行時に評価されるように見えますが、実際はsmtpd_delay_reject = yes
(初期値ではそうなっています) のときは4つともRCPTコマンドの実行時に評価されます。
(この動作がデフォルトになっているのは、かつてRCPTコマンドより前で拒否しても気づかずに通信を続けようとするクライアントがあったためだそうです。今日でもこの動作は、スパム送信者からのメッセージを拒否する前に少しだけ時間を無駄にさせる〔=スパム送信の能率が落ちる〕という効果が期待できるので望ましいです。)
とにかく、上記4つのルールはsmtpd_recipient_restrictions
にまとめて書くことができます。
- ただし
check_client_access
で、テーブル引きの結果がOK
となる場合、それ以降のルールが無視されてしまいますから修正が必要です。OK
となるエントリは取り除くかDUNNO
に書き換える必要があります。
-
実は、smtpd_recipient_restrictions
に書いてあるreject_unauth_destination
は実行されません。Postfix 2.10以降、smtpd_relay_restrictions
が導入されてsmtpd_recipient_restrictions
の直前に実行されるようになりました。smtpd_relay_restrictions
の初期値はpermit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
であるため、オープンリレーの試みにはreject_unauth_destination
による永続的エラー (554) ではなくdefer_unauth_destination
による一時エラー (454) が返されます。554にしたいのなら修正が必要です。
-
上でも述べたように、permit_sasl_authenticated
だけでは認証成功したユーザがなりすましし放題ですから、reject_sender_login_mismatch
などを使って防ぐ必要があります。
結果として、つぎのようになります (3. は除く)。
...
# オープンリレーの試みを一時エラー (454) ではなく永続的エラー (554) で拒否する場合
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
#smtpd_client_restrictions =
#smtpd_helo_restrictions =
#smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access cidr:/etc/postfix/reject_client.cidr
reject_unknown_reverse_client_hostname
reject_invalid_helo_hostname
reject_non_fqdn_sender
reject_unknown_sender_domain
permit_sasl_authenticated
reject_non_fqdn_recipient
#reject_unauth_destination #上記参照
check_sender_access hash:/etc/postfix/reject_final_destinations.hash
#上行は Postfix 3.x以降では次のようにも書ける
check_sender_access inline:{ mail.example.org = reject, ... }
...