Кратко

  • Клиент мог объявить BODY=8BITMIME и передать октеты со старшим битом только после того, как сервер указал 8BITMIME в ответе EHLO этой сессии.
  • Принятие создавало обязанность сохранить все биты; перед неспособным следующим узлом ретранслятор должен был без потерь создать корректный семибитный MIME или оформить постоянную ошибку.

Описание груза не расширяло дорогу

MIME дал письму способы назвать тип данных, набор символов и транспортное кодирование. Это решило вопрос интерпретации, но не изменило SMTP автоматически. RFC 2045 различает 7bit, 8bit и binary: правильно описанное тело могло содержать октеты, сохранность старшего бита которых следующий сервер не обещал.

Историческая задача состояла в назначении ответственности. Какая работающая реализация приняла это представление, в каком соединении и где заканчивалось её обязательство?

Три RFC сохранили одно узкое обещание

RFC 1426 опубликовал первое расширение в феврале 1993 года. RFC 1652 заменил его в июле 1994-го, а RFC 6152 заменил RFC 1652 в марте 2011-го. Эта цепочка доказывает историю нормы, но не современную долю внедрения.

Сервер помещает 8BITMIME в успешный ответ EHLO. Реестр расширений SMTP IANA хранит ключевое слово без параметра EHLO и ссылается на RFC 6152. Новый глагол SMTP не вводился.

Клиент может добавить к MAIL FROM параметр BODY=7BIT или BODY=8BITMIME. BODY описывает диапазон октетов будущего содержимого DATA, а не язык, charset или тип данных. Разрешение транспорта и смысл содержимого остаются разными фактами.

Разрешение относилось к текущему соединению

До отправки восьмибитного тела клиент обязан получить успешный EHLO с объявленной возможностью. Если её нет, передавать октеты вне US-ASCII нельзя. Способность TCP нести любые байты и вчерашняя терпимость того же продукта не заменяют свидетельство этой сессии.

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

Принять означало хранить каждый бит

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

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

Восемь бит не означали произвольный binary

DATA сохраняет строки и прозрачность точки. Строка с одной точкой по-прежнему завершает передачу, а начальные точки удваиваются. Ограничение длины тоже остаётся: RFC 6152 допускает сервер, гарантирующий лишь 1 000 октетов вместе с CRLF на строку.

Поэтому 8BITMIME поддерживает MIME 8bit, но не binary. Он расширяет допустимые значения внутри строки, не отменяя саму строку. CHUNKING и BINARYMIME решают другую задачу границ.

Следующий переход снова требовал решения

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

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

Объявление упорядочило доказательства

BODY=8BITMIME — заявление клиента, а не автоматическая истина. Эксплуатация должна отдельно сохранять возможность, объявленную пиром, BODY клиента, фактически наблюдаемый диапазон и действие на следующем переходе. Тогда искажённый символ можно отнести к отправителю, преобразованию, внутренней потере или отображению.

Долговечное достижение состояло в ограничении полномочий. MIME описывал груз; SMTP-соединение сообщало, способен ли этот хранитель его принять; следующее соединение задавало вопрос заново.

Источники и границы

Нормативную линию образуют RFC 1426, RFC 1652 и RFC 6152. RFC 2045 определяет области MIME, реестр IANA — текущую запись. Они не измеряют внедрение, объём или частоту преобразований сегодня.