Кратко

  • RFC 5248 создал управляемый словарь расширенных кодов состояния SMTP: три таблицы, публичные спецификации, заявители и ответственные за изменения.
  • Реестр подтверждает назначение значения, а не диагноз конкретного сервера, полноту клиентского журнала, правильность повтора или итоговую доставку сообщения.

Координата в словаре не является координатой сообщения

В инфраструктуре электронной почты одно сообщение получает множество состояний. Сервер отвечает на команду, клиент сохраняет или теряет подробности, очередь назначает следующую попытку, другой сервер принимает передачу, конечная система решает судьбу содержимого. Расширенный код относится к одному моменту этой последовательности.

RFC 3463 сделал пространство кодов расширяемым, но не дал явного механизма регистрации и отслеживания новых значений. Когда появились конфликтующие определения, RFC 5248 ввёл реестр IANA и правила его пополнения. В статусе BCP 138 он также обновил документы, которые уже добавляли значения, включая RFC 4468 и RFC 4954.

Тем самым был устранён риск семантического столкновения: стало возможно узнать, какое значение занято, на какой документ оно опирается и кто имеет право его менять. Однако реестр не получил доступа к журналам серверов и очередей. Он координирует название условия, но не удостоверяет, что условие действительно возникло в конкретной транзакции.

Три таблицы задают разные границы

Форма кода состоит из класса, предмета и детали. RFC 5248 ведёт таблицу подкодов класса, таблицу подкодов предмета и таблицу перечисленных кодов. В перечисленной записи предмет соединён с деталью, а класс остаётся шаблонным: определяющая спецификация может допускать одно условие более чем в одном классе.

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

Связанный базовый ответ не является исключительным. Указанный трёхзначный код не запрещает другие сочетания; поле может содержать Any или Not given. Если система контроля превратит его в взаимно-однозначную матрицу, она добавит ограничение, которого RFC сознательно не вводил.

Отдельное значение сохраняет неопределённость. X.0.0 — единственный неопределённый код, применимый, когда известен только класс ответа. Он не позволяет достроить предмет и деталь по предположению. Честно сохранённый пробел лучше ложной точности.

Эксперт проверяет пригодность определения

Для новых значений действует Specification Required. RFC 5248 требует доступности спецификаций вне стандартного процесса и подчёркивает задачу предотвращения путаницы и коллизий без лишних барьеров. Современное описание политики в RFC 8126 сочетает постоянно доступную публичную спецификацию с рассмотрением назначенным экспертом. Эксперт оценивает ясность, устойчивость и техническое качество.

Это проверка предложения для общего пространства, а не аудит работающей реализации. Эксперт не исследует производственную очередь, не воспроизводит сбой одного адресата, не сертифицирует логику каждого сервера и клиента. Хорошо определённый код может быть выбран не для того события; реальное событие может получить слишком общий код.

Полномочие на изменение также ограничено. Стандартизованная регистрация обычно меняется через обновление стандарта. Нестандартная находится у указанного контролёра. Обычные исправления касаются описания или ссылки, а не скрытой замены номера и примерного текста. IESG сохраняет исключительное право вмешаться ради разрешения конфликта.

Начальное наполнение показывает неоднородность происхождения. В реестр вошли значения из RFC и значения, уже использовавшиеся отраслью без опубликованной спецификации. Несколько кодов безопасности были внесены под управлением IESG. Условие «Trust Relationship Required» получило X.7.14 вместо прежнего применения X.7.8. Реестр способен исправить семантический адрес, но не доказывает переход каждой программы и не переписывает автоматически смысл старых журналов.

Класс направляет действие, но не определяет вечность

RFC 3463 описывает класс 2 как успех в уведомлении о состоянии доставки. Класс 4 означает устойчивый временный сбой, после которого будущая попытка может оказаться успешной. Класс 5 означает постоянный сбой, обычно требующий изменить сообщение или назначение.

Для совместимости это сильные правила, но не предсказания. RFC 5321 требует от клиента SMTP действовать по коду ответа, а не по поясняющему тексту. 4yz допускает повтор позднее при подходящих условиях. 5yz говорит, что не следует без изменений повторять тот же запрос. При этом даже кажущееся постоянным состояние позднее может быть исправлено.

Следовательно, 4.x.x не обещает успех следующей попытки, а 5.x.x не доказывает неизменность мира. Очереди нужны идентификаторы сообщения и получателя, номер попытки, время, ответивший сервер, маршрут, конфигурация и дальнейшие ответы. Класс ограничивает ближайшее действие, но не является квитанцией об исходе.

RFC 2034 описывает передачу расширенных кодов в ответах SMTP. RFC 5248 управляет их словарём. Логика выбора на сервере, разбор на клиенте, сохранение в очереди и автоматическое решение лежат на других поверхностях. После приёма следующим узлом ещё остаются конечное принятие, обработка почтовым ящиком и фактическое использование сообщения.

Больше деталей может означать больше риска

В разделе безопасности RFC 5248 предупреждает: расширенные коды способны раскрывать внутреннее устройство почтовой системы. При аутентификации различие между «пользователь не найден» и «неверный пароль» может стать для атакующего способом перечисления учётных записей. Спецификации должны указывать, когда серверу следует ограничить выдаваемые детали.

Поэтому внешний ответ может намеренно быть менее точным, чем внутренний диагноз. Система доказательств должна сохранять оба уровня и политику раскрытия. Недостаток публичных деталей не обязательно означает плохую диагностику, а их избыток не подтверждает истинность причины. Точность, раскрытие и достоверность — разные свойства.

Название, утверждение и подтверждение требуют разных записей

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

Выше расположены действия и результаты: применилась ли политика к правильному сообщению и получателю, состоялась ли следующая передача, приняла ли конечная система, что сделал почтовый ящик, дошло ли содержимое до человека или процесса. Нижняя квитанция не наследует полномочие верхней.

Разделение running code и слоёв реальности у Lu Heng здесь имеет практический смысл. Реестр согласует символы. Реализация применяет значение. Телеметрия наблюдает переходы. Организация принимает решения. Надёжная система связывает эти слои, но не разрешает публичному имени замещать наблюдение за исполнением.

Источники