Кратко

  • RFC 772 и RFC 780 определяли R — адресаты сначала — и T — текст сначала. Отправитель предлагал, получатель контролировал допустимый режим.
  • MRSQ обнаруживал функцию, выбирал и сбрасывал состояние. MRCP называл адресата, но в R подтверждал место в таблице, а в T — применение уже сохранённого текста.
  • RFC 788 и RFC 821 перешли к MAIL, одному или нескольким RCPT, затем DATA. Экономия общей копии осталась, переговоры о внешнем порядке исчезли.

Вопрос одновременно стирал ответственный контекст

В RFC 780 MRSQ ? просит предпочтение R или T. MRSQ без аргумента проверяет наличие механизма и возвращает состояние без схемы. Конкретный запрос может быть отвергнут, если получатель не способен его выполнить.

Любое MRSQ сбрасывает режим. Это не наблюдение без последствий: сохранённый текст или таблица адресатов могут исчезнуть. Диагност, вставивший вопрос в середину, изменит расследуемую транзакцию.

Выбор принадлежит получателю, потому что он знает свой mailer, объём таблицы, цену буфера и способ локальной доставки. Отправитель должен быть готов к доступному пути.

R сначала строил таблицу адресатов

В recipients-first команды MRCP TO:<path> оцениваются отдельно. Принятые пути сохраняются; один отказ не отменяет остальные.

Затем MAIL без TO переносит одно тело для всей таблицы. Финальный успех относится ко всем запомненным, финальная неудача считается неудачей группы. После обработки таблица очищается.

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

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

T сначала строил хранилище текста

В text-first MAIL без адресата сохраняет тело. Последующие MRCP применяют эту копию по одному адресу и дают индивидуальный результат без повторной передачи текста.

Тело живёт до следующего MAIL или MRSQ. T экономит тот же трафик, но буферизует другой объект.

Это удобно для постепенной доставки: квота и конфликт доступа проявляются в ответе конкретного ящика. Однако тело принято до гарантии хотя бы одного допустимого адреса.

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

Один код подтверждал разные вещи

В R успешный MRCP в основном фиксирует имя для будущего общего шага. В T текст уже существует, и ответ относится к его обработке для данного адресата. Без режима 2xx недостаточен.

MRSQ и обычный MAIL могут стирать состояние. Потерянная строка журнала связывает поздний MRCP с уже уничтоженным телом или списком.

Две последовательности означают два объекта хранения, разные моменты доказательства и несколько границ очистки. Локальная оптимизация расширяет состояние, общее для всех участников.

Получатель знал внутреннюю цену

RFC 780 связывает R с передачей полного набора центральному mailer, а T — с поэтапной доставкой и переменными результатами отдельных ящиков.

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

Для одной связи это разумно. Во всём Интернете каждый клиент, relay и анализатор должен поддерживать оба пути. Локальное различие становится внешней обязанностью.

SMTP закрепил единый внешний порядок

RFC 788 задаёт MAIL FROM, повторяемые RCPT TO и DATA. Диалог намеренно lock-step, команды применяются в этом порядке.

MRSQ и почтового MRCP нет. Получатель не может потребовать тело раньше адресов. Отказ RCPT затрагивает этот адрес, не обязательно всю транзакцию.

RFC 821 сохраняет структуру. Она не предписывает одинаковые очереди внутри серверов, но даёт всем парам одну наблюдаемую причинность.

Сервер может менять внутренний mailer без новой грамматики для клиентов. Уходит право выбирать порядок на проводе, а не инженерная свобода.

Одна копия для многих сохранилась

R и T устраняли повтор содержания. SMTP оставил цель: один MAIL, несколько RCPT, один DATA.

RFC 788 и RFC 821 поощряют единственную копию данных для нескольких адресатов одного назначения. RFC 1123 настоятельно требует RCPT, RCPT, ... RCPT, DATA вместо повторов RCPT, DATA.

Конвергенция не заменила эффективность расточительством. Она убрала text-first и сделала общую копию частью фиксированного recipients-first.

PIPELINING не возвращает T

Lock-step создаёт ожидание ответов. PIPELINING позволяет отправлять допустимые команды раньше, но не ставит DATA перед RCPT.

MRSQ T менял первый существующий объект состояния. PIPELINING меняет время передачи уже упорядоченных команд. Меньше задержки не означает новую причинность.

Так предмет отделяется от истории PIPELINING, а плотный сетевой захват не принимается за перестановку.

Современная граница стабильна

RFC 5321 оставляет MAIL, один или несколько RCPT, DATA. Расширения не восстанавливают R/T.

Внутри серверы могут проверять и ставить в очередь по-разному. Общая поверхность удерживает эти различия от превращения в обязанность отправителя.

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

Другой MRCP не связан с почтой

Здесь MRCP означает Mail Recipient в MTP. Поздний Media Resource Control Protocol для речевых ресурсов не имеет технического родства.

Поиск должен соединять MRCP с MRSQ, mail или RFC 772/780. Совпадение букв не является доказательством.

Источники и пределы

Использованы RFC 772, 780, 788, 821, 1123 и 5321. Они подтверждают режимы, сбросы, полномочие, лимиты, порядок SMTP и сохранённую экономию.

Они не дают статистику внедрения, одну дату удаления или общий выигрыш. RFC 788 просто перестаёт определять MRSQ/MRCP и задаёт другую последовательность.

R не гарантирует атомарность, T не повторяет тело для каждого адреса. Разница — в месте состояния и моменте доказательства.