Кратко

  • RFC 9671 вводит processcalendar для автоматической обработки календарных данных в электронной почте с ограничениями по формату, адресату и безопасности.
  • Значение updated охватывает три разных итога: объект изменён, помечен отменённым или удалён; :reason при этом может быть пустым.
  • Надёжное свидетельство связывает решение Sieve с последующим чтением UID, календаря, STATUS, участия получателя, сигналов, вложений и видимого результата.

Два подразделения получили одинаковые отмены встречи. В первом script не использовал :deletecancelled: запись осталась в календаре со статусом CANCELLED. Во втором option был включён, и запись исчезла. В обоих журналах стояло одно слово — updated.

Ни один журнал не был обязательно ошибочным. RFC 9671 прямо определяет updated как результат, при котором календарный объект обновлён, отменён или удалён. Это компактная развилка для Sieve, а не полное описание перехода состояния.

Проблема возникает позже, когда это слово становится официальным ответом на более широкий вопрос. Команда поддержки говорит, что событие «обновилось». Аудитор понимает, что оно сохранилось. Пользователь видит, что оно исчезло. Все используют одну метку для разных реальностей.

Допуск к изменению начинается до outcome

processcalendar расширяет Sieve и позволяет разбирать машиночитаемые календарные данные в MIME-сообщении, добавлять, обновлять или удалять элементы. Повреждённые данные должны игнорироваться.

Если сообщение содержит несколько MIME-частей с календарём, реализация должна проверить их семантическую эквивалентность. При различии обработка запрещена; при совпадении применяется только одно представление. Видимый текст, text/calendar и файловое вложение не получают права рассказывать три разные версии одной встречи.

Действие не должно менять статус участия получателя. Появление объекта в календаре не означает согласия присутствовать. Если интерфейс после автоматического добавления показывает подтверждённое участие, он создаёт утверждение, которого processcalendar не делал.

Стандарт также рекомендует удалять alarms до применения данных. Иначе нежелательные уведомления могут распространяться на несколько устройств. updated не сообщает, выполнено ли это действие, поэтому итоговые alarms нужно наблюдать отдельно.

Адрес назначения и полномочие организатора — разные факты

Без :allowpublic требуется корректное iTIP-сообщение, а один из адресов получателя должен совпадать с целью метода. Для REPLY это ORGANIZER, для REQUEST, CANCEL и ADD — ATTENDEE. Источником адреса может быть связь, известная сервису, конечный envelope recipient или список :addresses.

Каждый источник имеет свою происхождение. Поле, видимое пользователю, не обязательно равно адресу окончательной доставки. Alias в :addresses расширяет область действия script. Совпадение ATTENDEE подтверждает назначение, но не полномочие отправителя и не согласие получателя.

:organizers позволяет требовать совпадения ORGANIZER с внешним списком и корректность iTIP. Без option RFC 9671 не выполняет такую проверку. Со списком подтверждается локальная политика, но не текущая воля конкретного человека. Поэтому нужны версия списка, владелец и срок применимости.

Почтовая аутентификация остаётся входным сигналом

RFC 9671 называет автоматическое изменение календаря возможным каналом злоупотребления. Данные в сообщении, помеченном как spam или malicious, обрабатывать нельзя. Стандарт рекомендует известных отправителей и предостерегает от потенциально опасных или недоверенных. В оценку могут входить S/MIME, SPF, DKIM и DMARC.

Их смысл не следует обесценивать или расширять. SPF связывает SMTP client с политикой домена. DKIM проверяет подпись домена над выбранными частями сообщения. DMARC оценивает alignment и политику получателя. S/MIME требует проверки подписи, сертификата и привязки identity.

Положительный результат не доказывает сам по себе, что человек-организатор захотел удалить встречу именно сейчас. Законный аккаунт может быть захвачен, уполномоченное приложение может выбрать неверный UID, корректная система может повторно отправить устаревшее решение. Техническое доверие — часть policy, а не замена policy.

Конечное состояние читается после Sieve

При наличии Variables :outcome получает no_action, added, updated или error. :reason может пояснить итог, но при отсутствии причины должен быть пустой строкой. Оператор не вправе превращать пустоту в выдуманное объяснение.

:updatesonly запрещает добавить новую UID и может правильно привести к no_action. :calendarid задаёт место для нового объекта; без него выбирается default calendar. Успешное added не доказывает, что выбран организационно правильный календарь.

Для отмены :deletecancelled говорит реализации, что объект следует удалить. Без него объект сохраняется с отменённым статусом. Удаление сформулировано как SHOULD, поэтому наличие option не является наблюдением факта. Только последующее чтение различает два исхода.

Первая половина свидетельства включает message ID, окончательного получателя, generation script, решения spam/malware, результаты аутентификации, все calendar MIME parts, их эквивалентность, iTIP method, UID, ORGANIZER, ATTENDEE, внешний список, options и выбранный календарь.

Вторая половина читает рабочее состояние: существует ли UID, где он расположен, каковы revision и STATUS, сохранился ли статус участия, удалены ли alarms, декодированы и проверены ли embedded attachments. При обнаружении вредоносного вложения обработка календарных данных запрещена.

Судьба письма также отделена. processcalendar не отменяет implicit keep Sieve. Письмо может сохраниться после удаления встречи. Удаление письма не доказывает удаления объекта, как и отсутствие объекта не доказывает исчезновения письма.

Руководство CalConnect подчёркивает, что календарный abuse может размещать события в прошлом и будущем, использовать recurrence и вызывать alarms на многих устройствах. Пользовательский эффект продолжается после выполнения filter. Его нужно наблюдать отдельно.

RFC 9671 честно предоставляет минимальный общий механизм. Он не обещает, что четыре слова восстановят всю реальность. Ответственность организации — не подменять работающий календарь символом из журнала.

Sources