4. The Enhanced-Status-Codes service extension
Servers supporting the Enhanced-Status-Codes extension must preface
the text part of almost all response lines with a status code. As in
RFC 1893, the syntax of these status codes is given by the ABNF:
status-code ::= class "." subject "." detail
class ::= "2" / "4" / "5"
subject ::= 1*3digit
detail ::= 1*3digit
These codes must appear in all 2xx, 4xx, and 5xx response lines other
than initial greeting and any response to HELO or EHLO. Note that 3xx
responses are NOT included in this list.
221 2.0.0 Goodbye
4.1.1.9. NOOP (NOOP)
This command does not affect any parameters or previously entered
commands. It specifies no action other than that the receiver send a
"250 OK" reply.
4.1.1.10. QUIT (QUIT)
This command specifies that the receiver MUST send a "221 OK" reply,
and then close the transmission channel.
Я использую SMTP-сервер, поддерживающий RFC 2034, но кажется RFC 2034 и RFC 5321 конфликт, и я не знаю, что мне делать с моим сервером.
RFC 5321 говорит сервер MUST ответить "250 OK" для QUIT команда, но за RFC 2034, это также must preface the text part of almost all response lines with a status code. Следует ли отдавать приоритет расширению («250 2.0.0 OK»)? Разве это не нарушит RFC 5321?
Прежде всего: сервер не должен отвечать 250 OK но с 221 OK к QUIT команда.
Но я думаю, вы неправильно поняли, что OK здесь, стандарт SMTP (без расширений) не заботится о том, что идет после кода состояния, это был глупый стандарт, и во время его реализации каждый почтовый сервер был открытым ретранслятором. Вы можете ответить 221 Have a nice day и он по-прежнему соответствует RFC 5321. Кроме того, RFC 5321 действительно заменяет и включает в себя множество старых вещей (см. описания).
Важная часть для вас заключается в следующем:
Этот документ представляет собой спецификацию основного протокола для передачи электронной почты в Интернете. Он объединяет, обновляет и уточняет несколько предыдущих документов, в результате чего большинство из них полностью или частично устарели. Он охватывает механизмы расширения SMTP и передовой опыт для современного Интернета. но не дает подробностей о конкретные расширения.
В вашем примере, что касается RFC 5321, 221 это код состояния, а все остальное - просто текст. Я думаю, это станет более понятным, если вы прочитаете раздел о прекращении работы в RFC5321: https://tools.ietf.org/html/rfc5321#section-3.8
Итак, TL; DR: 221 2.0.0 Goodbye идеально подходит для RFC 5321.
Имейте в виду, что «расширения» называются неслучайно, они построены на основе базового стандарта. Вместо того, чтобы заменять, они дополняют его.
Но не переживайте, SMTP (и электронная почта в целом) - это чудовище Франкенштейна, единственная причина, по которой он не был полностью заменен, - это широкое использование. Обеспечение такой обратной совместимости для стандарта, которому по сути более 30 лет, просто смешно в 21 веке.
И чтобы дать вам еще больше спокойствия:
2.2.3. Особые проблемы с расширениями
Разрешены расширения, которые изменяют основные свойства работы SMTP. В этом контексте следует понимать текст в других разделах этого документа. В частности, расширения могут изменять минимальные пределы, указанные в разделе 4.5.3, могут изменять требования к набору символов ASCII, как упомянуто выше, или могут вводить некоторые дополнительные режимы обработки сообщений.
В частности, если расширение подразумевает, что путь доставки обычно поддерживает специальные функции этого расширения, а промежуточная система SMTP находит следующий переход, который не поддерживает требуемое расширение, она МОЖЕТ выбрать, в зависимости от конкретного расширения и обстоятельств, для повторной постановки в очередь. сообщение и попробуйте позже и / или попробуйте другой хост MX. Если используется эта стратегия, таймаут для возврата к нерасширенному формату (если он доступен) ДОЛЖЕН быть меньше обычного тайм-аута для возврата как недоставленного (например, если нормальный тайм-аут составляет три дня, таймаут повторной очереди перед попыткой передачи почта без расширения может быть один день).