SpamAssassinの代わりにRspamd：最新のスパムフィルターを適切に比較する

スパムフィルターの目標と避けられない誤判定

メールスパムフィルターは、技術的および内容的な特徴に基づいて、メールフロー内のメッセージを評価します。これには、製品によって異なりますが、送信者や認証データ、ヘッダー、URL、メッセージ本文、HTML構造、統計的分類、外部照会などが含まれます。 その目的は、メールの真偽を判断することではなく、配信リスクを明確に評価することにあります。 Rspamd このため、同様に多数の検査モジュールを統合し、その結果を意思決定の資料としてまとめることができます。

この際、いくつかの手順は別々に処理される必要があります。MTAはまずSMTPメッセージを受け入れるか、転送中にそれを拒否します。その後、フィルタは統合の過程で、あるいは統合後にスコアを算出します。例えば、マークがヘッダーに追加されたり、下流のルールによってメッセージが迷惑メールフォルダに移動されたりします。 一方、拒否は受信そのものを打ち切るものであり、単なるより強いマーク付けではなく、最も重大な措置となります。

A 誤検知 これは、正当なメッセージが誤ってスパムとして分類されてしまうケースを指します。例えば、サプライヤーからの本物の請求書であっても、PDF添付ファイルや支払請求、あるいは見慣れない送信ドメインなどが原因で、複数のチェックがトリガーされることがあります。 単にマークされるだけなら、受信者はまだそのメールを見つけることができますが、拒否されてしまうと、メールボックスに届くことすらありません。ビジネス上のコミュニケーションにおいて、この違いは極めて重要です。

逆に言えば、 偽陰性 フィルタをすり抜けるスパムメール。典型的な例としては、本文をわずかに変更し、リンクを変化させ、技術的には正しく見えるヘッダーを持つキャンペーンが挙げられます。このようなメールは、フィッシングやマルウェア、迷惑広告のリスクを高めますが、必ずしも厳格な拒否が正当化されるわけではありません。 メールスパムフィルターは、常にこれら2種類の誤検知のバランスを最適化しており、誤検知ゼロを目指すものではありません。

したがって、閾値の設定は、企業としてのリスク管理上の判断となります。拒否の閾値を低く設定すると、通過するスパムは減少するかもしれませんが、正当なメールが紛失するリスクが高まります。 閾値を高く設定すると、マーク付け、隔離、およびユーザーによる確認への依存度が高まります。段階的な戦略が有効です。まずマーク付けと監視を行い、その後、ログ、フィードバック、および自社のメール通信状況に基づいて判断が裏付けられる場合にのみ、グレイリストやより厳格な措置を講じるというものです。

SpamAssassin：ルール、スコア、および動作モデル

スパムアサシン これは、拡張可能なルールおよびポイントベースのフィルターです。ヘッダー、本文、HTML、URLなどを分析するほか、統計的手法、ネットワーククエリ、およびベイジアン、SPF、DKIM、DMARCなどの機能に対応したプラグインも利用可能です。 個々のヒット結果がスコアに加算されます。その合計から算出されたスコアを、設定された閾値と比較することができます。

独自のカスタマイズは、従来通り .cf-ファイル。これにより、例えばヘッダー、ボディ、URIに関するルールを独自のスコアとともに定義することができます。このモデルは、チームが特定のルールがなぜトリガーされたのかを追跡する必要がある場合に、特に透明性が高くなります。 一方で、例外やローカルなルールセット、評価基準が多様化すればするほど、メンテナンスの負担も増大します。各ルールには、業務上の根拠、文書化された効果、そして定期的な検証が必要となるからです。

サーバーを常時稼働させる場合、通常はサービスが spamd 検査依頼を受け付ける一方、スリムクライアントは spamc 彼へのメッセージを転送します。この分離により、メッセージごとにプログラムを完全に起動する手間が省かれ、定期的なチェックに最適です。また、このサービスはSQLやLDAPの設定、およびユーザーごとの設定を取り込むこともできます。

これはホスティング環境において重要な点です。ドメインごとに異なるホワイトリストが必要となる一方で、個々のメールボックスには独自の設定や学習履歴が存在する場合があります。こうした歴史的に形成された構造は技術的な欠陥ではありませんが、システム間の移行を困難にします。 したがって、移行を行う前に、どのルールが実際にビジネス上不可欠であり、どのルールが単に歴史的に引き継がれたものであり、どのタスクがすでにMTAや他のサービスによって処理されているのかを明確にしておく必要があります。

適切に管理されたSpamAssassinのインストール環境は、単に導入から時間が経過したという理由だけで置き換える必要はありません。ルールが理解しやすく、統合が安定して動作しており、管理の手間がメールの処理量に見合っている場合は、移行を行うよりも、的を絞ったメンテナンスを行う方が合理的である場合があります。 逆に、メンテナンスが困難な特殊なルールが多数存在するという事実は、盲目的にコピーすべき理由にはなりません。むしろ、それは 通常在庫 後で選択するフィルターに関係なく、クリティカルな部分を調整する。

Rspamd：ワーカー、シンボル、およびアクション

Rspamd はマスター・ワーカーモデルを採用しています。マスターはプロセスと設定を管理し、通常のワーカーはメッセージを検査します。 プロキシ・ワーカーは、とりわけMilterからのリクエストを受け付け、それをスキャナーに分散させることができます。コントローラーは管理機能とWebインターフェースを提供しますが、保護されていない状態でパブリックネットワークに接続されることはありません。これらの役割の分離により、メール通信、処理、および管理がより明確に区別されます。

このアーキテクチャにおいて重要なのは、ノンブロッキングな入出力です。DNS、Redis、HTTP へのクエリは非同期で実行できます。 あるチェックが外部からの応答を待っている場合でも、必ずしも同じワーカーによる他のスキャンが停止するわけではありません。ただし、これによって一般的なパフォーマンスが保証されるわけではありません。実際の結果は、ルールセット、ハードウェア、DNSの遅延、Redis、MTA接続、および実際のメッセージ構成によって依然として左右されます。

Rspamdでのテストの実行 記号 評価や追加情報を基に、フィルターがそれらを総合スコアに集約し、次のようなアクションを提案することができます。例えば、 add header, greylist 或いは reject. この設定は、必ずしも配信に関する決定を強制するものではありません。Postfix、Exim、またはSendmailへの設定および具体的な組み込み方法によって、MTAがこれを適用するかどうか、またどのように適用するかが決まります。

まさにその理由から、既存のSpamAssassinの閾値をそのまま数値として採用してはならない。 スコアは、有効化されたルール、その重み付け、および利用可能なデータソースの相互作用を反映したものです。同じ名称のチェックであっても、両システム間で重み付けや集計方法が異なったり、実行されるタイミングが異なったりする可能性があります。直接比較を行うと、 required_score Rspamdのしきい値を設定することは、技術的に誤解を招く恐れがあります。

運用上、評価と執行を分離することには利点がある。まず、シンボルの発行や提案されたアクションを、即座に却下することなく観察することができる。独自の正当なメッセージ、検知されたキャンペーン、およびフィードバックに基づいて初めて、どの アクションの閾値 妥当である。このようにして、技術的なデフォルト設定が、一見客観的なスパム判定基準ではなく、検証可能な配信ガイドラインとなる。

日常のメール運用における比較

SpamAssassinとRspamdの違いは、個々の検出ルールというよりも、運用モデルにあります。どちらも多くのシグナルに基づいてメールを評価しますが、設定、統合、分散運用へのアプローチは異なります。 以下の比較表は、計画立案の基礎としてこれらの点を整理したものであり、自組織のメールトラフィックを実際に評価する代わりとなるものではありません。

したがって、小規模な単体サーバーの場合、適切に管理されたSpamAssassinのインストールは、技術的な緊急事態とはなりません。独自のルールが明確で、サービスが安定して動作し、誤判定に対処できるのであれば、現状を維持する方が変更にかかる労力を抑えられる可能性があります。 とはいえ、Rspamdによる再構築も、そのMilter連携や一元化されたモジュールが計画中の環境により適している場合には、依然として妥当な選択肢となります。

複数のスキャナーが存在するホスティング環境では、 スケーリング 単にインストールされたルールの数よりも重要です。 Rspamdのプロキシワーカーは、Milterからのリクエストを他のワーカーに転送することができます。その際、非同期の外部クエリによってワーカー全体がブロックされることはありません。ただし、これによって一般的なパフォーマンスが保証されるわけではありません。実際のスループットは、DNSの遅延、ルール、ハードウェア、およびメッセージの構成によって決まります。

MTA接続、Redis、およびステートベースのモジュール

技術的な統合によって、どの位置に メールスパムフィルター その評価をメール転送エージェントに返します。Rspamdは、Milterを介してPostfixやSendmailと連携させることができます。Eximは、このために spamd_address. フィルタは結果を返しますが、メッセージをマークするか、遅延させるか、あるいは拒否するかは、引き続きMTAと選択された設定によって決定されます。

すべての検証に共通の状態が必要なわけではありません。SPF、DKIM、DMARCは認証情報を評価し、DNSベースのリストや正規表現は個々のメッセージのその他の特徴を検証します。 こうした検証には外部のDNS応答が必要となる場合もありますが、それらが自動的に学習履歴を構築するわけではありません。その信頼性は、とりわけDNSが正しく動作していることや、ルールセット全体における適切な重み付けなどに依存します。

働き方を変える 状態ベースのモジュール. ベイズ分類は学習した特徴を保存し、グレイリストは過去の配信試行を認識する必要があり、レート制限には複数の接続にわたるカウンターが必要となる。 Rspamdは、ベイズ分類、ニューラル分類、グレイリスト、およびその他の状態のためのドキュメント化されたアーキテクチャにおいて、Redisの利用を想定している。これにより、複数のインスタンスが共通の情報にアクセスできるようになる。

したがって、Redisは単なる代替可能な詳細要素でもなければ、個々のRspamdチェックの必須条件でもありません。アクセス可能なストレージがなくても、静的モジュールは引き続き使用可能ですが、学習機能やレピュテーション機能は制限されたり、機能しなくなったりする可能性があります。 したがって、運用担当者は本番運用開始前に、可用性、ネットワーク接続、アクセス保護、バックアップ、およびRedis障害時の対応策を明確に定義しておく必要があります。

実用的な観点からは、責任の分担が理にかなっています。MTAはSMTP接続を受け付け、フィルタリングの決定を実行し、Rspamdはメッセージを評価し、Redisは必要な状態を保持します。この役割分担により、トラブルシューティングが容易になりますが、監視すべきサービスの数は増えます。 遅延や到達不能な依存関係については、軽率な拒否によって補うべきではありません。

ルールと学習データを管理しながら移行する

移行は、すべてのファイルをコピーすることからではなく、現状把握から始まります。特に独自のルールについては、入念に確認する必要があります。これらはビジネス上の要件を反映している一方で、時代遅れの例外を含んでいる可能性もあるからです。Rspamd は、ルールのうち一部のみを処理する SpamAssassin モジュールを提供しています。 したがって、ルールが技術的に類似しているからといって、同じ効果が得られるとは限りません。

このモジュールは、とりわけ特定の body-, rawbody-, header-, meta- そして uri-ルールの処理。一方、ネットワークやHTML固有のプラグインについては、完全には対応されていません。検証されていない大規模なサードパーティ製のルールセットを読み込むと、設定が複雑になり、処理に負荷がかかる可能性があります。そのため、確実に必要と確認された独自のルールのみを採用し、ネイティブモジュールを優先することをお勧めします。

特に注意を要する点は、 ベイズ学習. Rspamdのドキュメントによると、SpamAssassinのベイジアンデータベースはインポートできない。 そのため、Rspamd には、正常なメールとスパムから構成される、検証済みの新しいコーパスが必要です。誤って分類された請求書、ニュースレター、またはキャンペーンメールは、分類を誤った方向に導き、その後の誤判定を助長する恐れがあります。

AWLも、単なるファイルの引き継ぎとして扱うべきではありません。過去の送信者履歴と現在のレピュテーション評価は、確かに類似した目的を持っていますが、異なるデータソースや重み付けを使用している可能性があります。 したがって、まずは既存の例外や信頼ルールがどのような効果をもたらすべきかを明確に定義してください。その上で初めて、Rspamdのネイティブ機能と、個別に設定したルールと、どちらが適切かを判断することができます。

Rspamdを並行運用で確実に導入する

生産的な移行は、従来のフィルターを置き換えることから始まるのではなく、現状の把握から始まります。MTA接続、SpamAssassinのルール、ユーザーごとの例外設定、DNSへの依存関係、許可された送信者、および不審なメッセージに対する現在の処理方法を文書化してください。 さらに、後で重要となる指標を明確に定義しておきましょう。例えば、誤ってスパムとしてマークされたビジネスメール、見逃されたキャンペーンメール、手動での処理にかかる工数などです。

まず、Rspamdを実際のメールパスとは別の場所にインストールし、その評価結果は記録されるものの、配信には影響を与えないように設定します。 ドキュメントに記載されている「シャドウモード」を利用すれば、まさにこの観察が可能になります。Rspamdは、提案されたアクションを実行することなくメッセージを検査します。これにより、比較期間中はSpamAssassinが唯一のアクティブな判定者となります。

総合スコアだけでなく、とりわけトリガーされた 記号 およびそこから導き出されたアクション。 スコアが高くなる原因としては、認証エラー、URLの特徴、レピュテーションデータ、またはローカルルールなどが考えられます。これらの原因に応じて、必要な修正も異なります。したがって、スコアやモジュールを変更する前に、不審なメッセージごとにヘッダー、受信者グループ、およびフィルタが提案するアクションを確認してください。

有意義な比較には、意図的に望ましいケースと望ましくない境界事例が含まれます。例えば、信頼できるサプライヤーからの正当な請求書には、PDFファイルや外部の追跡リンクが含まれている場合があります。 一方、バリエーションに富んだスパムキャンペーンでは、件名、定型文、送信者が絶えず変化しますが、典型的なURLや構造的な特徴は維持されます。これら2種類のメッセージは、個々の要素が合理的に寄与しているか、あるいはルールが広範囲に適用されすぎていないかを明らかにします。

ヨーク しきい値 検証可能な例が十分に揃ってから適用してください。Rspamdのスコア尺度と従来のSpamAssassinのスコアは同一視できないため、そのまま適用すると不適切な処理を引き起こす可能性があります。 ヘッダーの追加のみを行うタイミング、一時的にグレーリストに登録するタイミング、および拒否する条件については、個別に決定してください。MTAとの統合設定によって、アクションが実際に実行されるかどうか、またその方法が決定されます。

計画された監視期間を経て、制御された形で切り替えが行われます。Rspamdがアクティブなフィルタとなり、SpamAssassinはインストールされたまま設定も可能ですが、メールの流れにおける判断は行わなくなります。この移行期間には、責任の所在、文書化された元への切り戻し手順、および切り戻しを中止する基準を明記しておく必要があります。 さらに、明確に範囲が限定されたファイアウォールの設定も役立ちます。段階的なルール移行の基礎については、以下の記事で解説されています。 Netfilter 対 nftables.

運用、ログ記録、および体系的なトラブルシューティング

予期せぬ拒否が発生した場合、診断は具体的なメッセージとその処理フローから開始し、フィルタ閾値を一律に緩和することから始めるべきではありません。 MTAログ、Rspamdの結果、トリガーされたシンボル、スコア、および提案されたアクションを確認してください。この照合を行って初めて、ローカルルール、DNSベースのチェック、あるいはMTAによる強制のいずれが拒否の原因となったかが判明します。

通過してしまったスパムについては、逆方向の分析を行う必要があります。メッセージがRspamdに到達したかどうか、どのシンボルが欠落しているか、そしてスコアが原因で設定されたアクションが実行されなかったかどうかを確認してください。 期待されるDNSの結果が得られない場合は、新しいコンテンツルールを作成する前に、リゾルバー、到達可能性、および応答時間を調査してください。すべてのキャンペーンが単一の閾値で適切に捕捉できるわけではありません。

Redisの障害は、状態依存の機能に影響を及ぼす可能性があるため、別途対処する必要があります。 フィルタとストレージ間の接続、Redisサービスのログを確認し、続いてこの状態に依存しているモジュールを特定してください。静的なチェックでも引き続き結果を得ることができますが、ベイズ学習、グレイリスト、その他の状態依存型の評価を行うには、正常に動作するデータ管理システムが必要です。

期待したルールがトリガーされない場合は、まずそのルールの実際の読み込み場所、構文、および適用対象となるメッセージの形式を確認してください。 ヘッダー、プレーンテキスト、HTML、URLの各チェックでは、それぞれ異なるデータが対象となります。SpamAssassinでは、ルールファイルを適用する前に構文チェックを行うことができます。以下のコマンドは設定を検証するものであり、実際のメール配信には影響を与えません。

spamassassin --lint

繰り返し発生する障害については、タイムスタンプ、キューの挙動、DNSクエリ、および応答エラーを1つの画面にまとめて表示します。これにより、配信の遅延がMTA、外部クエリ、あるいはフィルタ処理のいずれに起因するものかを判別できます。 Linuxのテレメトリに関する詳細や、稼働中のシステムの監視については、以下の関連記事をご覧ください。 最新のカーネル解析のためのbpftool 技術的な基礎。

単発の事象が発生したからといって、反射的にグローバルスコアや大規模なルールセットを変更してはなりません。その代わりに、当該メッセージを個人情報保護の規定に従って適切に保管し、類似の事例と比較検討した上で、原因と変更内容を記録してください。これ エラー分析 追跡可能な修正を行い、例外ルールによって後で大量の正当なメールや迷惑メールが誤って処理されてしまうリスクを低減します。

サーバープロファイルに基づいて決定する

既存のメールサーバーが、独自のルール、ユーザーごとの設定、運用手順に基づいて確実に管理されている場合、SpamAssassinを継続して運用することは理にかなっています。このシステムはルールおよびポイントベースで拡張可能であり、プラグインや様々な設定方法、保存方法をサポートしています。 具体的な運用上の問題が存在しない限り、単に導入から時間が経過したという理由だけでシステムを切り替えることは、技術的なメリットをもたらしません。

Milterとの連携、最新の認証チェック、一元管理、およびステートフルなモジュールを最初から統合して計画する場合、Rspamdはシステムを再構築する際の有力な選択肢となります。 そのアーキテクチャには、処理、プロキシ接続、管理のためのワーカーロールが含まれます。同時に、DNSおよび必要に応じてRedisを、運用上の依存関係として確実に稼働させる必要があります。これはアーキテクチャ上の決定であり、一般的なパフォーマンスの保証ではありません。

特殊なケースが多数存在する、成熟したホスティング環境においては、 並列運転 たいてい、最も柔軟性のある選択肢です。これにより、どの独自のSpamAssassinルールが引き続き必要か、Rspamdのシンボルが想定される原因を正しく反映しているか、そしてどの受信者グループが誤分類に対して特に敏感に反応するかが明らかになります。 この分析結果に基づいて初めて、完全な移行を行うか、あるいは現状を維持するかを判断することができます。

したがって、選択はメールボックスの数そのものよりも、メンテナンス体制や相互依存関係に左右される。 Redis、DNSリゾルバー、ログ解析、およびアップデートを恒久的に担当できる体制が整っていれば、学習機能やステートフル機能を含むRspamdを一貫して運用することができます。こうしたリソースが不足している場合は、明確なルールを備えた、スリムでドキュメントが充実した構成の方が、運用リスクを低く抑えることができるでしょう。

製品を問わず、Rspamdコントローラーを保護措置を講じずにネットワーク上に公開しないでください。ドキュメントでは、ローカル接続またはファイアウォールによる保護が推奨されています。リモートアクセスを行う場合は、アクセス保護とパスワードハッシュが必要です。 また、他者が作成したルールや過去のスコアを、検証せずにそのまま採用しないでください。個別の測定結果や目立つキャンペーンだけでは、グローバルなフィルタリングポリシーの根拠とはなりません。

したがって、正しい決断は次の通りです。 リスクの評価: 迷惑メールからの保護と、正当なメールが紛失することによる影響とのトレードオフが生じます。 各操作について、誰が責任を負うか、どのように検証されるか、そして以前の状態にどう戻すかを明確に定義してください。そうすることで、メールスパムフィルターは、追跡が困難な自動処理システムではなく、メール運用において管理可能な要素として機能し続けます。