グレイリスティング（Greylisting）

概要

グレイリスティング（Greylisting） は、受信サーバーが初回のメール配送を SMTP 4xx（一時的エラー）で拒否し、送信サーバーが一定時間後に再送してきた場合にのみメールを受け入れるスパム対策手法です。2003 年に Evan Harris が提案した手法で、RFC として標準化されてはいませんが、広く実装されています。

正規の MTA は SMTP 4xx を受け取ると RFC 5321 に従って一定時間後に再送を試みます。一方、スパム送信ツールの多くは再送機能を持たず、一時拒否されたメールをそのまま破棄します。この動作の違いを利用してスパムをフィルタリングするのがグレイリスティングの原理です。

「ブロックリスト（Blocklist）」でも「許可リスト（Allowlist）」でもない、その中間の「グレー」な状態で送信元を一時的に保留するため、グレイリスティングと呼ばれます。

仕組み

グレイリスティングは送信元 IP・エンベロープ From・エンベロープ To の 3 要素（トリプレット）を記録し、初回拒否と再送の有無で正規の MTA とスパムボットを判別します。

トリプレットによる判定

グレイリスティングは、以下の 3 つの要素を組み合わせた「トリプレット」を記録し、判定に使います。

1. 送信元 IP アドレス
2. エンベロープ From（MAIL FROM）
3. エンベロープ To（RCPT TO）

受信サーバーはメールを受信するたびにトリプレットを生成し、データベースと照合します。

処理の流れ

1. 送信側 MTA が受信側 MTA に SMTP 接続し、メールを送信する
2. 受信側 MTA がトリプレットをデータベースで検索する
3. トリプレットが未登録の場合、データベースに登録し、450 4.7.1 Greylisted を返す
4. 送信側 MTA が 4xx を受け取り、送信キューに戻して再送スケジュールを設定する
5. 一定時間後（通常 5〜15 分）、送信側 MTA が再送する
6. 受信側 MTA がトリプレットをデータベースで検索し、最初の拒否から規定時間が経過していれば受け入れる
7. トリプレットを「通過済み」に更新する。以降、同じトリプレットからのメールは即座に受け入れる

タイミングパラメーター

グレイリスティングの動作を制御する主なパラメーターは 3 つあります。

パラメーター	意味	典型的な値
delay	初回拒否から再送を受け入れるまでの最短待機時間	5 分
max_age（未通過）	再送がなかった場合にトリプレットをデータベースから削除する期間	4 時間
max_age（通過済み）	通過済みトリプレットの有効期間。期間内に再度メールが届くとリセットされる	36 日

delay を短くしすぎると、高速で再送するスパムツールを通してしまいます。長すぎるとメールの遅延が目立ちます。5 分が多くの実装でのデフォルト値です。

スパムツールが再送しない理由

正規の MTA（Postfix、Sendmail、Exchange 等）はメールキューを持ち、4xx エラーの場合に自動的に再送します。Postfix のデフォルト再送間隔は 300 秒（5 分）です。

スパム送信ツール（ボットネットのマルウェア等）の多くは、送信速度を最大化するためにメールキューを実装していません。1 回送信して失敗したアドレスは破棄し、次の宛先に移ります。この動作パターンの違いが、グレイリスティングの有効性の根拠です。

ただし、近年のスパムツールには再送機能を持つものも増えており、グレイリスティング単独でのスパム排除率は低下傾向にあります。

設定例

Postfix では Postgrey をポリシーサーバーとして組み込み、グレイリスティングを有効化します。

Postfix + Postgrey の構成

Postgrey は Postfix 向けのグレイリスティング実装です。Postfix のポリシーサーバーとして動作します。

apt install postgrey

Postfix の設定（/etc/postfix/main.cf）で Postgrey をポリシーサーバーとして追加します。

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10023

Postgrey のデフォルト設定では、初回拒否後 300 秒（5 分）で再送を受け入れます。遅延時間を変更するには、Postgrey の起動オプションを変更します。

# /etc/default/postgrey
POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=300 --max-age=35"

許可リストとの併用

グレイリスティングによるメール遅延を避けたい送信元は、許可リスト（allowlist）で除外できます。Postgrey はデフォルトで /etc/postgrey/whitelist_clients と /etc/postgrey/whitelist_recipients を参照します。

# /etc/postgrey/whitelist_clients
# 大手メールプロバイダーはデフォルトで許可されている
google.com
outlook.com
yahoo.com

SPF レコードに記載された IP アドレスを自動的に許可する設定も可能です。

確認方法

グレイリスティングが動作しているかは、メールログで確認します。Postfix + Postgrey の場合、初回拒否時にログに以下のようなエントリーが記録されます。

grep "postgrey" /var/log/mail.log

action=greylist, reason=new,
  client_name=mail.sender.com,
  client_address=198.51.100.25,
  sender=user@sender.com,
  recipient=admin@example.com

再送後に受け入れられた場合は action=pass と記録されます。

外部から送信したメールがグレイリスティングの影響を受けているかは、送信側 MTA のログで 4xx 応答が返っているかを確認します。

450 4.7.1 <recipient@example.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html

送信元のメール認証設定が整っているかも併せて確認します。認証が不十分な送信元はグレイリスティングに加えて他のフィルターにもかかりやすくなります。

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "record": null,
      "exists": false,
      "selector": "default"
    },
    "dmarc": {
      "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

data.spf.exists と data.dmarc.exists が true であれば、送信ドメインの認証設定は外部から参照可能な状態です。グレイリスティングは認証とは独立した仕組みですが、認証が整っている送信元はレピュテーションが高く、一部のグレイリスティング実装では許可リストに自動追加されることがあります。

よくある問題

グレイリスティングの主な副作用はメール配送の遅延であり、即時性が必要な通知メールや大手プロバイダーの IP プール変動で問題が顕在化します。

メールの配送遅延

グレイリスティングの最大の副作用はメールの遅延です。初回の送信は必ず拒否されるため、再送までの時間分だけ配信が遅れます。Postfix のデフォルト再送間隔（300 秒）であれば 5 分程度ですが、MTA の実装や設定によっては 15〜30 分遅れることもあります。

パスワードリセットメールやワンタイムパスコードなど、即時性が求められるメールでは遅延が問題になります。対策として、送信元のドメインや IP を許可リストに追加し、グレイリスティングをバイパスします。

大手プロバイダーからのメールが遅延する

Gmail や Microsoft 365 は多数の送信 IP を持ち、再送時に異なる IP から送信することがあります。IP アドレスが変わるとトリプレットが一致せず、再度グレイリスティングにかかります。

対策として、IP アドレスの代わりに /24 ネットワーク単位でトリプレットを管理する設定を使います。Postgrey では --lookup-by-subnet オプションがこの機能を提供します。大手プロバイダーのドメインをデフォルトの許可リストに含めている実装も多くあります。

グレイリスティングの効果が薄れている

近年のスパムツールは再送機能を持つものが増えており、グレイリスティング単独でのスパムブロック率は低下しています。グレイリスティングは SPF・DKIM・DMARC、DNSBL、コンテンツフィルタリングと組み合わせて多層防御の一部として運用します。単独での運用は推奨されません。

正規のメールがバウンスする

送信側 MTA の再送回数が少ない設定になっていると、グレイリスティングの待機時間内に再送が行われず、送信側が最終的にバウンスとして処理してしまうケースがあります。受信側でグレイリスティングの delay を 5 分程度に設定し、未通過トリプレットの保持期間を 4 時間以上にすることで、正規の MTA からの再送を逃さないようにします。