これはスパムとの戦いに関する 標準的な質問 です。
関連もあります:
SPAMとの戦いについて知っておくべきテクニックはたくさんあります。管理者、ドメイン所有者、エンドユーザーが受信トレイから迷惑メールを排除するのに役立つ、広く使用されている手法と技術は何ですか?
さまざまな角度からさまざまなテクノロジーをカバーする答えを探しています。承認された回答には、さまざまなテクノロジー(SPF/SenderID、DomainKeys/DKIM、グレイリスト、DNS RBL、レピュテーションサービス、フィルタリングソフトウェア[SpamAssassinなど])を含める必要があります。ベストプラクティス(例:ポート25でのメールの中継を許可しない、ポート587を使用するなど)、用語(例:オープンリレー、バックスキャッター、MSA/MTA/MUA、スパム/ハム)、およびその他の手法。
敵を倒すには、敵を知らなければなりません。
私たちの目的では、スパムとは迷惑な電子メールのことです。最近のスパムは、疑いを持たないユーザーが(通常は不審な)Webサイトにアクセスするように仕向け、製品の購入やマルウェアのコンピューターへの配信、あるいはその両方を要求することを目的としています。一部のスパムはマルウェアを直接配信します。
最初のスパムが1864年に送信されたことに驚かれるかもしれません。 これは、歯科医院の広告であり、ウエスタンユニオンの電報で送信されました。 単語自体は 参照 であり、 シーンモンティパイソンのフライングサーカス 。
この場合、スパムはnotユーザーがサブスクライブしたメーリングリストトラフィックを参照しますが、後で気が変わった(または忘れた)場合でも、実際にはまだサブスクライブを解除していません。
スパムは問題です。これは、スパマーに対して機能するです。スパムは通常、スパマーに コストをカバーする -送信するのに十分な売り上げ(またはマルウェアの配信、あるいはその両方)を生み出します。 。スパマーは、受信者、ユーザー、およびユーザーへのコストを考慮していません。スパムを受信するごく少数のユーザーがそれに応答する場合でも、それで十分です。
したがって、帯域幅、サーバー、および管理者が受信したスパムに対処するための時間を支払う必要があります。
スパムをブロックする理由は次のとおりです。スパムを確認したくない、メール処理のコストを削減したい、スパマーにとってスパムのコストを高くしたい、などです。
スパムは通常、通常の正当な電子メールとは異なる方法で配信されます。
スパマーはほとんどの場合、電子メールの発信元を隠そうとするため、一般的なスパムには偽のヘッダー情報が含まれます。 From:
アドレスは通常、偽物です。一部のスパムには、偽のReceived:
行が含まれ、トレイルを偽装しています。多くのスパムは、オープンSMTPリレー、オープンプロキシサーバー、ボットネットを介して配信されます。これらすべての方法では、誰がスパムの発信者であるかを特定することがより困難になります。
いったんユーザーの受信トレイに入ると、スパムの目的は、宣伝されているWebサイトにアクセスするようにユーザーを誘導することです。そこで、ユーザーは購入を誘惑されるか、サイトがユーザーのコンピューターにマルウェアをインストールするか、またはその両方を試みます。または、スパムはマルウェアを含む添付ファイルを開くようにユーザーに要求します。
メールサーバーのシステム管理者は、メールサーバーとドメインを構成して、スパマーがユーザーにスパムを配信するのをより困難にします。
具体的にはスパムに焦点を当てた問題を取り上げ、スパムに直接関連しないもの(暗号化など)をスキップする場合があります。
大きなメールサーバーの罪はオープンリレーを実行することです。SMTPサーバーは任意の宛先へのメールを受け入れ、それを先に配信します。スパマーは事実上配信を保証するため、オープンリレーが大好きです。メッセージの配信の負荷を引き受けます(そして、再試行!)スパマーが他のことをしている間、彼らはスパミングを行います安い。
オープンリレーも後方散乱の問題の一因となります。これらは、リレーによって受け入れられたが配信不能であることが判明したメッセージです。オープンリレーは、スパムのコピーを含むFrom:
アドレスにバウンスメッセージを送信します。
From:
とTo:
の両方のアドレスがドメイン内にないネットワークの外部からSMTPサーバーにメールを送信して、システムをテストします。メッセージは拒否されます。 (または、 MX Toolbox などのオンラインサービスを使用してテストを実行しますが、メールサーバーがテストに失敗した場合、一部のオンラインサービスがIPアドレスをブラックリストに送信することに注意してください。さまざまな設定ミスやエラーは、着信メッセージがスパムであるか、そうでなければ違法である可能性が高いことを示すヒントになります。
HELO
/EHLO
を送信しない接続を拒否します。HELO
/EHLO
が次の場合に接続を拒否します:サーバーに到着するメールは、受信メールと送信メールの観点から考える必要があります。受信メールは、最終的にドメイン宛てのSMTPサーバーに到着するメールです。送信メールとは、SMTPサーバーに到着したメールで、配信される前に別の場所に転送されます(たとえば、別のドメインに送信されます)。受信メールはスパムフィルターで処理でき、どこからでも送信される可能性がありますが、常にユーザー宛てである必要があります。メールを送信する可能性のあるすべてのサイトに認証情報を提供することはできないため、このメールは認証できません。
送信メール、つまり中継されるメールは認証される必要があります。これは、インターネットからの場合でも、ネットワーク内部からの場合でも同様です(操作上可能な場合は、メールサーバーの使用を許可するIPアドレスの範囲を制限する必要があります)。これは、スパムボットがネットワーク内で実行されている可能性があるためです。そのため、SMTPサーバーを構成して、そのメールが認証されない限り、他のネットワークに宛てられたメールがドロップされるようにします(リレーアクセスは拒否されます)。さらに良いことに、インバウンドとアウトバウンドのメールに別々のメールサーバーを使用し、インバウンドメールにはリレーを一切許可せず、アウトバウンドメールへの認証されていないアクセスを許可しません。
ソフトウェアで許可されている場合は、認証されたユーザーに従ってメッセージをフィルタリングする必要もあります。メールの送信元アドレスが認証されたユーザーと一致しない場合は、拒否する必要があります。 fromアドレスをサイレントに更新しないでください。ユーザーは構成エラーに注意する必要があります。
メールの送信に使用したユーザー名をログに記録するか、識別ヘッダーを追加する必要もあります。このようにして、乱用が発生した場合は、証拠があり、それを行うために使用されたアカウントがわかります。これにより、侵害されたアカウントと問題のあるユーザーを分離でき、共有ホスティングプロバイダーにとって特に価値があります。
ネットワークを出たメールが実際に(認証された)ユーザーによって送信されているのではなく、ボットや外部の人々によって送信されていないことを確認したいとします。これを行う方法の詳細は、管理しているシステムの種類によって異なります。
一般に、企業ネットワークの場合は、送信メールサーバー以外のすべてのポート25、465、および587(SMTP、SMTP/SSL、送信)で下りトラフィックをブロックすることをお勧めします。これは、ネットワーク上でマルウェアを実行するボットがネットワークからスパムを送信してインターネット上のリレーをオープンしたり、アドレスの最終的なMTAに直接送信したりできないようにするためです。
ホットスポットは、それらからの正当なメールが多くの異なるドメインから発信されるため特別なケースですが、(特にSPFのため)「強制」メールサーバーは不適切であり、ユーザーは独自のドメインのSMTPサーバーを使用してメールを送信する必要があります。このケースははるかに困難ですが、これらのホストからのインターネットトラフィックに特定のパブリックIPまたはIP範囲を使用して(サイトの評判を保護するため)、SMTPトラフィックを抑制し、詳細なパケット検査を検討する必要があります。
歴史的に、スパムボットは主にポート25でスパムを発行してきましたが、同じ目的でポート587を使用することを妨げるものは何もないため、受信メールに使用されるポートを変更することは疑わしい価値があります。ただし、 RFC 2476 では、メール送信にポート587を使用することをお勧めします。これにより、メール送信(最初のMTAへ)とメール転送(MTA間)を分離できます。そのような分離が必要な場合は、これを行う必要があります。
ISP、VPSホスト、コロケーションプロバイダーなどの場合、または訪問者が使用できるホットスポットを提供している場合、独自のドメインを使用してメールを送信するユーザーにとって、下りSMTPトラフィックをブロックすると問題が発生する可能性があります。パブリックホットスポットを除くすべてのケースで、送信SMTPアクセスを必要とするユーザーがメールサーバーを実行しているため、それを明確に要求する必要があります。悪用の申し立ては、最終的にそのアクセスが終了してあなたの評判を保護することになることを彼らに知らせてください。
動的IP、および仮想デスクトップインフラストラクチャに使用されるIPは、それらのノードが使用すると予想される特定のメールサーバー以外に、アウトバウンドSMTPアクセスを持つべきではありません。これらのタイプのIP =もブラックリストに表示され、それらのレピュテーションを構築しようとしないでください。これは、正当なMTAを実行している可能性が非常に低いためです。
SpamAssassinは、メッセージヘッダーとコンテンツに基づいてスパムを識別するために使用できるメールフィルターです。ルールベースのスコアリングシステムを使用して、メッセージがスパムである可能性を判断します。スコアが高いほど、メッセージがスパムである可能性が高くなります。
SpamAssassinには、スパムとハム(正当な電子メール)のサンプルを分析できるベイジアンエンジンもあります。
SpamAssassinのベストプラクティスは、メールを拒否するのではなく、迷惑メールまたはスパムフォルダーに入れることです。 OutlookやThunderbirdなどのMUA(メールユーザーエージェント)は、SpamAssassinがメールメッセージに追加するヘッダーを認識して適切にファイルするように設定できます。誤検知は発生する可能性があり、実際に発生します。まれなケースですが、CEOに発生すると、それが通知されます。メッセージが完全に拒否されるのではなく、単にジャンクフォルダーに配信された場合、その会話ははるかにうまくいきます。
SpamAssassinは、他に類を見ないものですが、 いくつかの代替案が存在します 。
sa-update
を使用してルールの自動更新を構成します。DNSBL(以前のRBLまたはリアルタイムブラックホールリスト)は、スパムまたはその他の悪意のあるアクティビティに関連するIPアドレスのリストを提供します。これらは独自の基準に基づいて独立したサードパーティによって運営されているため、DNSBLによって使用されるリスティングおよびデリスティングの基準が、組織がメールを受信する必要性と互換性があるかどうかを慎重に調査してください。たとえば、いくつかのDNSBLには厳格な上場廃止ポリシーがあり、誤ってリストされた人物が削除されることを非常に困難にしています。他のユーザーは、IPアドレスが一定期間スパムを送信しなかった後に自動的に除外されます。これはより安全です。ほとんどのDNSBLは無料で使用できます。
レピュテーションサービスは似ていますが、特定のIPアドレスに関連するより多くのデータを分析することにより、より良い結果を提供すると主張しています。ほとんどのレピュテーションサービスでは、サブスクリプションの支払いまたはハードウェアの購入、あるいはその両方が必要です。
数十のDNSBLとレピュテーションサービスが利用可能ですが、私が使用してお勧めする、よく知られている便利なサービスをいくつか紹介します。
保守的なリスト:
積極的なリスト:
前に述べたように、他の何十ものものが利用可能であり、あなたのニーズに合うかもしれません。私のお気に入りのトリックの1つは IPアドレスを調べる で、複数のDNSBLを通過するスパムを配信して、拒否したDNSBLを確認します。
SPF(Sender Policy Framework; RFC 4408 および RFC 6652 )は、特定のドメイン名へのメール配信を承認されているインターネットホストを宣言することにより、電子メールアドレスのなりすましを防ぐ手段です。
-all
を構成します。DKIM(DomainKeys Identified Mail; RFC 6376 )は、DNSで公開された公開鍵を使用して検証できるメールメッセージにデジタル署名を埋め込む方法です。米国では 特許に制約された であり、その採用は遅れています。 DKIM署名は、メッセージが送信中に変更された場合にも壊れる可能性があります(たとえば、SMTPサーバーがMIMEメッセージを再パックする場合があります)。
グレイリストは、SMTPサーバーが永続的な拒否ではなく、受信メッセージに対して一時的な拒否を発行する手法です。配信が数分または数時間で再試行されると、SMTPサーバーはメッセージを受け入れます。
グレイリストは、一時的な拒否と永続的な拒否を区別するほど堅牢ではないが、オープンリレーに送信されたスパムやより強力なスパムソフトウェアには役立たない一部のスパムソフトウェアを阻止できます。また、ユーザーが必ずしも許容できない配信遅延が発生します。
Nolisting は、優先度が最も高い(優先度が最も低い)レコードが実行中のSMTPサーバーを持たないようにMXレコードを構成する方法です。これは、多くのスパムソフトウェアが最初のMXレコードのみを試行するという事実に依存していますが、正当なSMTPサーバーはすべてのMXレコードを優先順位の高い順に試行します。一部のスパムソフトウェアは、 RFC 5321 に違反して、優先度が最も低い(優先度が最も高い)MXレコードに直接送信しようとするため、SMTPサーバーなしでIPアドレスに設定される可能性もあります。これは安全であると報告されていますが、他と同様に、最初に慎重にテストする必要があります。
既存のSMTPサーバーの前に Cisco IronPort または Barracuda Spam&Virus Firewallまたは他の同様のアプライアンス)などのスパムフィルタリングアプライアンスを配置して、作業の多くを削減して、あなたが受け取るスパム。これらのアプライアンスは、DNSBL、レピュテーションサービス、ベイジアンフィルター、およびこれまでに取り上げたその他の機能で事前構成されており、製造元によって定期的に更新されています。
あなた(または働き過ぎのITスタッフ)にとってそれが多すぎる場合は、いつでもサードパーティのサービスプロバイダーにあなたの電子メールを処理させることができます。 Googleの Postini 、 Symantec MessageLabs Email Security (またはその他)などのサービスがメッセージをフィルタリングします。これらのサービスの一部は、規制要件および法的要件も処理できます。
エンドユーザーがスパムに対抗するために絶対にすべきことは次のとおりです。
スパムに応答しないでください。
見た目がおかしい場合は、Webサイトのリンクをクリックしたり、添付ファイルを開いたりしないでください。オファーがいかに魅力的であるかに関係なく。そのバイアグラはそれほど安くはありません、あなたは本当に誰かの裸の写真を撮るつもりはありません、そして ナイジェリアで$ 1500万ドル または他のどこにもありません_(しましたスパムに対応する。
スパムメッセージが表示された場合は、メールクライアントに応じて、ジャンクまたはスパムとしてマークします。
メッセージを受信するために実際にサインアップしていて、メッセージの受信を停止したいだけの場合は、メッセージをジャンク/スパムとしてマークしないでください。代わりに、提供されているunsubscribeメソッドを使用して、メーリングリストから退会してください。
ジャンク/スパムフォルダを定期的にチェックして、正当なメッセージが届いたかどうかを確認してください。これらを迷惑メールではない/スパムではないとしてマークし、送信者を連絡先に追加して、今後メッセージがスパムとしてマークされないようにします。
私は何年にもわたって100以上の個別のメール環境を管理しており、スパムを削減または排除するために数多くのプロセスを使用してきました。
テクノロジーは時間とともに進化してきたので、この答えは、私が過去に試みたいくつかのことを通り、現在の状況を詳しく説明します。
保護に関するいくつかの考え...
着信スパムに関して...
私の現在のアプローチ:
私はアプライアンスベースのスパムソリューションを強く支持しています。ネットワークの境界で拒否し、メールサーバーレベルでCPUサイクルを節約したい。アプライアンスを使用すると、実際のメールサーバー(メール配信エージェント)ソリューションからある程度の独立性も得られます。
いくつかの理由で Barracuda Spam Filterアプライアンス をお勧めします。私は数十のユニットを配備しましたが、ウェブ主導のインターフェース、業界のマインドシェア、そして設定して忘れるアプライアンスの性質がそれを勝者にしています。バックエンドテクノロジーには、上記のテクニックの多くが組み込まれています。
バラクーダスパム&ウイルスファイアウォール300ステータスコンソール
新しいアプローチ:
過去1か月間、 Barracudaのクラウドベースの電子メールセキュリティサービス を実験してきました。これは他のホストされたソリューションと同様ですが、高価なアプライアンスが非常に高価である小規模サイトに適しています。このサービスは、わずかな年額料金で、ハードウェアアプライアンスの約85%を提供します。このサービスは、オンサイトアプライアンスと連携して実行して、着信帯域幅を減らし、セキュリティの別のレイヤーを提供することもできます。また、サーバーが停止した場合にメールをスプールできる素敵なバッファでもあります。分析は依然として有用ですが、物理ユニットほど詳細ではありません。
バラクーダクラウドメールセキュリティコンソール
全体として、私は多くのソリューションを試しましたが、特定の環境の規模とユーザーベースの増大する要求を考えると、最もエレガントなソリューションを利用できるようにしたいと考えています。多方面からのアプローチを取り入れて「独自のロール」を行うことは確かに可能ですが、私はいくつかの基本的なセキュリティとバラクーダデバイスの適切な使用の監視でうまくやっていました。ユーザーは結果に非常に満足しています。
注: Cisco Ironport も同様に優れています。
一部では、私は他の人が言ったことを支持しています。一部ではありません。
これは私にとって非常にうまく機能しますが、ベイジアンフィルターのトレーニングに少し時間をかける必要がありますハムとスパムの両方を使用。
ewwhiteはその日が過ぎ去ったと感じているかもしれませんが、私は同意できません。私のクライアントの1つが、さまざまなフィルターの効果を尋ねたので、個人用メールサーバーの2012年7月のおおよその統計を以下に示します。
したがって、約44000がグレイリストを通過することはありませんでした。私がグレーリストを作成しておらず、それらすべてを受け入れていれば、CPUとメモリ、そして実際に帯域幅を使用するスパムフィルタリングがすべて必要だったでしょう。
編集:この回答は一部の人々にとって有用であると思われるので、統計を最新のものにすると思います。そこで、2.5年後の2015年1月からメールログの分析を再実行しました。
数値は直接比較することはできません。私が2012年の数値にたどり着いた方法についてのメモがないため、方法論が同一であるかどうか確信が持てません。しかし、当時は膨大な量のコンテンツに対して、計算量の多いスパムフィルタリングを実行する必要がなかったと確信していますが、グレイリストを作成しているため、まだ実行していません。
これは実際にはスパム対策技術ではありませんが、ジョージョブの場合は、対処しなければならない後方散乱の量を減らすことができます。つまり、インとアウトの両方で使用する必要があります。つまり、受信メールの送信者のSPFレコードを確認し、それに従って承認/拒否する必要があります。また、独自のSPFレコードを公開し、メールの送信が承認されているすべてのマシンを完全にリストアップし、-all
で他のすべてのマシンをロックアウトする必要があります。 -all
で終わらないSPFレコードは完全に役に立ちません。
RBLには問題があり、RBLは自分の過失なしにRBLに乗ることができ、降りにくい場合があります。それにもかかわらず、彼らはスパムとの戦いで合法的な使用法を持っていますが、メール受信の輝線テストとしてRBLを使用しないことを強くお勧めします。 spamassassinがRBLを処理する方法-それぞれが合計スコアに寄与する多くを使用することにより、受け入れ/拒否の決定を行うのはこのスコアです。
私は商用サービスを意味しているわけではありません。私のメールサーバーには、すべてのグレーリストとスパムフィルタリングを通過する1つのアドレスがありますが、誰の受信トレイに配信する代わりに、/var
。14日以上経過したメールが毎晩自動的に削除されます。
有効なメールアドレスが必要なメールフォームに記入するとき、保持する必要があるが今後は聞きたくない1通のメールを受信する場合、または購入するときに、すべてのユーザーにそれを利用することをお勧めします自分のアドレスを販売またはスパム送信する可能性が高いオンラインベンダー(特にヨーロッパのプライバシー法の適用範囲外)から。ユーザーは実際のアドレスを提供する代わりに、Dropboxアドレスを提供し、通信相手(通常はマシン)から何かを期待する場合にのみDropboxを見ることができます。到着したら、それを取り出して適切なメールコレクションに保存できます。それ以外の場合、ユーザーはDropboxを見る必要はありません。
私は、スパムを許容レベルまで削減するいくつかの手法を使用しています。
正しく構成されていないサーバーからの接続の受け入れを遅らせます。私が受け取るスパムの大部分は、マルウェアに感染したシステムで実行されているスパムボットからのものです。これらのほとんどすべてがrDNS検証に合格していません。各応答の前に30秒ほど遅延すると、ほとんどのスパムボットはメッセージを配信する前に諦めます。これをrDNSに失敗したサーバーにのみ適用すると、適切に構成されたサーバーにペナルティが課されることを回避できます。正しく構成されていない正当なバルク送信者または自動送信者にはペナルティが課されますが、遅延は最小限に抑えられます。
すべてのドメインに対してSPFを構成すると、ドメインが保護されます。ほとんどのサブドメインは、メールの送信には使用しないでください。主な例外は、自分でメールを送信できる必要があるMXドメインです。多くの正当な送信者が、ポリシーで許可されていないサーバーに一括メールと自動メールを委任しています。 SPFに基づいて拒否するのではなく延期することで、SPF構成を修正するか、ホワイトリストに登録することができます。
HELO/EHLOコマンドでFQDN(完全修飾ドメイン名)を要求する。スパムは、多くの場合、修飾されていないホスト名、アドレスリテラル、IPアドレス、または無効なTLD(トップレベルドメイン)を使用します。残念ながら、一部の正当な送信者は無効なTLDを使用しているため、この場合は延期する方が適切な場合があります。これには、メールを有効にするための監視とホワイトリスト登録が必要になる場合があります。
DKIMは否認防止に役立ちますが、それ以外の点ではそれほど有用ではありません。私の経験では、スパムに署名される可能性は低いです。ハムは署名される可能性が高いため、スパムスコアにある程度の価値があります。正当な送信者の多くは、公開鍵を公開したり、システムを不適切に構成したりしていません。
グレイリストは、設定の誤りの兆候を示すサーバーに役立ちます。適切に構成されたサーバーは最終的に通過するため、グレイリストから除外する傾向があります。彼らはスパムのために時々使用される傾向があるので、それはフリーメーラーをグレーリストにするのに役立ちます。遅延により、スパムフィルター入力の一部に、スパマーを捕まえる時間が与えられます。また、通常は再試行しないため、スパムボットをそらす傾向があります。
ブラックリストとホワイトリストも役立ちます。
スパムフィルタリングソフトウェアはスパムを見つけるのに適しており、一部は通過します。誤検知を過度に増加させずに、誤検知を妥当なレベルまで取得するのは難しい場合があります。 Spamassassinは、届いたスパムのほとんどをキャッチしています。自分のニーズに合ったカスタムルールをいくつか追加しました。
ポストマスターは、必要な不正行為とポストマスターのアドレスを設定する必要があります。これらのアドレスへのフィードバックを確認し、それに基づいて行動します。これにより、他のユーザーがサーバーが適切に構成され、スパムを発信していないことを確認できます。
開発者は、独自のサーバーをセットアップするのではなく、既存のメールサービスを使用してください。自動メール送信者用のサーバー設定が誤って設定されている可能性が高いのは私の経験です。 RFCを確認し、ドメイン内の正当なアドレスから適切にフォーマットされたメールを送信します。
エンドユーザーは、スパムを減らすためにいくつかのことを実行できます。
ドメインの所有者/ ISPは、ポート25(SMTP)でのインターネットアクセスを公式の電子メールサーバーに制限することで支援できます。これにより、スパムボットがインターネットに送信する機能が制限されます。また、動的アドレスがrDNS検証に合格しない名前を返す場合にも役立ちます。さらに良いのは、メールサーバーのPTRレコードがrDNS検証に合格することを確認することです。 (クライアントのPTRレコードを構成するときに誤植がないか確認してください。)
メールを3つのカテゴリに分類し始めました。
私が見た1つの最も効果的なソリューションは、外部メールフィルタリングサービスの1つを使用することです。
現在のクライアントで以下のサービスの経験があります。他にもあると思います。これらのそれぞれは、私の経験では素晴らしい仕事をしました。費用は3つすべてにとって妥当です。
このサービスには、ローカルソリューションに比べていくつかの大きな利点があります。
彼らはそれがあなたのインターネット接続とあなたの電子メールサーバーに当たる前にほとんど(> 99%)のスパムを止めます。スパムの量を考えると、これは帯域幅やサーバー上ではない大量のデータです。私はこれらのサービスの1つを数十回実装しましたが、どれもがメールサーバーの顕著なパフォーマンスの向上をもたらしました。
また、通常は両方向のアンチウイルスフィルタリングも行います。これにより、サーバーに「メールアンチウイルス」ソリューションをインストールする必要性が軽減され、viriiが完全に維持されます
また、スパムのブロックにも優れています。 MXLogicを使用している会社で2年間働いている間、私は誤検知を経験したことがなく、一方で通過した正当なスパムメッセージを数えることができます。
同じ2つのメール環境はありません。したがって、電子メール、トラフィック、ソフトウェア、ネットワーク、送信者、受信者などのコンテンツはすべて、環境によって大きく異なるため、効果的なソリューションを構築するには、利用可能なさまざまな手法に関する多くの試行錯誤が必要になります。
ただし、次のブロックリスト(RBL)は一般的なフィルタリングに適していることがわかりました。
すでに述べたように、SpamAssassinは正しく構成された場合の優れたソリューションです。CPANにできるだけ多くのアドオンPerlモジュールをインストールし、Razor、Pyzor、DCCをインストールしてください。 PostfixはSpamAssassinと非常にうまく連携し、たとえばEXIMよりも管理と構成がはるかに簡単です。
最後に、failblbanやiptablesなどを使用してクライアントをIPレベルで短時間(たとえば1日から1週間)にブロックし、乱暴な動作のためにRBLへのヒットをトリガーするなどのいくつかのイベントも非常に効果的です。既知のウイルスに感染したホストと話しているリソースを無駄にするのはなぜですか?