SMTP

Simple Mail Transfer Protocol SMTP Протокол

Уровень:

Прикладной

Семейство:

TCP/IP

Порт:

25 (TCP)

Назначение:

Отправка электронной почты

Реализация:

Клиенты:

MUA (MS Outlook, MS Outlook Express, Mozilla Thunderbird)

Серверы:

sendmail, postfix, exim, courier, CommunigatePro

Расширяемость:

Доп. команды (RFC 2449)

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают SMTP и его расширения.

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

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP. Данные передаются при помощи TCP, при этом обычно используется порт 25 или 587. При передаче сообщений между серверами обычно используется порт 25. Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать 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> — Задает адрес отправителя.

Пример MAIL FROM: [email protected] 250 2.1.0 [email protected]... Sender ok

• RCPT <SP> TO:<forward-path> <CRLF> — Задает адрес получателя.

Пример 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)

См. также

• Почтовый сервер
• POP3
• IMAP
• TCP
• Sender Policy Framework
• Sender ID
• X.400