Кратко

  • Положительный ответ SMTP после данных принимает транзакцию целиком и возлагает на сервер полную ответственность за последующую доставку.
  • RFC 2033 предписал LMTP отвечать по порядку за каждый успешный RCPT: менеджер очереди оставляет только неразрешённых адресатов, однако потеря ответа после фактической доставки всё ещё допускает дубликат.

Одно сообщение закончилось разными результатами

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

Обычный SMTP не может завершить DATA одновременно кодами 250 и 452. В RFC 5321 финал данных не допускает частичного исхода: сервер либо принимает сообщение для доставки, либо нет. Положительный ответ передаёт ему ответственность за всё сообщение. Поздний сбой отдельного адресата становится задачей его очереди или последующего уведомления.

Для store-and-forward между хостами это полезно: принимающий SMTP-сервер уже располагает устойчивой очередью. Но между существующим менеджером очереди и локальным агентом почтовых ящиков то же правило вынуждало бы создать вторую очередь лишь для хранения разных результатов.

LMTP был предназначен именно для этого узкого стыка.

Число ответов перенесло границу ответственности

RFC 2033, опубликованный в 1996 году как Informational, требует после финальной точки DATA по одному ответу на каждый ранее успешный RCPT в исходном порядке.

Финальный 250 для A позволяет upstream-очереди закрыть A. Код 452 для B оставляет только B для повтора. Локальный агент сообщает ближайший к ящику факт, но не становится вторым владельцем отложенной работы.

Соответствие позиционное. Отвергнутый до DATA адресат не входит в финальный ряд. Два успешных RCPT с одинаковым forward-path всё равно занимают две позиции. Многострочный ответ остаётся одним ответом. Поэтому последующая группировка по строке адреса не сохраняет контракт.

Начальный успех RCPT также не обещает доставку. Ответ после тела окончательно передаёт ответственность за соответствующую позицию.

LHLO обозначил другую грамматику

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

Поэтому LHLO заменил HELO и EHLO. LMTP-сервер не должен положительно принимать приветствия SMTP, а LMTP не должен использовать сервисный порт SMTP 25. Несовпадение становится заметным до передачи содержания.

RFC 2033 требует также PIPELINING и расширенные коды состояния. RFC 2920 сохраняет порядок ответов при опережающей отправке команд. RFC 2034 и RFC 3463 уточняют причину результата. Но даже точный код не указывает позицию RCPT без упорядоченного списка.

При CHUNKING команда BDAT LAST получает тот же набор результатов по адресатам; промежуточный BDAT имеет один ответ. Множественность относится к завершению сообщения, а не к каждой порции байтов.

Полученная работа и полученный ответ не стали одной операцией

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

LMTP уменьшил неопределённость до отдельного адресата, но не создал атомарную транзакцию между записью ящика и сетью. Если ответ A получен и устойчиво обработан, A закрыт. Если B записан, а его ответ потерян, клиент не имеет передаваемого доказательства. RFC 2033 велит обработать пришедший префикс и считать остальные позиции временными отказами.

Серверу следует быстро отправлять каждый результат и сбрасывать буфер; клиенту — обрабатывать ответы по мере поступления. Это сокращает неопределённый хвост при обрыве, но не отменяет уже выполненную запись.

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

Финальный LMTP-ответ не был DSN

DSN позднее сообщает о событии после принятия ответственности. LMTP-ответ участвует в самой передаче: временный результат оставляет обязанность текущей очереди, положительный передаёт её локальному агенту.

Он не доказывает чтение человеком, показ в интерфейсе или личность адресата. Протокол учитывает транспортную ответственность, а не внимание.

Источники и ограничения

Закрытый набор включает RFC 1047, RFC 2033, RFC 2034, RFC 2920, RFC 3463 и RFC 5321. Они устанавливают грамматику и ответственность, а не текущую долю внедрения, настройки продуктов или универсальный сокет. RFC 2033 имеет статус Informational и не является общим предписанием внедрять LMTP.