新しい電子メールフィルタリングシステムをどのようにテストしますか？
実稼働ネットワークにセットアップする前に、潜在的な新しい電子メールフィルタリングシステムをテストまたは評価するためにどのような方法を使用しますか？
私は特に、電子メールシステムの複製を構築するためのリソースがない単一のメールサーバーを持つ中小規模の組織に適した方法に興味があります。
電子メールフィルタリング製品のテストは、表面的には非常に難しいようです。それについて考えたとき、私は自分の考えを概説し、それらを特定の問題領域に分解しました。
配達
テストの最初の部分は、フィルタリングシステムへの電子メールのモックアップ配信に関連しています。潜在的に、フィルタリングシステムは次のいずれか（そしておそらく私が忘れているより多くのこと）を考慮に入れることができます：
- SMTPプロトコルの具体的な詳細（送信者はHELO、EHLOを実行しましたか、名前やIPなどで何を実行しましたか）
- 送信ドメインのDNSの属性（解決されますか、SPFレコード、ドメインキーレコード）
- 送信者のMXの到達可能性（リバースパス検証用）
- メッセージを配信するサーバーの送信元IPアドレス
- メッセージの内容
- サードパーティのデータベースまたは「署名」が上記のいずれかについて与える「意見」（DNSBL、独自の「レピュテーション」データベースなど）
これらの要因のいずれかが「実際の」配信中に発生するものと同じでない場合、フィルタリングツールへのメッセージ配信のモックアップは現実をあまり表さなくなります。たとえば、送信サーバーの送信元IPアドレスをシミュレートしない方法でキャプチャされた受信メールをフィルタリングリグに送信すると、フィルタリング製品がその要素に作用する（DNSBLによって実行されるなど）ことが妨げられます。同様に、遅延メッセージをフィルタリングに送信すると（たとえば、テストするメッセージの「缶詰」コーパスがある場合）、送信者のDNSとサードパーティのデータベースまたは署名の属性が変更された可能性があるため、動作の誤った印象を与えます。メッセージが最初に送信された時刻（送信者が誤検知を防ぐためにSPFレコードを変更した、サードパーティのサービスが送信者を「ブラックリストに登録」したなど）。
配信に関しては、現実を完全にモックアップすることは不可能だと私は主張します。送信サーバーのIPアドレスをシミュレートする場合、近づくのはかなり困難になります（そして、それを行う「既成の」ソリューションを私は知りません...そしてDNSBLからかなり良い結果を得たので、私は心配するnot送信サーバーのIPアドレスをシミュレートします。）最終的には、できるだけ近づける必要があります。
ストレージ
結果を分析する場合は、フィルタリングされた電子メールをどこかに保存する必要があります。何らかのストレージがなければ、実際に結果を表示する良い方法はありません。確かに、フィルタリングソフトウェアは統計を生成しますが、フィルタリングされたメッセージを見ることができれば、快適さのレベルは確かに向上します。
一部のフィルタリング製品には、ストレージ機能が組み込まれています（たとえば、MailMarshalなど）。他の製品は、配信する電子メールシステムを備えていることを期待しており、ストレージ機能はありません。これらの製品をテストし、本番の電子メールシステムを中断しないようにするには、テストフィルタリングの結果を保存するための何らかのセカンダリ電子メールインフラストラクチャを作成する必要があります。
ライセンス費用が懸念される場合は、無料のオープンソースツールを使用して、ライセンス費用の発生を防ぐことができます。これは、テスト担当者にとって学習曲線となる可能性があります。
より複雑な「グループウェア」タイプの電子メールシステムは、他のサービスに依存しているため、モックアップに課題をもたらす可能性があります。 Exchange Serverでは、メールボックスをホストするためにActiveDirectoryインフラストラクチャをモックアップする必要があります。他の「グループウェア」タイプの電子メールシステム（Notes、Groupwiseなど）には、並列インフラストラクチャの作成に関連する難易度があります。
分析
モックアップ配信と結果の保存に加えて、フィルタリングの精度（スパムとしてのフラグ付け、削除、「迷惑メール」フォルダーへのファイリングなど）を人間が分析する必要もあります。おそらく言うまでもありませんが、この演習の全体的なポイントは結果をフィルタリングするコンピュータの機能をテストすることであるため、人間はフィルタリングの結果を検証する必要があります。 （私は知っています、それは言わずに行きました...しかし私は誰かが「しかし待ってください！私たちは正確さをテストするためのスクリプトを書きます...」と言うのを聞くことができます）
フィルタリング分析は、規模の問題として、何よりも問題があります。エンドユーザーの大規模なグループの場合、フィルタリング分析は、個々のテスターまたはテスターの小グループの能力を超えます（または、おそらく、彼らは単に「スポットチェック」して最高のものを期待します）。さらに、テスターは、実際の受信ユーザー（実際にするレンタカー会社からの愚かな宣伝メールを受信したい）または「語彙」とは「スパム」と見なされるべきものについて異なる考えを持っている可能性があります今日の単語"）。明らかに失敗したメッセージ（「受信トレイ」内のポログラフィックメール、「迷惑メール」フォルダ内の既知の顧客からのメッセージなど）の特定はおそらく非常に簡単ですが、微妙な可能性は確かにあります。
現実に100％代替できるとは思いません。ただ近づいて、テスト設定が現実を十分に反映し、フィルターのパフォーマンスを正確に評価できることを期待する必要があります。
私たちの会社はあなたの基準に非常によく合います。新しいスパムフィルターをテストする前の約1か月間、システムが受信したすべてのスパムを、単に削除するのではなく、特別なアカウントに転送するようにユーザーに依頼して収集しました。サードパーティのフィルターサービスによって検出されたスパムもスパムアカウントに転送されました。次に、そのスパムは新しいフィルターを介して一時的なダミーアカウントに再送信され、そのパフォーマンスを確認しました。すべてが1つの大きなバッチで送信されたため、これはフィルターの負荷処理能力もテストしました。
テストの結果、いくつかの調整が行われ、同じスパムが学習システムにも送られました。ユーザーはまだ通過するスパムを私に送信しますが、時間の経過とともに、週に1つか2つのスパムを受信するとユーザーが不満を言うほどの量になります。
GTUBE（迷惑メールの一般的なテスト）を使用してメールを送信することでテストできます。
これを含むメールを作成するだけです：
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
これは、たとえばspamassassinで正常に機能しています。あなたは特定のアンチスパムのための他のGTUBEを見つけるかもしれません
最初にリレーをテストして、インターネットに新しいスパムボックスを開かないことを確認します。ここで提供されているようなオンラインツールを使用してこれを行うことができます： http://spamlinks.net/prevent-secure-relay-test.htm または無料ではないいくつかのツール http ：//www.dnsstuff.com/ 。