Кратко

  • RFC 2034 помещает class.subject.detail перед текстом почти каждого ответа SMTP классов 2xx, 4xx и 5xx. Класс расширенного кода обязан совпадать с классом основного ответа.
  • Сервер отправляет код даже без EHLO со стороны клиента; запросить или отключить его нельзя. Документ считает это узким исключением совместимости, а не общим разрешением обходить согласование расширений.
  • Структура помогает классификации, повторным попыткам и локализации, но доказывает только категорию, заявленную сервером в одном обмене, а не первопричину, окончательную доставку или прочтение.

Одинаковый 550 может потребовать разных действий. Неизвестный адрес, запрет пересылки и политика доступа относятся к постоянному отказу, но устраняются по-разному. Если машина ищет смысл в свободной фразе, словарь каждого продукта и язык каждого администратора становятся частью алгоритма.

RFC 2034, опубликованный в октябре 1996 года, сохранил традиционный трёхзначный ответ и текст для человека. В начало текста он добавил класс, предмет и деталь. Крупное решение осталось за старым кодом, тонкая категория получила общий формат, а объяснение могло оставаться естественным и локальным.

Два машинных уровня должны соглашаться

Расширение объявляется ключом ENHANCEDSTATUSCODES, не имеет параметров и не вводит новых команд. Класс принимает 2, 4 или 5; предмет и деталь содержат от одной до трёх цифр. Ответ 2xx сочетается с 2.X.X, 4xx — с 4.X.X, 5xx — с 5.X.X.

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

Интерфейс способен показать русское пояснение по коду и сохранить исходный текст. Но согласованность не равна достоверности причины. 550 5.1.1 доказывает, что сервер заявил постоянную проблему почтового ящика назначения; он не проверяет удалённую базу, полномочия автора политики или другой разрешённый путь.

Точные исключения важны для измерения

Требование действует для строк 2xx, 4xx и 5xx, кроме первого приветствия и ответов на HELO или EHLO. 3xx явно исключены. Поэтому промежуточный 354 в примере RFC не несёт расширенного кода.

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

Примеры 2.1.0, 2.1.5, 5.1.1, 5.7.1, 2.6.0 и 2.0.0 показывают работу грамматики, но не цепочку до читателя. Принятие данных — переход состояния принимающего сервера, не доказательство помещения в папку, показа или открытия.

Код появляется без выбора клиента

Совместимый сервер прикрепляет коды независимо от того, применил ли клиент EHLO. Нет команды включения и нет отказа. Это отличается от обычной модели расширений.

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

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

Много строк — одно заявление

В многострочном ответе один и тот же расширенный код должен начинать текст каждой строки. Пример повторяет 5.7.1 в двух строках 551; общие правила SMTP требуют и одинакового основного кода.

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

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

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

Свидетельство сервера не закрывает расследование

Локальная политика может поставить 4.X.X на повтор и завершить попытки по 5.X.X. Предмет и деталь направят событие к специалистам по адресам, ёмкости, безопасности или конфигурации. История покажет, как классификация изменилась после выпуска версии.

Код не объясняет внутренний сбой, не проверяет правильность фильтра и не обещает тот же ответ завтра. Положительный класс также не доказывает окончательную доставку, отображение или прочтение.

Пример RFC позднее строит уведомление и отмечает, что сообщающий MTA убрал расширенные коды из части диагностических полей для краткости. Живой ответ, журнал очереди, последующее уведомление и экранная сводка — разные артефакты. Каждое преобразование способно потерять сведения.

RFC 5248 впоследствии создал реестр IANA, чтобы определения кодов не конфликтовали. Регистрация координирует словарь, а не удостоверяет конкретный диагноз. Зарегистрированный код может быть неверно выдан программой.

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

Источники