グレーリスト（電子メール）

グレーリストは、電子メールユーザーをスパムから守る方法です。グレーリストを使用するメール転送エージェント(MTA) は、認識できない送信者からの電子メールを「一時的に拒否」します。メールが正当なものである場合、送信元サーバーはしばらくしてから再試行し、十分な時間が経過すると、電子メールは受け入れられます。

グレーリストを採用したサーバーは、 SMTP ( Simple Mail Transfer Protocol ) で定義されているように、4xx 応答コード (「後で折り返し連絡してください」) を送信して、不明または疑わしいソースからの電子メールを一時的に拒否します。完全な機能を備えた SMTP 実装では、このような場合にメッセージ送信を再試行するためのキューを維持することが期待されており、^[1]そのため、正当なメールが遅れる可能性はありますが、それでも通過するはずです。^[2]

一時的な拒否は、SMTP ダイアログのさまざまな段階で発行することができ、これにより、実装は受信メッセージに関するデータをより多くまたはより少なく保存できます。トレードオフは、再試行と元のメッセージとのより正確な一致のために、より多くの作業と帯域幅が必要になることです。^[3]コンテンツを受信した後にメッセージを拒否すると、サーバーはヘッダーの選択と/またはメッセージ本文のハッシュを保存できます。^{[引用が必要]}

グレーリスターは、適切な送信者をホワイトリストに登録するだけでなく、例外も提供できます。グレーリスターは、一般に、一致する証明書を持つ完全に検証された TLS 接続によってオーバーライドできます。大規模な送信者には、電子メールを送信 (および再送信) できるマシンのプールがあることが多いため、最上位 24 ビット (/24) が同じ IP アドレスは同等として扱われるか、場合によってはSPFレコードを使用して送信プールが決定されます。同様に、一部の電子メール システムでは、メーリング リスト用の可変エンベロープ リターン パス (VERP)、転送された電子メール用の送信者書き換えスキーム、バックスキャッタ保護用のバウンス アドレス タグ検証など、メッセージごとに一意のリターン パスを使用します。送信者アドレスの完全一致が必要な場合、このようなシステムからのすべての電子メールは遅延します。一部のグレーリスター システムでは、送信者ドメインと送信者アドレスのローカル部分の先頭のみを使用してVERPの可変部分を排除することで、この遅延を回避しようとします。^{[引用が必要]}

グレーリストは、通常のメール転送エージェントが通常行うようにキューに入れてメールの配信を再試行しない、スパマーが使用する大量メール ツールに対して有効です。配信を遅らせることで、リアルタイム ブラックホール リストや類似のリストにスパムの送信元を識別してフラグを立てる時間も与えられます。そのため、グレーリストによる遅延前よりも、その後の試行が他のメカニズムによってスパムとして検出される可能性が高くなります。^{[引用が必要]}

ユーザーの観点から見た主な利点は、グレーリストには追加のユーザー設定が不要であることです。グレーリストを使用するサーバーが適切に設定されていれば、送信メール サーバーが以前のメッセージと同じホワイトリスト グループに属していると識別されている限り、エンド ユーザーは特定の送信者からの最初のメッセージでのみ遅延に気付くことになります。同じ送信者からのメールが繰り返しグレーリストに登録されている場合は、遅延メールの詳細なヘッダーを添えてメール システム管理者に連絡することをお勧めします。^{[引用が必要]}

メール管理者の視点から見ると、利点は 2 つあります。グレーリストは、ローカル ホワイトリストを時々変更するだけで、最小限の設定で起動して実行できます。2 つ目の利点は、一時的な 451 エラー (実際のエラー コードは実装によって異なります) でメールを拒否すると、システム リソースの消費が非常に少なくなることです。ほとんどのスパム フィルタリング ツールは、CPU とメモリを大量に消費します。スパムがフィルタリング プロセスに到達する前に阻止することで、システム リソースの消費が大幅に減ります。^{[引用が必要]}

グレーリストの最大の欠点は、認識されていないサーバーの場合、ユーザーが期待する電子メールのほぼ即時性が損なわれることです。認識されていないサーバーからのメールは通常約 15 分遅れますが、送信システムの設定が不十分な場合は最大で数日遅れることがあります。即時の電子メール配信に慣れているユーザーにこれを説明しても、グレーリストを使用するメール サーバーが正しく動作しているとはおそらく納得できないでしょう。^{[引用が必要]}

これは、使用する前にアカウントを作成し、電子メール アドレスを確認する必要がある Web サイトや、グレーリスト メールサーバーのユーザーが、パスワード リセットの電子メール確認を使用する Web サイトで資格情報をリセットしようとする場合に特に問題となる可能性があります。サイトの送信側 MTA が適切に構成されていない場合、グレーリストによって最初の電子メール リンクが遅延される可能性があります。極端な場合、グレーリストによって課される配信遅延が、電子メールで配信されるパスワード リセット トークンの有効期限を超えることがあります。このような場合、リセット トークンを含む電子メールが期限切れになる前に使用できるように、Web サイトのメールサーバーをホワイトリストに登録するための手動介入が必要になる場合があります。^{[引用が必要]}

メールサーバーがグレーリストに登録されている場合、最初の遅延から再送信までの時間は変動します。グレーリストサーバーは遅延を制御または可視化できません。^[4] SMTPでは再試行間隔は少なくとも30分、ギブアップ時間は少なくとも4～5日必要であるとされていますが、^[1]実際の値はメールサーバーソフトウェアによって大きく異なります。^[5]

現代のグレーリストアプリケーション（Unix系オペレーティングシステム用のPostgreyなど）は、送信者の評判のスパム性に関わらず、一時的なエラーから回復できることが証明された送信者を自動的にホワイトリストに登録します。^{[6] [要出典]}

実装には通常、一部のメールサーバーを手動でホワイトリストに登録する機能も含まれます。^{[引用が必要]}

2007 年のグレーリストに関するある分析では、メールの遅延のためグレーリストはまったく望ましくないと考えられており、グレーリストが普及すると、迷惑メール送信者がシステムを変更してグレーリストを回避できるため信頼性が低いとされています。グレーリストの目的は、サーバーのスパム フィルタリング ソフトウェアが分析する必要があるスパムの量を減らし、リソースを集中的に使用してサーバーのコストを節約することであり、ユーザーに届くスパムを減らすことではないという結論が出ています。結論: 「[グレーリスト] は非常に迷惑です。スパムよりもずっと迷惑です。」^[7]

現在の SMTP 仕様 (RFC 5321) では、「SMTP クライアントは、そのメッセージの配信の責任を負います」(セクション 4.2.5) と、「すぐに送信できないメールはキューに入れられ、送信者によって定期的に再試行される必要があります」(セクション 4.5.4.1) と明確に規定されています。ほとんどのMTA は、したがってメッセージをキューに入れて再試行しますが、少数の MTA はそうしません。^{[2] [4] [8]}これらは通常、ホワイトリストまたは例外リストによって処理されます。^{[引用が必要]}

また、再試行が元の試行とは異なる IP アドレスから行われた場合、正当なメールが配信されない可能性があります。メールの送信元がサーバー ファームである場合、または他の種類のリレー サービスを経由して送信される場合、元のサーバー以外のサーバーが次の試行を行う可能性があります。ネットワークのフォールト トレランスのために、それらの IP はまったく関連のないアドレス ブロックに属している可能性があり、その結果、アドレスの最も重要な部分を識別するという単純な手法が無効になります。IP アドレスが異なるため、受信者のサーバーは一連の試行が関連していることを認識できず、順番にそれぞれを拒否します。サーバーの数が十分に多い場合は、メッセージがキューからなくなるまでこれが続く可能性があります。この問題は、サーバー ファームなどの例外を事前に識別することで部分的に回避できます。同様に、マルチホーム ホストおよびDHCP を使用するホストに対しては例外を構成する必要があります。^{[2]極端な場合、送信者は (正当に) 送信 SMTP 接続ごとに異なる}IPv6アドレスを使用できます。^[要出典]

グレーリストの対象となる送信サーバーは、受信ドメインに複数のMXレコードがある場合、別の受信メールサーバーへの配信を再試行することもあります。すべてのホストが同じグレーリストポリシーを実装しておらず、同じデータベースを共有していない場合は、問題が発生する可能性があります。^[2]

• 非掲載
• 帯域幅の調整
• ターピット（ネットワーキング）

• エヴァン・ハリスによるグレーリストのホワイトペーパー
• netqmail のグレーリスト実装
• Microsoft Exchange グレーリストの問題 - ニュースグループ記事
• インターネットエンジニアリングタスクフォースのRFC 6647、2012年6月: 現在の最先端技術を標準化