SMTPのグレーリストは、a）多くのスパムを阻止し、b）多くの正当なメールを阻止しますか？
Postfixを使用して比較的使用頻度の低いドメインにSMTPサーバーをセットアップし、 SQLGrey でグレーリストを有効にしました。これまでのところ問題なく動作しているようで、新しい送信者からの電子メールの遅延に少し苛立ちがありますが、ログから、多くのスパムメッセージを阻止していることがわかります。
あなたの経験では、グレイリストは多くのスパムを効果的に阻止しますか？それは例えばへの有用な追加ですか？ SpamAssassinですか、それとも過剰/不要なものに追加していますか？
これをより使用頻度の高いドメイン（おそらくより要求の厳しいユーザー）に展開する場合、メッセージがバウンスしたり失われたりする、構成が不十分なメールサーバーのかなりの部分が予想されますか？
あなたの経験では、グレイリストは多くのスパムを効果的に阻止しますか？
とても効果的です。私はそれを3年以上使用しており、ろ過プロセスに明確な影響を与えています。
それは例えばへの有用な追加ですか？ SpamAssassinですか、それとも過剰/不要なものに追加していますか？
実際にはreduceスキャンワークロードになります。追加することをお勧めします。
これをより使用頻度の高いドメイン（おそらくより要求の厳しいユーザー）に展開する場合、メッセージが返送されたり失われたりする、構成が不十分なメールサーバーのかなりの部分が予想されますか？
メールサーバーの構成が大幅に間違っていたにもかかわらず、これが発生するのを確認しました（ポストマスターは、ソフトエラーが発生した場合、送信を再試行するのではなく、すぐに配信を断念することにしました）。これは、送信者が4xxメッセージと5xxメッセージを処理する方法に要約されます。彼らがそれらを同じように扱うならば、あなたはいくつかの問題を抱えているでしょう。彼らがそれらを扱う場合正しく、ここで4xxはソフトフェイルであり、送信者は再試行しますが、問題はありません。設定が正しくない場合でも、簡単な解決策は、送信者のドメインを「既に表示済み」としてグレーリストに追加し、データベースからの脱落を防ぐために不条理なスコアを付けることです。
私の経験では、グレーリストは欠点を正当化するのに十分な利点を提供しません。サーバーにグレーリストを設定していましたが、すべての（新しい）受信メールが遅れるほど面倒でした。また、受信メールの一部が失われていたことも確かです。
スパマーは十分に永続的であり（そして当時でも自動的に再試行を開始していたと思います）、とにかくスパムが通過しました。私は何年も前にグレイリストをオフにしましたが、振り返っていません。
グレイリストは、コンテンツフィルタに到達する前に、大量のスパムを効果的に阻止します。
これは、スキャンのワークロードを大幅に削減し、フォールスネガティブを削減し（コンテンツフィルターに捕捉されないスパムの一部はグレーリストによって事前にブロックされます）、定義上、導入できないため、非常に便利な依存症です。誤検知（正当なメールがブロックされている）。
緩んだメールは、SMTP送信者に準拠していないことが原因です。はい、まだニースを再生していない「ビッグ」がいくつかあります。システムが修正されるまで、短いホワイトリストがそれらを処理します。結局、インターネット上にグレーリストのあるサイトがたくさんあると、正しく構成されたメールサーバーをより多くの人に使用させるという素晴らしい副作用があります。
適切なグレーリスト設定（適切な実装+適切な構成/操作）を使用すると、遅延するメールはほとんどなく、ほとんどの場合、遅延は数分程度になります。また、適切なグレーリスト設定は、ほとんどの場合「展開して忘れる」システムであり、スパムフローを減らし、システムの負荷を減らしながら、（sysadmin）の負荷を増やしません。
既存のドメインでグレーリストを実際にオンにする前に、「学習モード」でデプロイすることを強くお勧めします。このモードでは、何も遅らせることなくメールフローを監視します。これにより、トリプレットを学習し、優れたSMTP送信者を自動ホワイトリストに登録する時間が与えられます。
コンテンツスキャナーの前に大量のメールがブロックされると、多くの良い副作用が発生します。私は特にこれらが好きです：
- 短くて頻繁に変更されない手動ホワイトリストを除いて、グレーリストシステムはサーバー間で知識を共有する必要がないため、地理的に分散した場所/データセンターでの複数のMXの展開が簡素化されます。
- スキャンの負荷を減らすことは、コンテンツスキャンに使用するハードウェアが少なくて済むことを意味します
- コンテンツスキャン用のサーバーが少ないということは、それらをより簡単に一元化、管理、デバッグできることを意味します（ログの信号/ノイズ比が向上します;）
- 「明らかな」スパムを拒否するためのシステムへの負荷が少なくなり、配信を再試行するためのスパマーシステムへの負荷が増えると、受信者の負荷とスパマーの負荷の比率が向上し、スパムの送信がより「高価」になります。これは長い間良いことです。期間
全体として、グレーリストは次のように要約されます。
- 送信者に標準への準拠を強制することで、電子メールシステム全体が正しく機能し、管理しやすくなります（->副作用としてスパマーをより簡単に追跡できます）
- 電子メール送信のコストを（少し）増加させ、正当な送信者に少し影響を与え、スパマーに大きな影響を与えます（->スパム送信コストを増加させることは常に良いことです）
編集：正当なメール配信時間の（小さいが、それは私見です）影響がありますが、 tarpitting や [〜＃〜 ] spf [〜＃〜] 。前者は興味深いですが、その有効性/欠点を判断する前にいくつかの実世界のテストを行います。後者は常に利用できるとは限りません。
はい、グレーリストに登録すると、かなりの量のスパムを非常に安価に阻止できます。スパムを止めない場合でも、追加された遅延により、メッセージまたは送信者がDNSBLまたはハッシュベースのリストにリストされるまでの時間が長くなります。
適切な実装を使用していることを確認する必要があります（私はSQLGreyに個人的に精通していません）。特に、以前に正確なトリプレットを見たことがなくても、トリプレットを信頼する方法を一般的に理解できます（たとえば、IPから十分な優れたトリプレットを見た場合、そのIPからそれ以上のトリプレットをグレーリストする意味はおそらくありません）。しばらくすると、正当なメッセージがグレーリストに表示されることはほとんどありません。
他の回答に追加するには：
グレイリストを展開するときに考慮すべきことの1つは、それがwill（特定の）正当なメールの遅延を増加させることです。これがユーザーにとって問題であるかどうかを最初に確認する必要があります。
たとえば、組織の大部分が内部メールと少数の長年のビジネスパートナーとのメールである場合、その影響はごくわずかです。
OTOHさん、新規のお客様と頻繁にメールをやり取りするのは大変かもしれません。特に1つの状況が問題になる可能性があります。電話で誰かと話し、そのディスカッションに関連するドキュメントを電子メールで交換したい場合（私がサポートタイプの電話で定期的に行うこと）、数分でも受け入れられない。
したがって、いつものように、ユーザーの特定のニーズを考慮に入れてください。
私はグレイリストで素晴らしい運がありました。個人的には、これを唯一のスパム対策として使用することはありませんが、階層化されたスパム対策システム（SpamAssassing、amavisd、clamav、RBL、SPF/DKIMなど）の一部として含まれている場合、多くの機能を提供します。メリット。
重要な注意点の1つは、グレーリストに登録された宛先を適切に処理しないISP（主要なもの）がいくつかあることです（yahooメーリングリストはよく知られている例です）。実際の電子メールをブロックしてしまうことがないように、人々がまとめたホワイトリストのいくつかを確認することをお勧めします。
私の経験では、vast（実際の人/ユーザーから）人から人へと受信する電子メールの大部分は、主要なメールサーバー（postfix、qmail、exchange、sendmail）の1つを通過します。 ）、これらはすべてグレーリストを適切に処理します。時折、それを正しく処理しないメーリングリストソフトウェアや自動電子メールプログラムに出くわすかもしれませんが、私の経験では、これは非常にまれであると示唆しています。