SMTP

Материал из Provizorii
Перейти к: навигация, поиск
SMTP
Название: Simple Mail Transfer Protocol
Уровень (по модели OSI): Прикладной
Семейство: TCP/IP
Создан в: {{{Создан}}} г.
Порт/ID: 25/TCP
Назначение протокола: Отправка электронной почты
Спецификация: {{{Спецификация}}}
Основные реализации: {{{Реализации}}}
Основные реализации (клиенты): MUA (MS Outlook, MS Outlook Express, Mozilla Thunderbird)
Основные реализации (серверы): sendmail, postfix, exim, courier, CommunigatePro, Merak Mail Server
Расширяемость: Доп. команды (RFC 2449)
Основные расширения: {{{Основные расширения}}}

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.

Обзор протокола

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim<ref>Спецификация Exim MTA Описание dnslookup роутера(англ.)</ref>) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).

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

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

Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.

Сервер SMTP — это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:

  • 2ХХ — команда успешно выполнена
  • 3XX — ожидаются дополнительные данные от клиента
  • 4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время
  • 5ХХ — неустранимая ошибка

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

ESMTP — расширяемый протокол, в отличии от SMTP. При установлении соединения сервер объявляет о наборе поддерживаемых расширений (в качестве ответа на команду EHLO). Соответствующие расширения могут быть использованы клиентом при работе. Необходимо помнить, что если сессия начинается с команды HELO (используемой в «классическом» SMTP, RFC 821), то список расширений выводиться не будет.

Безопасность SMTP и спам

Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения — фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, Yahoo Domain Keys. Единой спецификации на настоящий момент не существует.

Пример простейшей SMTP-сессии

C: — клиент, S: — сервер

S: (ожидает соединения)
C: (Подключается к порту 25 сервера)
S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you!
C:HELO
S:250 domain name should be qualified
C:MAIL FROM: <[email protected]>
S:250 [email protected] sender accepted
C:RCPT TO:<[email protected]>
S:250 [email protected] ok
C:RCPT TO: <[email protected] >
S:550 [email protected]  unknown user account
C:DATA
S:354 Enter mail, end with "." on a line by itself
C:Hi!
C:.
S:250 769947 message accepted for delivery
C:QUIT
S:221 mail.company.tld CommuniGate Pro SMTP closing connection
S: (закрывает соединение)

В результате такой сессии письмо будет доставлено адресату [email protected], но не будет доставлено адресату [email protected], потому что такого адреса не существует.

Команды SMTP

  • HELO <SP> <string><CRLF> — Идентифицирует SMTP-сервер отправителя, открывает сеанс

Пример

HELO user.example.net
250 server.example.com Hello user.example.net [192.168.1.1] pleased to meet you
  • QUIT<CRLF> — Завершает SMTP-сеанс.

Пример

QUIT
221 2.0.0 server.example.com closing connection
  • MAIL <SP> FROM:<reverse-path> <CRLF> — Задает адрес отправителя. Адрес следует указывать в угловых скобках. Некоторые серверы могут проигнорировать то, что им передают адрес без угловых скобок, но те серверы, что неукоснительно следуют описанию RFC, отклонят такой адрес.

Пример

MAIL FROM: <[email protected]>
250 2.1.0 [email protected]... Sender ok
  • RCPT <SP> TO:<forward-path> <CRLF> — Задает адрес получателя. Адрес следует указывать в угловых скобках. Некоторые серверы могут проигнорировать то, что им передают адрес без угловых скобок, но те серверы, что неукоснительно следуют описанию RFC, отклонят такой адрес.

Пример

RCPT TO: <[email protected]>
250 2.1.5 [email protected]... Recipient ok
  • DATA <CRLF> — Указывает на начало сообщения. Для окончания сообщения указывается <CRLF>.<CRLF>.

Пример:

DATA
354 Enter mail, end with "." on a line by itself
this is a test message.
.
250 2.0.0 l3PDY91f000484 Message accepted for delivery
  • VRFY <SP> <string><CRLF> — проверяет существование получателя.

Пример (пояснение чуть ниже):

VRFY
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
  • EXPN <SP> <string><CRLF> — показывает список адресов для списка рассылки.

Пример (пояснения чуть ниже):

EXPN
502 5.7.0 Sorry, we do not allow this operation
  • NOOP<CRLF> — пустая операция

Пример:

NOOP
250 2.0.0 OK
  • TURN<CRLF> — сервер и клиент меняются ролями после ответа сервера 200 OK

Пример: (команда не реализована)

TURN
502 5.5.1 Command not implemented: "TURN"
  • RSET<CRLF> — сброс сессии в исходное состояние

Пример:

RSET
250 2.0.0 Reset state
  • HELP<CRLF> — информация о поддерживаемых командах. Некоторые сервера поддерживают справку по отдельным командам, например, HELP MAIL (sendmail), некоторые выводят по этой команде лишь список доступных команд без пояснения (Microsoft Exchange Server).

Пример:

HELP
214-2.0.0 This is sendmail version 8.12.9
214-2.0.0 Topics:
214-2.0.0       HELO    EHLO    MAIL    RCPT    DATA
214-2.0.0       RSET    NOOP    QUIT    HELP    VRFY
214-2.0.0       EXPN    VERB    ETRN    DSN     AUTH
214-2.0.0       STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0       [email protected].
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
HELP MAIL
214-2.0.0 MAIL FROM: <sender> [ <parameters> ]
214-2.0.0       Specifies the sender.  Parameters are ESMTP extensions.
214-2.0.0       See "HELP DSN" for details.
214 2.0.0 End of HELP info

Из-за проблем со спамом, почти все современные сервера игнорируют команды VRFY и EXPN, как раскрывающие информацию о пользователе.

Расширения ESMTP

RFC 1869 предписывает начинать сессию не командой HELO, а командой EHLO. В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.

Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:

ehlo office.company1.tld
250-mail.company2.tld is pleased to meet you
250-DSN
250-SIZE
250-STARTTLS
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM
250-ETRN
250-TURN
250-ATRN
250-NO-SOLICITING
250-HELP
250-PIPELINING
250 EHLO

Стандарты RFС

  • RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
  • RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
  • RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
  • RFC 2554 SMTP Service Extension for Authentication
  • RFC 2821 The Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974 и RFC 1869)
  • RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
  • RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
  • RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
  • RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
  • RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
  • RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
  • RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
  • RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
  • RFC 3552 Guidelines for Writing RFC Text on Security Considerations
  • RFC 3834 Recommendations for Automatic Responses to Electronic Mail
  • RFC 4409 Message Submission for Mail (заменяет RFC 2476)

Примечания

<references/>

См. также