return-pathとfromフィールドを比較するSpamassassinルール
最近、私が受け取るスパムのいくつかに繰り返しパターンがあることに気づきました。 return-pathヘッダーとfromヘッダーは常に同じ構造になっています。
例を挙げて説明しましょう。
Return-path: <[email protected]>
From: <[email protected]>
To: <[email protected]>
基本的に、Return-pathユーザー部分がFromユーザー部分と同じであるかどうかを確認したいのですが、To（ "@"が "="）に変更され、Toの前にダッシュが追加されています。
いくつかのPostfixheader_checksを使用し、USER=DOMAIN.COM@パターンを拒否したかったのですが、受け取った合法的なニュースレターのほとんどは、リターンパスにもそれを含んでいます（以前ははるかに複雑な文字列があり、フィールドから）。
誰かが以前にそのようなルールを作成し、共有したいと思ったことはありますか？
ありがとう！
SpamAssassinでは、ルールにコードを記述したり、変数を割り当てたりすることはできません。あなたがやりたいことをするために、あなたはカスタムプラグインを書くのに最も適しているでしょう（それはあなたにPerlへのフルアクセスを与えるでしょう）。
とは言うものの、ヘッダータイプALL（rawbodyルールのようにすべてのヘッダーを一度に検査する）を使用して、SpamAssassinルール記述構文内で要求していることを技術的に行うことができます。
header RPATH_EMBEDS_TO_ADDR ALL =~ /\bReturn-Path:[^\r\n]{0,99}-([\w.])=([\w.-]{1,99}\.[a-z]{2,8})\@(?:[^\r\n]{0,99}[\r\n]{1,9}){1,30}To:[^\r\n]{0,99}<\1@\2>/ism
上記のルールは高価であり、ユーザー名にダッシュを含めると、考えられるすべての長さにわたって反復する必要があるため、さらにコストがかかります。ユーザー名は([\w.-])です。これは、多くのバックトラックが必要なだけでなく、非常に長い文字列を調べる必要があるため、コストがかかります。また、Return-PathヘッダーがafterToヘッダーである可能性もあります。つまり、1秒必要です。その場合を処理するための2番目の正規表現のルール。
このテクニック用のカスタムSpamAssassinプラグインを作成する方がはるかに良いでしょう。
ただし、これが行うのは特定の種類のバルクメールをターゲットにすることであり、その多くは正当なものであることがすぐにわかると思います。 Return-Pathヘッダーは バウンスアドレス として使用され、多くのメーリングリストは、配信可能性を測定してリストをクリーンアップするために、受信者をエンコードします。
この種のものが本当に必要な場合は、正確なToアドレスがReturn-Pathヘッダーにあるアドレスであるかどうかは実際には問題ではないと思います。これが劇的により速いルールであり、ほぼ同じ効果があるはずです：
header RPATH_EMBEDS_ADDR Return-Path =~ /-[\w.]{1,99}=[\w.-]{1,99}\.[a-z]{2,8}\@/i
もう1つの大きな注意点は、メッセージがリダイレクトされるたびに（たとえば、電子メール転送サービス）、Return-Pathヘッダーが書き換えられることです。これにより、そのルールのスパム検出ユーティリティが制限される可能性があります。