ナレッジベース
自分で書くルール
自分で決めた条件と、それに一致したものをどう扱うか。
詳細
- 「設定 → ルール」で作成するほか、すべてのワークスペースで有効な /rules のREST APIからも作成できる。ルールは、届いたメッセージに対する条件の一覧と、それに一致したものに対して実行するアクションの一覧からなる。メールボックスごとに100ルール、各ルールは最大20条件と10アクションまで。これはプランの制限ではなく、ループするスクリプトへの防御である。101件目のルールは課金されるのではなく、その旨のメッセージとともに拒否される。
- 条件が問い合わせられる項目は21種類ある。Fromのアドレスとそのドメイン（example.com への一致は mail.corp.example.com も含む）、SMTPのエンベロープ送信者、To、Cc、Bcc、任意の受信者、Reply-To、プラスタグを除いた実際の配信先アドレス、件名、本文、任意の名前付きヘッダー、List-Id、添付ファイルの名前・種類・サイズ、添付ファイルの有無、メッセージ全体のサイズ、スパム判定、そしてUTCでの到着時刻と曜日である。一致方法はglob（* と ?）、contains、equals、starts with、ends with、そして数値4項目についての大小比較である。パターンには英数字が2文字以上必要なので、単独の * は、今後届くすべてのメッセージに一致するのではなく、書いた時点で拒否される。
- 条件はすべて一致か、いずれか一致かを選べ、各条件に個別にNOTを付けられる。入れ子の括弧はない。(A and B) or C は2つのルールになるが、半年後に読み返すときにはどのみちそう読むことになる。
- アクションは11種類。ラベルを付ける、ラベルを外す、アーカイブする、既読にする、スターを付ける、迷惑メールに振り分ける、ゴミ箱に入れる、転送する、テンプレートから自動返信する、送信者をブロックする、メッセージをそのまま拒否する、である。ルールは並べた順に上から実行され、どれも削除せずにオフにできる。処理を停止と指定したルールはそこでパスを終えるので、それより下は評価されない。2つのルールがどちらもフォルダーを指定した場合は後のほうが勝つ。番号付きの一覧とは、そういう意味だからである。
- 入口での拒否はエンベロープのみを対象とし、それ以外は書き込み時に拒否される。550 に応じるのはメッセージを渡してきた相手であり、メーリングリストの場合それはリストである。リストはそれをバウンスする購読者と解釈し、1人の投稿を止めたかっただけのものからあなたを購読解除してしまう。Fromヘッダーの送信者だけに一致するルールは、ブロックの場合とまったく同じくSpamへ振り分ける。
- 自動返信は機械には応答しない。Auto-Submitted、Precedence: bulk、list、junk、List-Id または List-Unsubscribe ヘッダー、X-Autoreply、X-Autorespond、そしてあらゆるバウンスが持つ空のエンベロープ送信者に対しては抑制される。それに加えて、1人の送信者に対する返信は1日1通までである。返信ルールを持ち、こうした防御のない2つのメールボックスは、誰かが気づくまで互いにメールを送り続ける。
- 転送は、届いたメッセージそのものではなく再構成されたコピーである。送信経路を通るため、送信者のDKIM署名は残らず、珍しいヘッダーや特殊なパートも残らない。元のメッセージは .eml の添付として同行するので、ヘッダーと正確なパートは読める形で残る。ただし5MBの添付上限を超える場合は別で、その場合も転送は読める本文とともに送られ、元のメッセージは自分のメールボックスに残る。それが起きたことは何も知らせないので、ここは知っておく価値がある。宛先はルールを書いた時点で検証されるが、形式だけである。ops や、ドットのない ops@example は、一致するメッセージごとに失敗するのではなく、書いた時点で拒否される。有効なアドレスとして成立する打ち間違い（[email protected] のつもりの [email protected]）は受け付けられる。またルールの宛先は、アドレス転送の宛先のように本人の承認を求められることがないため、コピーは入力したとおりの宛先に送られる。
- ルールは有効にする前に試せる。直近30日（最長1年、最大200件）を対象に指定すると、自分のメッセージのうちどれが該当し、それらに何が行われたはずかを、実際には1件も変更せずに報告する。これに答えるのは配信経路で動くのと同じマッチャーだが、保存済みのメッセージはSMTPが渡したメッセージそのものではない。エンベロープ送信者、ヘッダーのマップ、List-Id、配信先アドレス、通信時のサイズはその時点で失われているため、21項目のうち11項目はドライランで異なる答えを返すか、まったく答えられない。ダイアログはそれらを黙って不一致として扱うのではなく、名前を挙げて示す。最も顕著なのは入口で拒否するルールで、これはエンベロープ送信者の条件を必ず含む必要がある一方、保存済みの内容ではそれに答えられないため、実運用ではどれだけ拒否するとしても、プレビューは何にも一致しないと報告する。
- 遡及的な処理はなく、それを可能にするボタンも意図的に用意していない。すでにあるメールボックス全体にルールを適用する処理は際限がなく、取り消しもできず、触れたすべてのメッセージを受信トレイの先頭へ引き戻してしまう。ルールが決めるのは、次に届くメールに何が起こるかである。
- 各ルールが何をしたかはメッセージごとに記録される（適用されたアクションと、それとは別に、拒否されたアクションとその理由）。そのため「なぜこれはここにあるのか」「なぜ不在通知はあれに返信しなかったのか」のどちらにも答えられる。ログはルール名を保持するので、ルールの名前を変えたり削除したりした後でも正しく読める。
- 自分のドメイン上のすべてのアドレスに適用されるため、ルールは黙って何もしない場所で提示されるのではなく、届くものすべてに及ぶ。
- エンジンが判定できない場合（新しいクライアントからの条件、応答しないデータベースなど）、メッセージは本来どおり配信され、その失敗は記録される。例外を投げるルールは、届かないメッセージを意味するからである。