Протокол SMTP

 

Перший стандарт - RFC0788 (Simple Mail Transfer Protocol J. Postel Nov-01- 1981).

Остання версія - RFC2821 (Simple Mail Transfer Protocol J. Klensin, Ed. April 2001).

Simple Mail Transfer Protocol - протокол високого рівня, використовується для відправки пошти, як клієнтом на сервер, так і сервером на інший сервер.

Порт за умовчанням - 25.

Основний недолік протоколу, це відсутність аутентифікації і "докачки" (як в FTP, HTTP) повідомлень, тобто якщо ви посилаєте великий лист (10Мбайт), то у разі розриву з'єднання ваше повідомлення доведеться передавати наново, і можливо так до безконечності. Тому великі листи необхідно різати на частини.

SMTP використовується для відправки пошти від користувачів до серверів і між серверами для подальшої пересилки до одержувача. Для прийому пошти поштовий клієнт повинен використовувати протоколи POP3 або IMAP.

Щоб доставити повідомлення до адресата, необхідно переслати його поштовому серверу домена, в якому знаходиться адресат. Для цього зазвичай використовується запис типу MX (англ. Mail exchange - обмін поштою) системи DNS. Якщо MX запис відсутній, то для тих же цілей може бути використана запис типу A. Деякі сучасні реалізації SMTP-серверів (наприклад, Exim) для визначення сервера, обслуговуючого пошту до імені адресата, також можуть додавати SRV-запис (RFC 2782).

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

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

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

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

 

1 Модель протоколу

 

Події роботи SMTP протоколу:

• Клієнт ініціює з'єднання з сервером

• Клієнт посилає запити на обслуговування

• Сервер відповідає на ці запити

 

Рис. 1. Модель протоколу SMTP

 

2 Послідовність команд SMTP

 

Протокол SMTP обумовлює послідовність SMTP-команд

Розглянемо приклад:

Якийсь Vasy абонент сервера kstu.ru, посилає листи трьом абонентам сервера kazan.ru (Pety, Koly, Dima) один лист.

Розглянемо лістинг передачі сервера kstu.ru серверу kazan.ru:

R - сервер (receive)

S - клієнт (send)

 

R 220 lviv.ua Simple Mail Transfer Service Ready // код відповіді 220 (з’єднання встановлено), сервер kstu.ru, протокол SMTP

S HELO kstu.ru // Зєднання встановлено, "Я kstu.ru", ідентифікація здійснюється по kstu.ru

R 250 lviv.ua // команда прийнята й оброблнна, ідентифікація пройшла

S MAIL FROM: <Vasy@kstu.ru> // Початок поштової транзакції, обратный адрес

Vasy@kstu.ru.

R 250 OK // Сервер згідний прийняти листа від Vasy@kstu.ru

S RCPT TO:<Petro@lviv.ua > // Кому відправити листа, Petro@lviv.ua

R 250 OK // Сервер згідний прийняти лист для Petro@lviv.ua

S RCPT TO:<Koly@kazan.ru> // Ще кому відіслати лист, Koly@kazan.ru

R 550 No such user here // Сервер видає помилку 550, повідомляє, що такого користувача немає

S DATA // Запит на передачу даних

R 354 Start mail input; end with <CRLF>.<CRLF> // Дозволяє передачу даних, останній рядок повинен містити "крапку"

S From: <vasy@list.ru> //Текст повідомлення (включаючи заголовок)...

S To: <pety@kfti.knc.ru>

S Subject: С новим роком!

S Mime-Version: 1.0

S X-Mailer: mPOP Web-Mail 2.19

S Date: Fri, 19 Sep 2003 08:37:43 +0400

S Reply-To: <vasy@list.ru>

S Content-Type: text/plain; charset=koi8-r

S Content-Transfer-Encoding: 8bit

S Message-Id: <E1A0D1b-000AnC-00.vasy-list-ru@f15.mail.ru> S

S С новым роком Петя!

S . // Кінець повідомлення, клієнт відправив крапку

R 250 OK // Сервер отримав дані

S QUIT // Клієнт посилає запит на завершення з’єднання

R 221 kazan.ru Service closing transmission channel // Сервер завершує з’єднання

 

Лістинг 6. Передача сервера kstu.ru серверу kazan.ru

 

3 Деякі команди SMTP

 

Обов'язкові команди (команди які повинні бути присутніми завжди)

HELO - Відкриття сеансу зв'язку (hello).

MAIL - Починає поштову транзакцію, яка завершується передачею даних в один або декілька поштових скриньок (mail).

RCPT - Ідентифікує одержувача поштового повідомлення (recipient).

Необов’язкові команди

DATA - Рядки, наступні за цією командою, розглядаються одержувачем як дані поштового повідомлення. У разі SMTP, поштове повідомлення закінчується комбінацією символів: CRLF-крапка-CRLF.

RSET - Перериває поточну поштову транзакцію (reset).

NOOP - Вимагає від одержувача не робити ніяких дій, а тільки видати відповідь ОК. Використовується головним чином для тестування.(No operation).

QUIT - Закриття сеансу зв'язку.

VRFY - Вимагає від приймача підтвердити, що її аргумент є дійсним ім'ям користувача.

SEND - Починає поштову транзакцію, що доставляє дані на один або декілька терміналів (не в поштову скриньку).

SOML - Починає транзакцію MAIL або SEND, що доставляє дані на один або декілька терміналів або в поштові скриньки.

SAML - Починає транзакцію MAIL і SEND, що доставляють дані на один або декілька терміналів і в поштові скриньки.

EXPN - Команда SMTP-серверу підтвердити, чи дійсно аргумент є адресою поштової розсилки і якщо так, повернути адресу одержувача повідомлення (expand).

HELP - Команда SMTP-серверу повернути повідомлення-довідку про його команди.

TURN - Команда SMTP-серверу або сказати ОК і помінятися ролями, тобто стати STMP- передавачем, або послати повідомлення-відмову і залишитися в ролі SMTP-сервера.

 

4 Синтаксис деяких команд SMTP

 

Команди, MAIL, SEND, SOML і SAML, мають однаковий синтаксис: MAIL <пропуск> FROM:<reverse-path> <carriage-return line-feed>

де:

<reverse path> (зворотна адреса) вказує серверу, кому у разі помилки відіслати повідомлення.

<carriage-return line-feed> (CRLF) повернення каретки.

Примітка: Команди SEND, SOML і SAML додаткові і використовуються досить рідко.

 

Синтаксис RCPT схожий на синтаксис команди MAIL: RCPT <пропуск> TO:<forward-path> <CRLF>

Проте, на відміну від MAIL, аргумент RCPT починається із слова <ТЕ:>.

 

5 Деякі коди відповідей SMTP

Сервер SMTP - це кінцевий автомат з внутрішнім станом. Клієнт передає на сервер рядок команда<пробіл>параметри<перехід рядка>. Сервер відповідає на кожну команду рядком, що містить код відповіді і текстове повідомлення, відокремлене пропуском. Кожна цифра в коді відповіді має певний сенс. Код відповіді - число від 100 до 999, представлене у вигляді рядка, що трактується таким чином:

? 2хх - команда успішно виконана

? 3xx - очікуються додаткові дані від клієнта

? 4хх - тимчасова помилка, клієнт повинен провести наступну спробу через деякий час

? 5хх - неусувна помилка

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

Як вказано в додатку Е документу RFC 821, простий SMTP-клієнт може аналізувати тільки першу цифру у відповіді сервера, і на підставі її продовжувати свої дії. Друга і третя цифри коду відповіді роз'яснюють значення першої. Якщо ви розробляєте SMTP-додаток, слід обов'язково вивчити конструкцію всіх кодів SMTP- відповіді.

211 Відповідь про стан системи або допомога

214 Повідомлення-підказка (допомога)

220 <ім’я_домена> служба готова до роботи

221 <ім’я_домена> служба закриває канал зв'язку

250 Оголошена дія поштової транзакції успішно завершилася

251 Даний адресат не є місцевим; повідомлення буде передано по маршруту <forward- path>

354 Починай передачу повідомлення. Повідомлення закінчується комбінацією CRLF-крапка-CRLF

421 <ім’я_домена> служба недоступна; з'єднання закривається

450 Оголошена команда поштової транзакції не виконана, оскільки поштова скринька недоступна

451 Оголошену команду не виконано; відбулася локальна помилка при обробці повідомлення

452 Оголошена команда не виконана; системі не вистачило ресурсів

500 Синтаксична помилка в тексті команди; команда не розпізнана

501 Синтаксична помилка в аргументах або параметрах команди

502 Дана команда не реалізована

503 Невірна послідовність команд

504 У даної команди не може бути аргументів

550 Оголошена команда не виконана, оскільки поштова скринька недоступна

551 Даний адресат не є місцевим; спробуйте передати повідомлення по маршруту <forward-path>

552 Оголошена команда поштової транзакції перервана; дисковий простір, доступний системі, переповнився

553 Оголошена команда не виконана; вказано неприпустиме ім'я поштової скриньки

554 Транзакція не виконана

 

6 Ретрансляція повідомлень

Можна використовувати проміжні сервера для доставки пошти одержувачу.

Приклад: передамо повідомлення від Vasyl@knu.ua через хости @knu.ua, @mail.ua одержувачеві Mykola@lviv.ua

Механізм ретрансляції:

 

• повідомлення передається хосту @knu.ua

S MAIL FROM:<Vasyl@knu.ua>

S RCPT TO:<@knu.ua, @mail.ua, Mykola@lviv.ua>

• повідомлення передається хосту @mail.ua

S MAIL FROM:<@knu.ua>

S RCPT TO:<@mail.ua, Mykola@lviv.ua>

• повідомлення передається хосту lviv.ua

S MAIL FROM:<@mail.ua>

S RCPT TO:<Mykola@lviv.ua>

При цьому параметри To, From і Cc залишаються без змін.

 

7 Резервні поштові сервери (relay)

 

У випадку якщо основний сервер не доступний, пошта може бути відправлена на резервний, який задається в записах MX (DNS). Резервний сервер зберігає пошту (клієнт її отримати не може) до тих пір, поки не запрацює основний сервер, як тільки основною запрацює, резервний передає всю ту, що накопичилась. Резервних серверів може бути досить багато. Як правило декілька різних серверів є резервними по відношенню до один одного.

 

Рис. 2. Схема роботи резервних поштових серверів

 

Коли основний сервер не доступний, пошта передається на резервний, коли основний сервер стає доступний, резервний передає пошту основному.