要約

  • RFC 5230はSieveに新しいメッセージを生成する動作を加え、元メールのエンベロープ送信者へ返信し、その相手が同じ返信を受け取ったかを一定期間記録する。
  • 休暇メッセージの本文だけでなく、本人宛てかどうか、何を同じ返信とみなすか、ループ対策用ヘッダー、サイトが制限する間隔が、誰にいつ送るかを決める。

不在の影響は本人だけにとどまらない

不在通知は短いので無害に見える。しかし、アカウントの所有者に代わって外向きの通信を始め、送信先ごとの確認はしない。休暇中だと他人に知らせたり、メーリングリストに返事したり、無人の自動システム同士で往復したりする可能性がある。必要なのは文章のひな型だけではない。いつ黙るかを決める規則だ。

2008年、RFC 5230は意図的に機能を絞ったメールフィルター言語Sieveに vacation を追加した。スクリプトは「すぐには返事ができない」と指定でき、インタープリターが別のメッセージを生成する。これはSieveで初めて、まったく新しいメールを作る拡張だった。フォルダーへの振り分けとは違い、ひとつの規則が外部へ会話を開始し、相手側の自動処理からさらなる返信を招く。

宛先には元のSMTPエンベロープ送信者、つまりMAIL FROMを使う。Sieveが最終配信後に動く場合はReturn-Pathに残っていることがある。画面に表示されるFromだけを宛先にするわけではない。生成側のエンベロープは空にすることが推奨され、配送状態通知拡張があれば、返信の配送失敗からさらに通知を作らない指定を使う。Auto-Submitted ヘッダーは自動生成された返信だと示す。日時、From、To、スレッド用ヘッダーも、新しい応答であることを隠さないために定められた。

ひとつの宛先、ひとつの応答、ひとつの期間

最も重要な状態は目立たない。vacationは送信先ごとに一定期間の返信履歴を保持する。同じ人が休暇中に再度メールしても、毎回同じ案内を送り返す必要はない。:days が抑制期間を指定する。省略時は7日と実装側の最小値のうち大きいほうが既定値になる。サイトは正の最小値と最大値を設定でき、範囲外の指定はその境界に丸める。スクリプトに書いた数値が実際の間隔とは限らない。

これは全員に対する単一の「不在通知済み」フラグではない。相手が受け取った返信の種類を区別する。明示的な :handle は複数のvacation文に共通の返信IDを与える。指定しない場合は :subject、:from、:mime、本文の組み合わせから識別する。同じ相手に、異なる状況に応じた別の返信を送ることができる一方、引数が同じ二つの文は抑制履歴を共有する。変数拡張を使う場合でも、追跡の前に値を展開してはならない。応答の識別には、実行ごとに変化する文字列ではなく、コマンドに書かれた引数を使う。

この時間窓は小さな方針データベースのように働く。キーは送信元アドレスだけでも返信本文だけでもなく、相手と返信の組み合わせだ。これにより無用な繰り返しを避けながら、異なる説明は送れる。スクリプト作者が「同じ答え」を定義し、運用者が実効頻度に上限を置く。

不在の本人に宛てられたメールか

RFC 5230は、ユーザーのアドレスがTo、Cc、BccまたはResent系の欄にある場合に限って返信するよう要求する。アカウントの既知アドレス、最終エンベロープ宛先、あるいはスクリプトの :addresses による別名登録を使って本人のアドレスを判断できる。複数のアドレスを持つ利用者には便利だが、転送やサブアドレスでは完全な一覧を作れない場合がある。

機械やリストへの応答を避ける策もある。実装は返信してはならないアドレス一覧を持たなければならず、標準はデーモンやリスト管理用アドレスを例に挙げる。リスト管理ヘッダーを含むメールや、Auto-Submitted が no 以外のメールには返信すべきでない。ヘッダーや本文から不適切な返信だと判断して抑制することもできる。ただし、あらゆる自動処理を見分けられる保証はない。いくつかの宛先は実装ごとに決まり、サーバーが観測できる情報に依存する。

自動応答一般の勧告はRFC 3834に先立って定められ、RFC 5230はvacationがそのpersonal responderの考え方に沿うと明記する。その後RFC 6131は秒単位の間隔を追加し、ゼロなら毎回返信する動作を定義した。RFC 6133はpresenceや連絡先情報との組み合わせを例示し、RFC 8580は生成した返信のコピーをメールボックスに保存する任意機能を追加した。これらは仕様の展開であって、普及率の測定ではない。

本文以外にも応答の設計はある

RFC 5230はUTF-8とMIMEを扱い、複数言語の本文をひとつのメールに入れることもできる。ヘッダーから言語を選ぶスクリプト例はあるが、単純な文字列検査は複雑な値で誤る可能性があるとも警告する。さらに、同僚と見知らぬ人では適切な語調が違うことがある。言語だけでなく、誰に何をどう伝えるかも選択対象だ。

この動作は限定的で、ひとつのスクリプトで一度だけ実行でき、reject/refuseとは併用できず、Sieveの暗黙のkeepを取り消さない。これは言語内での位置づけであって、RFC 3028が扱った一般的なアクション選択の論点とは別だ。RFC 5230の固有の歴史的論点は、新たに作るメッセージの宛先、応答の識別、ヘッダー、そして再送間隔にある。

史料から分かるのは設計であり、あらゆるサービスで安全だったかどうかではない。転送された別名が同じ利用者のものか、メールが本人にだけ宛てられたのかをサーバーが正確に判断できない場合もある。標準は観測可能な条件と限られた記憶で、自動化を囲い込もうとした。不在通知は保存済みの一文ではなかった。誰かに向けた、時間制限付きの送信許可だった。

出典