1.2. Предыстория и контекст документа
Документ содержит спецификацию базового протокола передачи электронной почты в сети Internet. Документ консолидирует, обновляет и разъясняет перечисленные ниже спецификации, не изменяя их функциональности:
- исходная спецификация SMTP (Simple Mail Transfer Protocol) — RFC 821 [1];
- требования к системе доменных имен и ее использованию для передачи электронной почты — RFC 1035 [2] и RFC 974 [12];
- пояснения и вопросы применимости RFC 1123 [3];
- материалы из механизмов расширения SMTP Extension — RFC 1869 [13];
- редакторские правки и разъяснения к RFC 2821 [14] для повышения статуса до Draft Standard.
Данный документ отменяет действие RFC 821, RFC 974, RFC 1869, RFC 2821 и обновляет RFC 1123 (замена материалов по доставке электронной почты в RFC 1123). Однако в RFC 821 приведены спецификации некоторых свойств, которые не стали достаточно значимыми в среде Internet середины 1990-х, и (в приложениях) некоторые дополнительные транспортные модели. Эти разделы опущены здесь с целью снижения объема документа, интересующиеся читатели могут обратиться к RFC 821.
Документ также включает некоторые дополнительные материалы из RFC 1123, которые требовалось усилить. Такие материалы определены разными путями — прежде всего просмотром популярных списков рассылки и телеконференций, а также идентификацией проблем и разночтений, которые появлялись в разрабатываемых расширениях SMTP. В тех случаях, где настоящая спецификация выходит за пределы консолидации сведений из более ранних документов и реально отличается от них, приведенные здесь сведения имеют более высокий приоритет, как в техническом, так и в текстовом отношении.
Хотя SMTP разрабатывался как протокол транспортировки и доставки электронной почты, данная специффикация содержит также информацию, которая важна для использования протокола в качестве средства представления сообщений, как рекомендовано спецификациями протоколов POP (RFC 937 [15], RFC 1939 [16]) и IMAP (RFC 3501 [17]). В общем случае предпочтительно использовать для представления почтовых сообщений отдельный протокол, описанный в RFC 4409 [18]; далее в документе этот вопрос рассматривается более подробно.
В параграфе 2.3 приводятся определения специфических для данного документа терминов. За исключением тех случаев, когда исторически сложившаяся терминология нужна для понимания, в данном документе применяются современные трактовки терминов «клиент» и «сервер» для обозначения передающих и принимающих процессов SMTP, соответственно.
В дополнительном документе RFC 5322 [4] обсуждаются разделы заголовков и тел почтовых сообщений, а также их структура и форматы.
1.3. Соглашение о терминах
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [5]. Такие термины в документе используются очень аккуратно в целях повышения уровня интероперабельности систем электронной почты. Каждое использование таких терминов должно трактоваться как уровнеь требований в части соответствия данной спецификации.
Поскольку этот документ имеет длинную предысторию, во избежание возникновения ошибок и заблуждений у читателей, большая часть примеров и упомянутых в них доменных имен заимствована из RFC 2821. Читателям следует быть осторожными с приведенными примерами и не использовать их напрямую в программном коде или конфигурационных файлах.