Новая папка (2) / Ленция_7_ОС / SMTP_1
.htmSMTP SMTP Основные расширения:
{{{Основные расширения}}}
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.
// Обзор протокола SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.
Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов для определения сервера, обслуживающего почту в домене адресата, также могут задействовать 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:HELOS:250 domain name should be qualifiedC:MAIL FROM: <someusername@somecompany.ru>S:250 someusername@somecompany.ru sender acceptedC:RCPT TO:<user1@company.tld>S:250 user1@company.tld okC:RCPT TO: <user2@company.tld >S:550 user2@company.tld unknown user accountC:DATAS:354 Enter mail, end with "." on a line by itselfC:Hi!C:.S:250 769947 message accepted for deliveryC:QUITS:221 mail.company.tld CommuniGate Pro SMTP closing connectionS: (закрывает соединение) В результате такой сессии письмо будет доставлено адресату user1@company.tld, но не будет доставлено адресату user2@company.tld, потому что такого адреса не существует.
Команды SMTP HELO <SP> <string><CRLF> — Идентифицирует SMTP-сервер отправителя, открывает сеанс
Пример
HELO user.example.net250 server.example.com Hello user.example.net [192.168.1.1] pleased to meet you QUIT<CRLF> — Завершает SMTP-сеанс.
Пример
QUIT221 2.0.0 server.example.com closing connection MAIL <SP> FROM:<reverse-path> <CRLF> — Задает адрес отправителя. Адрес следует указывать в угловых скобках. Некоторые серверы могут проигнорировать то, что им передают адрес без угловых скобок, но те серверы, что неукоснительно следуют описанию RFC, отклонят такой адрес.
Пример
MAIL FROM: <USER@EXAMPLE.NET>250 2.1.0 USER@EXAMPLE.NET... Sender ok RCPT <SP> TO:<forward-path> <CRLF> — Задает адрес получателя. Адрес следует указывать в угловых скобках. Некоторые серверы могут проигнорировать то, что им передают адрес без угловых скобок, но те серверы, что неукоснительно следуют описанию RFC, отклонят такой адрес.
Пример
RCPT TO: <USER2@EXAMPLE.COM>250 2.1.5 USER2@EXAMPLE.COM... Recipient ok DATA <CRLF> — Указывает на начало сообщения. Для окончания сообщения указывается <CRLF>.<CRLF>.
Пример:
DATA354 Enter mail, end with "." on a line by itselfthis is a test message..250 2.0.0 l3PDY91f000484 Message accepted for delivery VRFY <SP> <string><CRLF> — проверяет существование получателя.
Пример (пояснение чуть ниже):
VRFY252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger) EXPN <SP> <string><CRLF> — показывает список адресов для списка рассылки.
Пример (пояснения чуть ниже):
EXPN502 5.7.0 Sorry, we do not allow this operation NOOP<CRLF> — пустая операция
Пример:
NOOP250 2.0.0 OK TURN<CRLF> — сервер и клиент меняются ролями после ответа сервера 200 OK
Пример: (команда не реализована)
TURN502 5.5.1 Command not implemented: "TURN" RSET<CRLF> — сброс сессии в исходное состояние
Пример:
RSET250 2.0.0 Reset state HELP<CRLF> — информация о поддерживаемых командах. Некоторые сервера поддерживают справку по отдельным командам, например, HELP MAIL (sendmail), некоторые выводят по этой команде лишь список доступных команд без пояснения (Microsoft Exchange Server).
Пример:
HELP214-2.0.0 This is sendmail version 8.12.9214-2.0.0 Topics:214-2.0.0 HELO EHLO MAIL RCPT DATA214-2.0.0 RSET NOOP QUIT HELP VRFY214-2.0.0 EXPN VERB ETRN DSN AUTH214-2.0.0 STARTTLS214-2.0.0 For more info use "HELP <topic>".214-2.0.0 To report bugs in the implementation send email to214-2.0.0 sendmail-bugs@sendmail.org.214-2.0.0 For local information send email to Postmaster at your site.214 2.0.0 End of HELP infoHELP MAIL214-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.tld250-mail.company2.tld is pleased to meet you250-DSN250-SIZE250-STARTTLS250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM250-ETRN250-TURN250-ATRN250-NO-SOLICITING250-HELP250-PIPELINING250 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)