Кратко

  • Environment-значения сообщает интерпретатор в конкретной точке обработки. Стандартное имя поля не аутентифицирует метод получения и не превращает непосредственный сетевой узел в исходного автора.
  • RFC 5183 прямо предупреждает: remote-host может быть получен через недоверенный PTR, владелец которого способен выбрать удобный домен.

В журнале соединения находился IP общего почтового реле. Рядом Sieve записал remote-host с доменом партнёра. Правило доверяло суффиксу имени и пропускало письмо мимо дополнительной проверки.

Оба значения могли быть корректны в своих узких смыслах. IP был адресом непосредственного peer, а PTR — опубликованным именем этого адреса. Ни одно не доказывало, кто создал исходное сообщение и кому принадлежит деловая роль «партнёр».

Это аналитическая ситуация, а не утверждение о конкретном инциденте. Она показывает, почему граф происхождения сильнее одного выбранного поля.

Среда исполнения — отдельный источник данных

RFC 5183 вводит capability environment. Тест получает имя item и ключи, использует выбранные match-type и comparator, а по умолчанию — :is и i;ascii-casemap.

Текущее сообщение не является прямым источником значения. Информацию извлекает среда интерпретатора. Поэтому доказательство начинается с процесса и точки наблюдения: какой компонент видел соединение, какие заголовки ещё не существовали, какая прокси-цепочка была раскрыта и каким способом построено поле.

domain описывает основной DNS-домен контекста, host — хост исполнения. location выбирает MTA, MDA, MUA или message store. phase помещает обработку до, во время или после финальной доставки. name и version относятся к продукту. remote-host и remote-ip относятся к применимому удалённому клиенту SMTP, LMTP или Submission.

Список не содержит универсального поля «исходная организация». Он также не подтверждает патч, транзакцию хранения или человеческое прочтение. Эти связи строит локальная архитектура.

Отсутствие и пустота должны остаться видимыми

Если item неизвестен реализации, тест обязан вернуть false, но не аварийно завершить script. Это позволяет переносить правила между системами.

Проверка :contains с пустой строкой обнаруживает сам факт существования item. Однако remote-host должен быть пустым, если имя получить нельзя. RFC 5231 определяет :count как ноль для пустого значения и один для непустого.

Получаются разные состояния: поля нет; поле есть, но пусто; поле непустое, но источник не проверен; поле удовлетворяет заявленной политике доверия. Они не должны сливаться в одну ветвь «разрешить».

Особенно опасен тихий fallback после миграции. Отсутствующее vendor-поле не означает старое безопасное значение. Невозможность получить hostname не делает IP доверенным. Неопределённость должна давать отдельный результат и отдельную запись.

PTR подтверждает публикацию, а не корпоративную роль

В security considerations RFC 5183 допускает любой способ получения remote-host и подчёркивает разную надёжность. Распространённый способ — PTR-запрос по клиентскому IP. Источник может быть недоверенным.

Контролирующий reverse-зону может указать выбранное им доменное имя. Поэтому проверка *.example.com не годится как доказательство того, что письмо пришло не извне. Протокол может отработать безупречно, а полномочие, присвоенное строке, останется выдуманным.

Для важного решения сохраняются peer IP, транспорт и наблюдаемый hop, reverse query, resolver, ответ, TTL и возраст кэша, DNSSEC-состояние там, где оно применимо, и политика forward-confirmation. Затем фиксируется связь между DNS-именем и принципалом, которого хочет авторизовать бизнес.

Даже проверенная DNS-цепочка не доказывает автоматически трудовые отношения, владельца сообщения или отсутствие компрометации. Она ограничивает утверждение данными DNS.

Непосредственный IP тоже требует топологии

remote-ip ближе к факту TCP-соединения, однако архитектура электронной почты включает relay, gateway, submission service, proxy и NAT. Интерпретатор может видеть доверенный входной relay, а не автора. Или видеть внешний relay, который законно представляет множество доменов.

Правило должно назвать hop: внешний sender-to-MTA, внутренний relay-to-MDA, LMTP delivery или иной участок. Для каждой границы указываются разрешённые утверждения. Адрес общего relay может подтверждать выбранный маршрут, но не индивидуального отправителя.

Когда remote-ip и remote-host кажутся противоречивыми, нельзя выбирать строку, которая лучше согласуется с ожиданием. Нужно проверить, были ли они получены из одного hop, в одно время и под одной политикой. Расхождение — сигнал для расследования происхождения.

Такой подход отделяет наблюдение от символической власти. Доменное имя остаётся полезным для маршрутизации и диагностики, не превращаясь в удостоверение.

MS и post не завершают цепочку

location=MS классифицирует исполняющий сервис как message store. Он не указывает worker, replica, build или transaction. phase=post описывает положение относительно финальной доставки, но не подтверждает индексацию и видимость клиенту.

RFC 6785 расширяет environment для IMAP events. Он задаёт MS и post, добавляет пользователя, email, причину APPEND/COPY/FLAG, mailbox и changed flags.

imap.mailbox фиксируется в начале исполнения и не меняется после fileinto. Это начальный контекст, а не финальный адрес. imap.changedflags перечисляет изменившиеся flags, но не говорит, были они поставлены или сняты; текущее состояние проверяется отдельно.

Такая точность полезна для графа событий. Узел invocation не подменяет узел action, а action не подменяет storage receipt. Если политика требует конечного состояния, граф должен дойти до него.

Registry определяет словарь, не доверенную модель мира

Стандартизованные items определяются Standards Track или Experimental RFC. Vendor items начинаются с vnd. и регистрируются против конфликтов. Актуальный IANA registry включает исходные и IMAP-поля, а также vendor namespace.

Это минимальная общая спецификация: участники согласуют названия, сохраняя свободу локальной реализации. Будущие документы могут добавить группы значений, а оператор — отказаться от неизвестной семантики.

Регистрация не является тестом продукта. Она не определяет, как часто обновляется поле и кто его контролирует. Одинаковое location в двух системах не гарантирует одинаковую commit boundary. Vendor-строка не переносится без контракта.

RFC 5463 позволяет проверять capabilities через ihave. Capability support, item existence, nonempty value и trustworthiness независимы. ManageSieve управляет script, но не доказывает путь исполнения конкретного сообщения.

Граф происхождения для каждого решения

Необратимая политика получает immutable decision ID, script hash и identity загруженного interpreter build. Для каждого environment test журнал хранит item, raw value, source method, peer, location, phase, comparator и branch.

Далее добавляются Sieve action, ответ transport/storage component и сверка с конечной mailbox или пользовательским состоянием. Так можно увидеть, где расходятся намерение, наблюдение и эффект.

Граф полезен и при смене поставщика. Новая система не обязана имитировать старые строки, если она способна доказать тот же ограниченный факт. И наоборот, совпавшая строка не скрывает смену источника.

Закрывающий вопрос: можем ли мы проследить каждое полномочие от наблюдаемого hop до результата, или выбрали самый знакомый label? В первом случае RFC 5183 помогает автоматизации. Во втором он лишь поставляет символ для чужого предположения.

Источники

  1. RFC 5183 — HTML
  2. RFC 5183 — текст
  3. Информационная страница RFC Editor
  4. Страница документа IETF Datatracker
  5. История IETF Datatracker
  6. Ссылки IETF Datatracker
  7. Errata RFC 5183
  8. RFC 5228 — базовая спецификация Sieve
  9. Информационная страница RFC 5228
  10. RFC 5231 — relational extension
  11. RFC 5598 — архитектура интернет-почты
  12. RFC 6785 — IMAP events в Sieve
  13. Информационная страница RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — расширение Sieve ihave
  16. Реестр Sieve Extensions IANA
  17. Реестр Sieve Environment Items IANA
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация и добровольное принятие
  20. Heng Lu — приоритет работающего кода