要約

  • RFC 9671 は、カレンダー情報を自動適用する前に、形式、複数 MIME 表現の意味的一致、対象受信者、送信者の信頼性を確認する境界を定める。
  • updated は内容変更、取消し、削除を一つにまとめ、アラームが除去されたかどうかは表さない。
  • 監査可能な証跡には、メール側の判断だけでなく、適用後の UID、STATUS、参加状態、アラーム、添付物と利用者画面の確認が必要である。

翌月の予定が自動で登録され、処理ログには updated と残った。ところが予定には十五分前、五分前、開始時刻の三つのアラームが残っていた。さらに毎週の繰り返しだったため、複数端末が同じ通知を鳴らし続けた。

これは単なる表示上の不便ではない。RFC 9671 は、カレンダー情報を適用する前にアラームを除去することを SHOULD としている。除去しなければ、受信者に望まない通知を発生させ得るからだ。ただし :outcome の値は、その処理が行われたかを報告しない。

つまり、正しい Sieve 結果と望ましくない利用者結果は同時に成立し得る。標準が矛盾しているのではない。観測対象が違うのである。

自動変更の前に、入力を一つの意味に絞る

processcalendar は Sieve に追加される action で、MIME メールに封入された機械可読の予定情報を解析し、追加、更新、取消し、削除を行う。形式不正の情報は無視しなければならない。

一通のメールに複数のカレンダー MIME 部分がある場合、実装は意味的な同等性を確認する。意味が異なれば処理してはならず、同等なら一つだけを処理する。見た目の本文と機械処理用データが異なる時に、都合のよい方を選ぶ余地を与えないための境界だ。

また、この action は受信者の参加状態を変更してはならない。予定をカレンダーに置くことと、本人が出席を承諾することは別の行為である。画面上で両者を同じ状態に見せれば、製品が標準の境界を消してしまう。

宛先判定は人の同意ではない

:allowpublic を使わない場合、情報は正しい iTIP メッセージでなければならず、受信者に属するメールアドレスが対象と一致する必要がある。REPLY では ORGANIZER、REQUEST、CANCEL、ADD では ATTENDEE が対象になる。アドレスの根拠は、実装が知る関連アドレス、最終 envelope recipient、または :addresses である。

この三つは同じ証拠ではない。表示された宛先は最終配送先と異なり得る。:addresses の追加は script 作者による適用範囲の拡張である。ATTENDEE の一致は対象を示すが、主催者の権限や受信者の承諾までは示さない。

:organizers は外部リストに ORGANIZER が含まれることを要求できる。省略時、RFC 9671 は ORGANIZER property を検証しない。使用時も、証明できるのは設定されたリストとの一致であり、その人物が今回の変更を意図したことではない。

認証結果を人間の意思まで拡張しない

RFC 9671 は、利用者の操作なしに予定を変える仕組みが calendar abuse の経路になり得ると認める。spam または malicious と判定されたメールは処理してはならない。既知の送信者を優先し、潜在的に悪意または信頼性のない送信者を避けるべきだとする。S/MIME、SPF、DKIM、DMARC は信頼判断の材料になり得る。

しかし、それぞれの control には固有の主語がある。SPF は SMTP client と domain policy、DKIM は署名 domain と選択された message content、DMARC は alignment と receiver policy、S/MIME は certificate と署名検証を扱う。いずれも「表示名の人物が今この予定を変更したい」という心理的事実を直接証明しない。

正規の account が侵害されることも、承認済み application が誤った UID を選ぶこともある。認証を軽視すべきなのではない。認証の証明範囲を守ったうえで、calendar policy が別の判断を引き受けるべきなのである。

updated の後から本当の確認が始まる

Variables extension を使うと、:outcome は no_action、added、updated、error のいずれかになる。:reason は理由を記録できるが、理由が得られない場合は空文字列になる。

updated は、内容更新、取消し、削除を一つにまとめる。:deletecancelled があれば、取消し対象を削除することが推奨される。なければ STATUS を CANCELLED にして残す。どちらも updated になり得るし、option が存在するだけでは削除の実行を証明しない。

したがって証跡は二段階で作る。最初に message ID、最終 envelope recipient、script generation、spam/malware 判定、認証信号、全 calendar MIME parts、意味的一致、iTIP method、UID、ORGANIZER、ATTENDEE、外部リスト、option、解決された calendar を記録する。

次に calendar を読み戻す。UID は存在するか。どの calendar にあるか。revision と STATUS は何か。受信者の参加状態は変わっていないか。アラームは除去されたか。埋め込み添付物は decode と scan を終えたか。悪性なら calendar data は処理されてはならない。

メールの残存も別である。processcalendar は Sieve の implicit keep を取り消さない。メールを残したまま予定が消えることも、予定が残ったままメールを削除することもできる。一方の存在は他方の証明にならない。

CalConnect の calendar abuse 指針は、悪意ある予定が過去や未来の任意の位置に置かれ、recurrence と複数 device の alarm によって影響を繰り返し得ると説明する。action の終了時刻と利用者への影響の終了時刻は一致しない。

RFC 9671 が提供するのは、共有可能な最小仕様である。その最小性を尊重するなら、symbolic な成功を running system の全体結果に膨らませてはならない。

Sources