Кратко

  • В RFC 2156 соответствие MIXER относилось к экземпляру шлюза X.400/RFC 822-MIME, а не только к реализации, которую можно правильно настроить.
  • Локальная установка могла перейти в глобальный сценарий из-за раскрытия списков рассылки и обмена с пользователями X.400 вне первоначального домена.
  • Доказательство связывает функции продукта с активными параметрами, MCGAM, каждым переходом, преобразованием, сохранённой услугой и отдельным исходом доставки.

Роль менялась без смены программы

Лабораторный тест показывает, что продукт способен преобразовать одно сообщение. Он не говорит, какую таблицу использует производство и сколько шлюзов пройдёт сообщение после раскрытия списка. RFC 2156, опубликованный в январе 1998 года, включил эти вопросы эксплуатации в само утверждение о соответствии.

Глобальный сценарий соединял Internet/MIME и X.400 несколькими шлюзами. Объект мог пересекать границу многократно, поэтому требовалось согласованное поведение. Локальный сценарий соединял закрытое сообщество с мировой сетью, а граница поддерживалась связностью или политикой разрешений. Глобальное отображение адресов и другие детали требовали затрат, необязательных для строго локального коридора.

Но RFC описывал переходный эффект. Шлюзы ADMD, рассчитанные на своих клиентов, начинали действовать глобально из-за списков и сообщений от пользователей X.400, не являвшихся клиентами. Получатели и маршрут расширяли функцию того же экземпляра.

Поэтому соответствие применялось к инстанцированному шлюзу, а не только к реализации. Реализация должна была позволять правильную эксплуатацию; наличие возможности не доказывало активную конфигурацию.

Список превращал одно преобразование в цепочку

Пользователь X.400 мог отправить письмо в список на стороне RFC 822, а раскрытие списка добавляло адреса третьих сторон и новых получателей X.400. Сообщение попадало к независимо настроенным шлюзам.

RFC 2156 считал повторные отображения особенно важными для списков. Симметрия и обратимость должны были не допустить лишнего повторного кодирования и дать ответу правильный обратный путь. Но уровень услуги обычно снижался до наименьшего общего знаменателя, приблизительно RFC 822. Услуги X.400 без стандартного аналога не предполагались сохранёнными после X.400→RFC 822→X.400.

Обратимость адреса не доказывала сохранность смысла, уведомлений, trace, запретов преобразования, отображения или действия человека. Рекурсия в одном шлюзе также отличалась от source route через несколько экземпляров с разными картами, версиями и политиками тел.

Appendix G требовал сведений об экземпляре

Если обязательной функции не было, заявлять соответствие запрещалось. Appendix G требовал форматы полей, MCGAM, все отображения trace, доступ ко всем трём глобальным отображениям, RFC 2157 для тел и RFC 2045 при создании MIME. Шлюз должен был назвать транспортные протоколы, версии X.400 и способы доступа к глобальным данным; при SMTP Appendix A становился обязательным.

Продукт может содержать DNS, X.500 и таблицы, тогда как работающий процесс читает устаревший файл. Функция trace может присутствовать, но быть выключена в проверяемом профиле.

Обязательный спутник RFC 2157 называет функцию реализованной, если продукт можно настроить на её использование, и одновременно не требует постоянно держать именно такую настройку. Определение реализации само сохраняет отдельную проверку экземпляра.

RFC 2157 разрешал учитывать возможности получателя, запрос отправителя, эвристику содержимого и ограничения следующего перехода. Два способных шлюза могли по-разному инкапсулировать, отклонять или отмечать потерю. Доказательством служит выполненное решение по конкретному сообщению.

Корректный результат был лишь одной квитанцией

Для одного перехода слово «supported» включало семантическое соответствие, отсутствие существенной потери и требуемое действие. Синтаксически правильный вывод без обязательного отчёта не соответствовал этому определению.

Аудит фиксирует сборку и функции продукта, затем экземпляр, параметры, транспорты и версии. Он сохраняет источник и хеш MCGAM, результат поиска, раскрытия списков, входные и выходные отпечатки, правило, инкапсуляцию, потери и trace. Удалённое принятие, доставка в ящик, отображение и прочтение остаются разными исходами.

Running-Code Primacy Лу Хэна используется здесь как раскрытая редакционная оптика, а не требование RFC: стандарт и бинарный файл показывают возможность, настройки и путь — исполнение. Minimum Initial Specification разделяет локально проверяемые утверждения. On Reality Layers не позволяет символическому ярлыку заменить исполняемое доказательство.

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

Источники