Кратко

  • RFC 1344 различал транспорт внутри однородной почтовой среды и gateway между разными средами. Relay, менявший тело письма, уже выполнял вторую роль.
  • MIME позволял вернуть непонятное сообщение целиком, разделить большой объект, перенести внешнее тело или защитить байты кодированием. Эти операции не доказывали одинаковую степень сохранности.
  • Trace и предложенный запрет отправителя делали вмешательство видимым. Поздние MIXER и DSN сохраняли также факт потери, исходный и конечный адрес, общий и родной код ошибки.

Одного статуса было мало

Почтовый транспорт мог доставлять MIME-сообщение, не понимая изображения, звук и структуру всех частей. Это было достоинством: новый формат тела не требовал одновременной переделки каждого MTA на маршруте.

RFC 1344 воспользовался этой совместимостью, чтобы ограничить полномочия. Transport перемещал письмо в достаточно однородной системе. Gateway соединял существенно разные системы, где преобразование иногда неизбежно. Обычному транспорту менять содержимое считалось неприемлемым.

Документ привёл характерное исключение. SMTP relay на крайне дорогой межконтинентальной линии мог захотеть изменить сообщение ради приемлемой услуги. Но экономический мотив не оставлял его нейтральным. После изменения он должен был переопределить себя как gateway.

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

Возврат мог сохранить непонятный оригинал

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

RFC 1344 показал multipart, где одна часть объясняла отказ человеку, а вторая включала всё отвергнутое сообщение как message/rfc822. Почтовой программе не требовалось интерпретировать вложенный объект. Ей требовалось не разрушить его границы.

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

RFC 3464 позднее определил машинно-обрабатываемый Delivery Status Notification. Он разделил поля всего сообщения и результаты отдельных получателей, позволил хранить адрес отправителя и конечный адрес после переадресации, а также общий статус и специфический код чужой системы. Переведённая категория помогала автоматизации; оригинальный код сохранял условия сбоя.

Пять операций не означали один результат

Защитное кодирование при переходе ASCII–EBCDIC меняло транспортную форму, чтобы отдельные символы не исчезли. После base64 или quoted-printable получатель обычно мог восстановить прежние байты. Целью было сохранение объекта.

GIF–JPEG conversion создавал другое представление. Меньший JPEG снижал нагрузку дальней линии, а GIF мог быть удобнее для некоторых систем того времени. Успех конвертера не доказывал одинаковые детали, поддержку формата или удовлетворительный просмотр.

message/partial решал проблему размера. Отправляющий или принимающий gateway мог разделить или собрать сообщение. Однако ограничения дальней сети нередко приходилось угадывать. Создание правильного набора фрагментов не подтверждало, что набор дошёл полностью.

message/external-body переносил в письмо указатель на большие данные. Шлюз мог получить объект заранее, разместить ближе к адресату или изменить ссылку. RFC предложил сохранять и первоначальный указатель, и развёрнутую копию как alternatives. Удобство не должно было стирать происхождение и путь к более свежей версии.

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

След преобразования называл действующее лицо

При смене формата RFC 1344 настоятельно рекомендовал добавлять trace information, вероятно в Received. Если выход отличался от входа, почтовый путь должен был показать место решения.

В качестве голоса отправителя предлагались Content-Conversion: prohibited и permitted. Это предложение Informational RFC, а не доказательство универсального стандарта. При отсутствии поля многие gateways могли предположить разрешение. Получатели при этом не получали симметричного права выбора.

Асимметрия соответствовала раздельному знанию. Отправитель знает оригинал; gateway — стоимость связи и возможности своих инструментов; адресат — своё ПО и задачу. Trace не объединяет их волю. Он лишь мешает посреднику исчезнуть из истории.

RFC 2156 для MIXER между X.400 и RFC 822/MIME позже различал запрет преобразования, запрет при потере, неподдерживаемый носитель, преобразование с потерей и сбой. Шлюз добавлял trace conversion. Полная поддержка подразумевала семантическое соответствие без существенной потери. Это не доказывает повсеместное принятие идеи 1992 года, но показывает, почему одного “relayed” недостаточно.

Путь продолжался после шлюза

Исходник, приём транспортом, обнаруженное ограничение, решение gateway, новый объект, приём следующим MTA, доставка каждому получателю, отображение программой и использование человеком — отдельные события.

Конвертер может закончить работу, а клиент не открыть результат. SMTP может принять письмо до ошибки конкретного ящика. Локальная копия может устареть. DSN может быть точным и ничего не знать о чтении.

RFC 1344 сообщил, что вопросы безопасности не обсуждались. Он не свидетельствует об атаке или злоупотреблении. Его вывод уже и полезнее: изменение чужого представления есть решение с властью. Доказательство действия должно оставаться отдельным от доказательства его последствий.

Источники

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