Postfixのheader_checksと動作

PC&FreeBSD

F&FのサーバにはPostfixがインストールしてある。
メールの送受信はこれが担っている。
Postfixの重要なお仕事として、楽天からの迷惑メール排除がある。
楽天は以下の文言を使って宣伝メールを送りつけてくる。

弊社からのメールを希望されない会員様へも重要なお知らせとして配信しております。
誠に勝手ながらこのお知らせメールの配信停止はいたしかねますので、何とぞご了承ください。

これさえ書けば何を送っても良いというのが楽天スタイルである。
逆にこの文言が書かれていたら、それは楽天からの迷惑メールだと判断できる。
ただし楽天以外からだと、本当に重要なメールが送られてくる可能性が高い。

最初はこの「~重要なお知らせ~」や件名で制御していた。
必要なメールの件名は最初に【楽天】が入り、迷惑メールの場合は最後に【楽天】が入る事が多いからだ。

しかしそんな苦労をしなくても、emberpoint.comを弾いた方が余程簡単だった。
ただしこれを拒否すると、ゆうちょ銀行からのメールも来なくなる。

もう少し綿密な制御を行おうと考えてメールのヘッダを見てみた。
楽天の場合は宣伝メールを排除されないように、送り主は全て同じになっている。
送り主は同じだが、Return-Path:は異なる。
そこで、これを検出してメールの受信を拒否しようと思った。

Postfixのheader_checksは、メールヘッダを調べる仕組みだ。
まずはheader_checksが使えるようにmain.cfを編集する。

# For details, see "man header_checks".
#
header_checks                   = regexp:$config_directory/header_checks
#mime_header_checks             = regexp:$config_directory/mime_header_checks
body_checks                     = regexp:$config_directory/body_checks
smtpd_sender_restrictions       = regexp:$config_directory/reject_sender

次にテキストファイルであるheader_checksを作成する。
中身は、メールヘッダーの書式になっていれば良い。
例えばSubject: testとなっているメールを拒否したければ次のように記述する。

/^Subject: test/ REJECT

リターンパスで拒否するにはこんな感じだ。

/^Return-Path: ichiba-info@bounce\.emagazine\.rakuten\.co.jp/ REJECT

.(dot)はエスケープしている。

これで動作するのだが、動作しない事がある。
最初は何がいけないのか分からず、トライアンドエラーで実験を繰り返した。
メールヘッダは次のようになっている。

Return-Path: <hogehoge@fnf.jp>
X-Original-To: korokoro@fnf.jp
Delivered-To: korokoro@fnf.jp
Received: from [192.168.1.xxx] 
Date: Fri, 17 Sep 2021 18:57:11 +0900
From: hogehoge <hogehoge@fnf.jp>
To: korokoro@fnf.jp
Subject: test
Message-Id: <20220119185711.62C8.22EB418@fnf.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.75.04 [ja]

test

なぜReturn-Path:でリジェクトできないのか?
試しに次のように記述してみた。

/^Return-Path:/ REJECT

これなら、メールヘッダの中にReturn-Path:の文字列が存在すればリジェクトされる。
しかし結果はダメだった。

Gmaliから送ればリジェクトされる、つまりReturn-Path:によるリジェクトは全く問題なく動作する。
しかしF&Fサーバから送ると引っかからない。
Yahoo!メールで試してみると、これも引っかからない。

メールヘッダの中にReturn-Path:が見つからないような動作なのだ。
ちなみに以下のテストでは正常にリジェクトされる事になる。

postmap -q "Return-Path" regexp:/usr/local/etc/postfix/header_checks

と言う事は、メールのヘッダがおかしい事になる。
そうは言ってもviでヘッダを見ても全然おかしくない。
GmailのヘッダもF&Fサーバから送ったメールのヘッダも同じだ。

見えない文字があるとか?
だったらこれでどうだ。

/R.*e.*t.*u.*r.*n.*-.*P.*a.*t.*h/ REJECT

しかしダメだった。
見えない文字が入っているわけではなく、文字がPostfixには見えないのだ。

Return-Pathがダメなのかと、その次の行のX-Original-To:にマッチさせようとしたがダメ、次の行のDelivered-To:もダメ、その次のReceived:はマッチした。
Received:より下にある文字列には全てマッチさせる事が出来た。

Postfixのバージョンは3.5.4で、OSはFreeBSD12.1-RELEASEである。

楽天spamのブロックは、Return-Path行を見ないでSender:行をチェックすることにした。
Sender:行は全ての送信主がそれを表示しているわけではないが、少なくとも楽天spamのメールにはこれがある。

もう一つ、楽天から来る不要メールには”X-Keywords: “の行がある。
なので、念のためこの行のあるメールもRejectしておく。

こうしてしばらく運用していたら、ご登録メールアドレス確認の願いというメールが来た。

メールが届かないからこのメールを出しているのだろうが、そもそもメールが届かないのでメールで通知する事に大きな意味は無さそうだ。
携帯電話宛のメールが届かないよ、だからPCのメールに出したよと言う意味もあるとは思うけど。

emberpoint.comはリターンメールは少なくなるように、日々spam送信を改善しているのだそうだ。
その一環としてのリターンメールチェックし、F&Fにはメールが届かない事からこのメールが送られてきたのだと思う。

にほんブログ村 その他趣味ブログ 電子工作へ
にほんブログ村

コメント

  1. noname より:

    Return-Path: X-Original-To: Delivered-To:
    このへんのヘッダは、メール送信元が送ってくるのではなく、
    受信したメールサーバー(つまりお宅様のPostfix)が、ローカル配信前に付加している、ということは理解されているのでしょうか。

    >見えない文字が入っているわけではなく、文字がPostfixには見えないのだ。

    header_checks のときには、これらのヘッダは、そもそも、無いのです。

タイトルとURLをコピーしました