RFC 3834: メール自動応答

Standards Track Mailing Lists & Header Fields Published March 2026

ELI5: 「不在時」の自動返信を設定した場合、2つの自動応答者が互いに永遠に返信し続けるのを何が止めるのでしょうか？RFC 3834は、ルールを定義しています：メッセージを自動としてマークする方法、ループを検出および抑制する方法、およびいつ自動応答を送信することが適切であるかです。これがあなたの不在時自動返信が無限メール嵐を引き起こさない理由です。

このシステムが存在する理由

自動メール応答はいたるところに存在します：休暇/不在メッセージ、読み取り確認、チャレンジレスポンススパムフィルター、チケットシステムの確認応答、および通知ダイジェスト。ルールがないと、自動応答装置は危険なフィードバックループを生成します：

AliceのAutoresponderがBobのメッセージに返信します。
BobのAutoresponderはAliceの自動応答に返信します。
AliceのAutoresponderはBobの自動応答に返信します。
永遠に繰り返され、両方のメールボックスとネットワークが洪水状態になります。

RFC 3834は、Auto-Submittedヘッダーフィールドと、すべての自動応答装置が従わなければならないルールのセットを定義することでこれを防止します。

動作方法

Auto-Submittedヘッダー

自動生成されるすべてのメッセージには、Auto-Submittedヘッダーを含める必要があります。定義された値は：

値	意味	例
`no`	メッセージは人間によって作成されました（ヘッダーが存在しない場合はデフォルト）	人が作成した通常のメール
`auto-generated`	メッセージは自動的に生成され、別のメッセージに応答していません	スケジュール済みレポート、監視アラート、システム通知
`auto-replied`	メッセージは別のメッセージへの自動応答です	休暇の返信、不在通知、読み取り確認
`auto-notified`	メッセージは別のメッセージに関する自動通知です	配信状況通知、処置通知

; 休暇自動応答
From: alice@example.com
To: bob@example.com
Subject: Re: プロジェクト更新
Auto-Submitted: auto-replied
In-Reply-To: <msg-id-from-bob@example.com>

1月15日まで不在です。
緊急の場合はcharlie@example.comまで連絡してください。

コアルール：自動応答に自動応答しない

自動応答を送信する前に、応答装置は**受信メッセージ自体が自動かどうか**をチェック必須です。自動の場合、自動応答は送信されません。チェックは：

Auto-Submittedヘッダーをチェックします。存在し、noと等しくない場合は応答しません。
空の返信パスをチェックします。エンベロープ送信者（MAIL FROM）が<>の場合は応答しません。バウンスおよびDSNは空の返信パスを使用します。
Precedenceヘッダーをチェックします。値がbulk、junk、またはlistの場合は応答しません。（これはRFC 3834より前の従来の慣例ですが、依然として広く使用されています。）

; 受信メッセージにはAuto-Submittedヘッダーがあります
Auto-Submitted: auto-replied

; 判断：自動応答しない
; これは無限ループシナリオを防ぎます

レート制限

RFC 3834は、自動応答装置に同じ送信者への応答を制限することを要求します。標準的な慣行：

送信者あたり時間ごとに最大1つの自動応答を送信します（通常は1日に1回、または休暇期間に1回）。
自動応答を既に受け取った送信者を追跡します。
同じ休暇期間中に同じ人に重複する自動応答を送信しません。

エンベロープおよびヘッダー要件

自動応答は：

空のエンベロープ送信者（MAIL FROM:<>）または応答装置のアドレスを使用します。自動応答のエンベロープ送信者として元の送信者のアドレスを使用しません。
Auto-Submitted: auto-repliedを設定します（または非応答オートメーション用にauto-generated）。
元のメッセージを指すIn-Reply-ToおよびReferencesヘッダーを含めるため、自動応答が正しくスレッド化されます。
Fromアドレスではなく、Return-Pathまたはエンベロープ送信者に応答を転送します。これにより、自動応答からのバウンスが元の人間の送信者に命中しないようになります。

主要な技術詳細

自動応答をトリガーしてはいけないメッセージ

RFC 3834は、自動応答を抑制する必要がある特定のケースをリストします：

Auto-Submittedがno以外の値に設定されているメッセージ
空のエンベロープ送信者（MAIL FROM:<>）を持つメッセージ
メーリングリストに送信されたメッセージ（List-Id、List-Unsubscribe、またはPrecedence: listをチェック）
送信者がデーモンまたはシステムアドレスと思われるメッセージ（例：MAILER-DAEMON、postmaster）
それ自体がバウンス通知（DSN）であるメッセージ

Auto-SubmittedとPrecedence

古いPrecedenceヘッダーはRFC 3834より前の時代のものであり、正式に標準化されていませんが、依然として広く使用されています：

; 従来のアプローチ（依然として一般的）
Precedence: bulk

; 標準準拠のアプローチ
Auto-Submitted: auto-generated

; ベストプラクティス：最大互換性のために両方を含める
Precedence: bulk
Auto-Submitted: auto-generated

自動応答装置は両方のヘッダーをチェックする必要があります。一部の古いシステムはPrecedenceのみを設定します。一部の新しいシステムはAuto-Submittedのみを設定します。両方をチェックするとどちらかのループが防止されます。

X-Auto-Response-Suppressヘッダー

Microsoft Exchangeは標準ではありませんが広くサポートされているヘッダーを導入しました：

X-Auto-Response-Suppress: All

可能な値にはDR（配信レポート）、NDR（配信不可レポート）、RN（読み取り通知）、NRN（未読通知）、OOF（不在）、およびAutoReplyが含まれます。多くの送信システムはトランザクショナルおよびマーケティングメールでAllを設定して、Exchange/Outlookからのすべての自動応答を抑制します。

メーリングリストメッセージの検出

メーリングリストメッセージへの自動応答は特に問題です—すべてのサブスクライバーに送信されます。以下をチェック：

; これらのいずれかはリストメッセージを示します
List-Id: <dev.lists.example.com>
List-Unsubscribe: <mailto:unsub@lists.example.com>
Precedence: list
X-Mailing-List: dev@lists.example.com

例

よく形成された休暇返信

; エンベロープ
MAIL FROM:<>
RCPT TO:<bob@example.com>

; ヘッダー
From: alice@example.com
To: bob@example.com
Date: Mon, 10 Mar 2025 09:00:00 +0000
Subject: Re: Q1計画
Auto-Submitted: auto-replied
In-Reply-To: <orig-msg-id@example.com>
References: <orig-msg-id@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

メールをありがとうございます。私は3月8日から15日まで不在で、
メールへのアクセスが限定されています。

緊急の場合はcharlie@example.comまで連絡してください。

システム通知

From: noreply@monitoring.example.com
To: ops-team@example.com
Subject: [アラート] web-prod-03のCPU使用率が90%を超えています
Auto-Submitted: auto-generated
Precedence: bulk
X-Auto-Response-Suppress: All

サーバーweb-prod-03がCPU閾値を超えました。
現在の使用率：94%。直ちに調査してください。

一般的な間違い

自動化されたメッセージでAuto-Submittedを設定しません。これが最も重要なことです。これがないと、すべての受信者の休暇応答装置が自動化されたメッセージに返信し、それらの返信があなたの側でさらなるオートメーションをトリガーする可能性があります。
空の返信パスを持つメッセージへの自動応答。バウンスはMAIL FROM:<>を使用します。それらに返信するとバウンスループが作成されます：あなたの返信がバウンスし、別のバウンスが生成され、あなたのシステムは再びそれに返信しようとします。
メーリングリストへの自動応答。メーリングリストに不在返信を送信すると、すべてのサブスクライバーにスパムを送信します。自動応答する前に常にList-IdおよびPrecedenceヘッダーをチェック。
レート制限がありません。レート制限がないと、50のメッセージを送信したユーザーは50の同一の休暇返信を受け取ります。送信者あたりの時間ごとに1つの自動応答に制限します。
Fromアドレスを自動応答ターゲットとして使用します。自動応答はFromアドレスではなくReturn-Path（エンベロープ送信者）に送信されるべき。Fromアドレスはメーリングリスト、no-replyアドレス、または実際の送信者と異なる可能性があります。
自動応答に元のメッセージ本文を含めます。一部の自動応答装置は元のメッセージ全体を引用します。これはプライバシーリスク（自動応答が転送される可能性がある）で、帯域幅を浪費します。
トランザクションメールでX-Auto-Response-Suppress: Allを設定しません。注文確認またはパスワードリセットを送信する場合は、このヘッダーを追加して、Exchange/Outlookユーザーが自動メッセージへの不在返信を送信するのを防ぎます。

配信可能性への影響

自動応答ループは送信者の評判を損ないます。あなたのシステムがループを作成する場合、ボリュームスパイクは受信サーバーへのスパム実行に見えます。あなたの送信IPは数時間以内にブラックリストに登録される可能性があります。
適切にマークされた自動応答は受信者によってフィルタリングされます。Gmailおよび他のプロバイダーは自動的にAuto-Submittedヘッダーを持つメッセージを分類し、自動応答がスパムとしてフラグされる可能性を低減します。
すべての自動化されたメールにAuto-SubmittedおよびPrecedenceを設定します。これにはトランザクションメール、アラート、レポート、および人間によって作成されていないメッセージが含まれます。これは休暇返信があなたのインバウンドキューを洪水させるのを防ぎます。
空の返信パスはバウンスカスケードを防ぎます。自動応答にMAIL FROM:<>を使用すると、応答自体がバウンスされた場合、バウンスはどこにも配信されず、潜在的なカスケードが破断されます。
自動応答フラッドについてインバウンドを監視します。受信休暇返信または配信確認の急増は、多くの場合、新しいメッセージテンプレートで自動応答抑制ヘッダーを設定し忘れたことを示します。