RFC: 5321
Оригинал: Simple Mail Transfer Protocol
Предыдущие версии: RFC 772, RFC 780, RFC 788, RFC 821, RFC 974, RFC 1425, RFC 1651, RFC 1869, RFC 2821
Категория: Проект стандарта
Дата публикации:
Автор:
Перевод: Николай Малых
4.5.4.2. Стратегия приема

Серверу SMTP следует пытаться сохранить постоянное прослушивание порта SMTP (в соответствии с реестром IANAIANAIANA порт 25). Это требуется для поддержки множества входящих TCP-соединений для SMTP. Некоторые ограничения возможны, но серверы, неспособные одновременно обслуживать множество транзакций SMTP, являются нарушением данной спецификации.

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

4.5.5. Сообщения с пустым полем обратного пути

Некоторые типы уведомлений, требуемые существующими или предложенными стандартами, передаются с пустым полем обратного пути. К числу таких сообщений относятся уведомления об ошибках при доставке (см. параграф 3.7), другие типы сообщений DSN (Delivery Status Notifications — уведомления о состоянии доставки RFC 3461 [32]) и сообщения MDN (Message Disposition Notifications — уведомления о диспозиции сообщений RFC 3798 [37]). Все типы указанных сообщений являются уведомлениями о предыдущем сообщении и посылаются по обратному пути из заголовка письма, с которым связано данное уведомление. Невозможность доставки зачастую связана с проблемами в почтовой системе на хосте адресата, поэтому некоторые АДП настраиваются на пересылку таких уведомлений кому-нибудь, кто будет способен исправить проблему с почтой (например, с использованием псевдонима postmaster).

Все остальные типы сообщений (т. е., любые сообщения, для которых проекты стандартов RFC не требуют использовать пустой путь возврата) следует посылать с корректным, непустым полем обратного пути.

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.