メインコンテンツまでスキップ

Appendix D. SPF/Mediator Interactions (SPF/メディエーター相互作用)

Appendix D. SPF/Mediator Interactions (SPF/メディエーター相互作用)​

この付録は、SPFとメールメディエーター(メーリングリストや転送サービスなど)との相互作用とその影響について議論します。

D.1 Originating ADMDs (発信元ADMD)​

発信元ADMDは、最初にメールを送信する管理ドメインです。メディエーターが存在する場合、発信元ADMDは、そのメールが通過する可能性のある転送およびリストサービスを考慮する必要があります。

D.1.1 問題の識別​

SPFの基本的な仮定:

  • メールは承認されたサーバーから受信者に直接送信される
  • MAIL FROM識別は変更されない
  • 送信IPアドレスはSPFレコードで承認されている

メディエーターによって壊される仮定:

  • メールは中間システムを経由する
  • 異なるIPアドレスから再送信される可能性がある
  • MAIL FROMは変更されるか、そのままになる可能性がある

D.1.2 送信者の選択肢​

オプション1: 緩いSPFポリシーを使用

example.com IN TXT "v=spf1 mx ~all"

利点:

  • 正当な転送を許可
  • 誤検知を減らす

欠点:

  • SPF保護を弱める
  • 偽造しやすくなる

オプション2: 他の認証方法に依存

DKIM署名を公開:
- DKIMは転送時も有効なまま
- 送信IPアドレスに依存しない
- DMARCと連携して機能

オプション3: SPF失敗を受け入れる

example.com IN TXT "v=spf1 mx -all"
  • 一部の正当なメールがマークまたは拒否される可能性を受け入れる
  • ユーザーが正しい送信方法を使用することに依存
  • ユーザーに転送ではなく「コピーとして送信」を使用することを推奨

D.1.3 ベストプラクティス​

推奨設定:

1. 厳格なSPFレコードを公開(-all)
2. 同時にDKIM署名を実装
3. DMARCポリシーを公開
4. 転送問題についてユーザーを教育

DMARC設定例:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected]"

パラメータの説明:

  • adkim=r: DKIMリラックスドアライメント
  • aspf=r: SPFリラックスドアライメント
  • p=quarantine: 失敗時に隔離

D.2 Mediators (メディエーター)​

メディエーターは、送信チェーン内でメールを変更または再送信するシステムです。一般的なメディエーターには、メーリングリスト、転送サービス、自動応答システムが含まれます。

D.2.1 メーリングリスト​

問題:

従来のメーリングリストは元のMAIL FROMを保持します:

元: MAIL FROM:`<[email protected]>`
リスト後: MAIL FROM:`<[email protected]>`
送信IP: list-server.mailinglist.org

SPFチェック:

example.comのSPFレコードをクエリ
list-server.mailinglist.orgのIPをチェック
結果: fail(IPはexample.comのSPFレコードにない)

D.2.2 解決策​

解決策1: MAIL FROMを書き換える(推奨)

書き換え後: MAIL FROM:`<[email protected]>`
Reply-To: [email protected]

利点:

  • SPFチェックが成功
  • バウンスはリストサーバーに戻る
  • 受信者が正しく識別できる

欠点:

  • 元の送信者情報を変更
  • ユーザーがReply-Toに適応する必要がある

実装例(Mailman):

# Mailman設定
from_is_list = 2  # Munge From, add Reply-To

解決策2: SRS (Sender Rewriting Scheme)を使用

SRSはより複雑な書き換えスキームです:

元: [email protected]
書き換え先: [email protected]

SRS形式:

SRS0=<hash>=<timestamp>=<domain>=<localpart>@<forwarder>

例:
[email protected]

利点:

  • 元の送信者情報を保持(local-part内)
  • SPFチェックが成功
  • 追跡および検証可能

欠点:

  • 実装が複雑
  • SRSデータベースが必要
  • local-partが読みにくくなる

解決策3: SPFではなくDKIMを使用

設定:

1. 元の送信者がDKIM署名を使用
2. リストサーバーが元の署名を保持
3. リストサーバーが独自のDKIM署名を追加
4. 受信者がDKIMを検証(SPF失敗を無視)

DMARC設定:

_dmarc.example.com IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"
  • p=none: 強制なし(SPF失敗を許可)
  • adkim=r: DKIMリラックスドアライメント(リスト署名を許可)

D.2.3 メール転送サービス​

タイプ1: シンプル転送

ユーザー設定: [email protected] → [email protected]
転送サービスが保持: MAIL FROM:`<[email protected]>`
転送サーバーのIPから送信

SPF問題:

Gmailはoriginal.comのSPFをチェック
転送サーバーのIPはSPFレコードにない
結果: fail

解決策A: SRS書き換え

転送サービスがSRSを使用:
MAIL FROM:<[email protected]>

解決策B: -allの代わりに~allを使用

original.com IN TXT "v=spf1 mx ~all"

転送されたメールはfailではなくsoftfailを受け取り、受け入れられる可能性が高くなります。

タイプ2: .forwardファイル

# ~/.forward
[email protected]

問題はシンプル転送と同じ。

ベストプラクティス:

1. 転送サービスはSRSを実装すべき
2. 元の送信者はDKIMを使用すべき
3. 受信者はDKIM結果を考慮すべきで、SPFだけではない

D.2.4 自動応答および通知システム​

問題:

元のメール: [email protected] → [email protected]
自動応答: MAIL FROM:`<[email protected]>`
         (company.comサーバーから送信)

SPFチェックは失敗します。

解決策:

空のMAIL FROMで通知を送信:
MAIL FROM:<>
From: Mail Delivery System `&lt;[email protected]&gt;`

または:

ローカルアドレスを使用:
MAIL FROM:`&lt;[email protected]&gt;`
From: Automatic Reply `&lt;[email protected]&gt;`
Reply-To: [email protected]

D.3 Receiving ADMDs (受信ADMD)​

受信ADMDは、メディエーターからのメールを処理し、適切な決定を下す必要があります。

D.3.1 メディエーターメールの識別​

識別子:

1. Receivedヘッダーの中間ホップ
2. List-*ヘッダー(メーリングリスト)
3. Precedence: bulkまたはlist
4. SRS形式のMAIL FROM
5. 既知のリストサービスからのDKIM署名

検出ロジックの例:

def is_mailing_list(message):
    # List-*ヘッダーをチェック
    list_headers = [
        'List-Id', 'List-Post', 'List-Unsubscribe',
        'List-Help', 'List-Subscribe', 'List-Owner'
    ]
    
    for header in list_headers:
        if message.get(header):
            return True
    
    # Precedenceをチェック
    if message.get('Precedence') in ['bulk', 'list']:
        return True
    
    # SRSをチェック
    mail_from = message.get('Return-Path', '')
    if mail_from.startswith('SRS0=') or mail_from.startswith('SRS1='):
        return True
    
    return False

D.3.2 ポリシー推奨事項​

ポリシー1: リストメールに対する寛大な取り扱い

if is_mailing_list(message):
    if spf_result == 'fail':
        # DKIMをチェック
        if dkim_result == 'pass':
            accept_message()
        else:
            # リストの評判をチェック
            if list_is_trusted(list_id):
                accept_message()
            else:
                quarantine_message()

ポリシー2: DMARCに依存

if dmarc_result == 'pass':
    accept_message()
elif spf_result == 'fail' and dkim_result == 'fail':
    reject_message()
else:
    # SPFまたはDKIMのいずれかが成功
    if is_mailing_list(message):
        accept_message()
    else:
        apply_content_filtering()

ポリシー3: ユーザー固有のルール

ユーザーはホワイトリストを設定できます:
- 信頼できるメーリングリスト
- 既知の転送アドレス
- 特定ドメインの寛大な取り扱い

D.3.3 実装推奨事項​

SpamAssassin設定:

# メーリングリストに対する寛大な取り扱い
header LIST_ID exists:List-Id
score LIST_ID -0.1

# SPF failだがList-Idヘッダーあり
meta SPF_FAIL_LIST (SPF_FAIL && LIST_ID)
score SPF_FAIL_LIST 0.5

# 通常のSPF fail(リストヘッダーなし)
score SPF_FAIL 5.0

Postfix設定:

# smtpd_recipient_restrictions
reject_unauth_destination,
check_policy_service unix:private/spf-policy,
permit

# SPFポリシーサービスはリストメールを識別して調整可能

rspamd設定:

-- SPFモジュール設定
spf {
  -- メーリングリストに異なる重みを適用
  symbol_fail = "R_SPF_FAIL";
  symbol_softfail = "R_SPF_SOFTFAIL";
  
  -- カスタムルール
  custom_symbols = {
    R_SPF_FAIL_LIST = {
      score = 2.0,
      description = "SPF failed but from mailing list",
      condition = function(task)
        local spf = task:get_symbol('R_SPF_FAIL')
        local list_id = task:get_header('List-Id')
        return spf and list_id
      end
    }
  }
}

D.4 相互運用性の推奨事項​

D.4.1 標準化​

標準ヘッダーを使用:

メーリングリストは追加すべき:
- List-Id: &lt;list-name.domain.com>
- List-Post: &lt;mailto:[email protected]>
- List-Unsubscribe: &lt;mailto:[email protected]>
- Precedence: bulk

DKIM署名:

リストサーバーは:
1. 元のDKIM署名を保持(存在する場合)
2. 独自のDKIM署名を追加
3. 署名済みヘッダーを変更しない

D.4.2 コミュニケーション​

送信者への通知:

リストサービスは購読者に通知すべき:
- メールはリストサーバーから再送信される
- MAIL FROMは書き換えられる
- リストに返信するためにReply-Toを使用することを推奨

受信者ドキュメント:

受信ポリシーをドキュメント化:
- リストメールの処理方法
- ホワイトリストメカニズム
- ユーザーが設定可能なオプション

D.5 将来の開発方向​

D.5.1 ARC (Authenticated Received Chain)​

RFC 8617がARCを導入:

ARCはメディエーターが認証情報を追加することを許可:
- ARC-Seal: メディエーターの署名
- ARC-Message-Signature: メッセージ署名
- ARC-Authentication-Results: 認証結果

例:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none;
    d=mailinglist.org; s=arc-seal; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mailinglist.org; s=arc-msg; h=from:to:subject; b=...
ARC-Authentication-Results: i=1; mailinglist.org;
    spf=pass [email protected];
    dkim=pass header.d=example.com

利点:

  • 元の認証結果を保持
  • チェーン検証を可能にする
  • 受信者はメディエーターを信頼できる

D.5.2 推奨事項​

新規デプロイメントの場合:

  1. DKIMとSPFを実装
  2. DMARCポリシーを公開
  3. ARCサポートを検討(メディエーターの場合)
  4. 一般的なメーリングリストとの相互運用性をテスト

既存システムの場合:

  1. SPFポリシーの厳格さを見直す
  2. DMARCレポートを監視
  3. 問題のある送信元を識別(リスト、転送など)
  4. ポリシーを調整するか、SRSを実装
に最終更新