アカウント名:
パスワード:
作り直しを考えるのなら、DNSBLとして振舞うように仕立てると、ヘッダ解析しなくてもメールサーバが接続元IPアドレスを拾ってくれるし、負荷や管理対象絞込みの観点でもメールサーバとうまく分離できて幸せかもしれませんよ。
いや、組織内のローカルなDNSBLサーバって位置づけでいいじゃないですか。
メールサーバが参照するローカルなDBバックエンドサーバのひとつってことで、アカウントや設定情報を抱えたLDAPサーバと同じようなところに置けば。
読み返して勘違いに気づきました。
組織のボーダゲートウェイなメールサーバから中継されて受け取る自分のメールサーバにフィルタを仕掛けたいってことですか。 それならまあ確かにReceivedヘッダにしか情報がないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
バグレポート (スコア:3, 参考になる)
というのは、メール送信者IPアドレスを抽出する(NNIPF/PERL/header.plの中のmain'HeaderAnalysis)時に、メールヘッダの最初から走査して、Received:行の内、最後にMTAOBのリストに一致したものからメール送信者IPアドレスを抽出しているように見えます(違ったらすまん)。普通、Received:行は、新しいものが最初の方に来ますから、MTAOBのリストと一致するものの中で、一番古いものと一致することになります。
という事は、MTAOBのリストを知っているスパマーは、偽のReceived:行を紛れ込ませるこ
作り直すのなら (スコア:2, 興味深い)
作り直しを考えるのなら、DNSBLとして振舞うように仕立てると、ヘッダ解析しなくてもメールサーバが接続元IPアドレスを拾ってくれるし、負荷や管理対象絞込みの観点でもメールサーバとうまく分離できて幸せかもしれませんよ。
Re:作り直すのなら (スコア:1)
インターネットから引けるMXレコードに載ってるようなMTA向けであれば、おっしゃる通りだと思います。
Re:作り直すのなら (スコア:1)
いや、組織内のローカルなDNSBLサーバって位置づけでいいじゃないですか。
メールサーバが参照するローカルなDBバックエンドサーバのひとつってことで、アカウントや設定情報を抱えたLDAPサーバと同じようなところに置けば。
Re:作り直すのなら (スコア:2, 参考になる)
読み返して勘違いに気づきました。
組織のボーダゲートウェイなメールサーバから中継されて受け取る自分のメールサーバにフィルタを仕掛けたいってことですか。 それならまあ確かにReceivedヘッダにしか情報がないかな。