SMTP

SMTP ( англ. Simple Mail Transfer Protocol - Простий протокол передачі пошти) - це широко використовуваний мережевий протокол, призначений для передачі електронної пошти в мережах TCP / IP.

SMTP вперше був описаний в RFC вісімсот двадцять-одна (1982 рік); останнє оновлення в RFC п'ять тисяч триста двадцять-один (2008) включає масштабоване розширення - ESMTP ( англ. Extended SMTP ). В даний час під "протоколом SMTP", як правило, мають на увазі і його розширення. Протокол SMTP призначений для передачі вихідної пошти з використанням порту TCP 25.

В той час, як електронні поштові сервери і інші агенти пересилання повідомлень використовують SMTP для відправки та отримання поштових повідомлень, що працюють на рівні користувача клієнтські поштові програми зазвичай використовують SMTP тільки для відправки повідомлень на поштовий сервер для ретрансляції. Для отримання повідомлень клієнтські додатки зазвичай використовують або POP ( англ. Post Office Protocol - Протокол поштового відділення), або IMAP ( англ. Internet Message Access Protocol ), Або патентовані системи (такі як Microsoft Exchange і Lotus Notes / Domino) для доступу до облікового запису своєї поштової скриньки на сервері.


1. Історія

У 1960-х роках використовувалися різні види електронного зв'язку. Люди зв'язувалися один з одним за допомогою систем, розроблених для певних мейнфреймів. Коли все більше комп'ютерів ставали пов'язаними, особливо в мережі Уряду США, ARPANET, були розроблені стандарти для того, щоб користувачі на різних системах могли писати електронні повідомлення один одному. Ці стандарти, розроблені в 1970-х роках, стали основою для SMTP.

Коріння SMTP можна простежити у двох описаних в 1971 р. реалізаціях - Mail Box Protocol і SNDMSG, який був "винайдений" Реєм Томлінсон з BBN Technologies для TOPS-20/TENEX-компьютеров, що посилають повідомлення по ARPANET (в той час до неї були приєднані менше 50 хостів).

Подальші реалізації включають в себе FTP Mail і Mail Protocol, розроблені в 1973 р. Розробка тривала протягом 1970-х, поки ARPANET не перетворене в сучасний Інтернет близько 1980 р. У тому ж році Джон Постел запропонував Mail Transport Protocol (протокол передачі пошти), завдяки якому FTP перестав бути основою для передачі пошти. SMTP опублікований в RFC 821 (також написаному Постелом) в серпні 1982 р.

Стандарт SMTP був розроблений приблизно в той же час, що і Usenet, мережа передачі даних, що має деякі подібності з SMTP. SMTP став широко використовуватися в ранні 1980-ті. У той час, він був доповненням для працюючої під Unix поштової програми Unix Copy Program (UUCP), яка більше підходила для обробки передачі електронних повідомлень між періодично пов'язаними пристроями. З іншого боку, SMTP прекрасно працює, коли як відправляє, так і приймає пристрої зв'язані в мережі постійно. Обидва пристрої використовують механізм збереження і пересилки і є прикладом push-технології (технології "проштовхування"). Хоча новинні групи Usenet усе ще поширюються між серверами за допомогою UUCP, пошта UUCP фактично зникла разом з маршрутом "bang path" (послідовність хост-машин в мережі, по якій повідомлення повинно дійти до адресата), які використовувалися як заголовки маршрутизації. У статті про перезапис відправника міститься технічна довідкова інформація про історії раннього SMTP і маршрутизації від джерела до RFC 1123.

Sendmail був одним з перших (якщо не першим) агентом пересилки повідомлень, в якому був реалізований SMTP. У число інших популярних серверних програм, що підтримують SMTP, входять Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, Sun Java System Messaging Server.

Надання повідомлень (RFC дві тисячі чотиреста сімдесят-шість) і SMTP-AUTH (RFC дві тисячі п'ятсот п'ятьдесят-чотири) були введені в 1998 і 1999 р.р. і описували нові тенденції в передачі електронних повідомлень. Спочатку, SMTP-сервера були зазвичай внутрішніми для організації, отримуючи повідомлення від організацій ззовні і ретранслюючи повідомлення організації в зовнішнє середовище. Але з плином часу, SMTP-сервера (агенти пересилання повідомлень), на ділі, розширювали свої функції і в кінці кінців стали агентами надання повідомлень для користувальницьких поштових додатків, деякі з яких тепер ретранслювали пошту ззовні організації (наприклад, керівник компанії, будучи в поїздці, хоче відправити електронне повідомлення за допомогою корпоративного SMTP-сервера).

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

Оскільки цей протокол спочатку був з текстовим ( ASCII) інтерфейсом, то він погано працював з бінарними файлами і символами багатьох неанглійських мов. Такі стандарти, як Multipurpose Internet Mail Extensions ( MIME), були розроблені для кодування двійкових файлів для передачі через SMTP. Розроблені після Sendmail агенти пересилання, як правило, також здійснювали опцію чистих 8 біт, так що альтернативна стратегія "просто посилай вісім" може бути використана для передачі довільних текстових даних (в будь восьмібітного ASCII-подібної кодуванні символів) через SMTP. Однак все ще залишалася проблема кракозябри, викликана різним відображенням наборів символів у виробників, хоча самі поштові адреси все ще дозволяли використовувати виключно ASCII. Сьогодні агенти пересилання, що працюють з чистими 8 бітами, як правило, підтримують розширення 8BITMIME, що дозволяє передавати бінарні файли майже так само легко, як звичайний текст. Нещодавно було створено розширення SMTPUTF8 для підтримки тексту в кодуванні UTF-8, завдяки чому стало можливим включати міжнародне вміст і адреси з використанням таких алфавітів, як кирилиця або китайський.

Багато видатних людей внесли свій внесок у специфікацію основного SMTP, серед них Джон Постел, Ерік Оллман, Дейв Крокер, Нед Фрід, Рендалл Джелленс, Джон Кленсін і Кейт Мур.


2. Модель обробки пошти

Сині стрілки можуть бути реалізовані з використанням різних версій SMTP.

Електронна пошта представлена ​​поштовим клієнтом (MUA, mail user agent - користувальницький поштовий агент) для поштового сервера (MSA, mail submission agent - агент передачі електронної пошти) за допомогою SMTP по TCP -порту 587. Звідти MSA доставляє пошту своїм агентам пересилання повідомлень (MTA, mail transfer agent). Часто ці два агента є просто різними зразками одного і того ж програмного забезпечення, запущеного з різними параметрами на одному пристрої. Локальна обробка може бути проведена як на окремій машині, так і розділена між різними пристроями; в першому випадку залучені процеси мають загальний доступ до файлів, у другому випадку SMTP використовується для пересилання повідомлення внутрішньо, причому кожен хост налаштований на використання наступного пристрою в якості проміжного хоста. Кожен процес - сам по собі MTA, тобто - SMTP-сервер.

Граничний MTA повинен знайти цільової хост. Він використовує систему доменних імен ( DNS) для пошуку записів поштового обмінника (mail exchanger - MX) домену одержувача (частина адреси, що знаходиться праворуч від символу @). Повертається запис поштового MX містить ім'я цільового хоста. Потім MTA підключається до сервера обміну в якості SMTP-клієнта.

Як тільки мета MX приймає вхідне повідомлення, вона передає його агенту доставки пошти (mail delivery agent - MDA) для локальної доставки повідомлення. MDA передбачає можливість зберігати повідомлення у відповідному форматі поштової скриньки. Прийом пошти, знову ж таки, може бути проведений як декількома, так і одним комп'ютером - зображення показує два найближчих ящика для кожного випадку. MDA може доставляти повідомлення прямо на зберігання або передавати їх по мережі за допомогою SMTP або будь-яких інших засобів, у тому числі протоколу локальної пересилання пошти (Local Mail Transfer Protocol - LMTP) - похідного від SMTP, призначеного для цієї мети.

Після доставки на локальний поштовий сервер повідомлення зберігається для пакетного пошуку по аутентіфіцированний поштовим клієнтам (MUA). Повідомлення витягується додатками кінцевого користувача (поштові клієнти) з використанням Internet Message Access Protocol (IMAP, який полегшує доступ до повідомлень і управляє зберігається поштою), або ж за допомогою Post Office Protocol (POP), який зазвичай використовує традиційний mbox-формат файлів, або фірмові системи на зразок Miscrosoft Exchange / Outlook або Lotus Notes / Domino. Клієнти мережевої пошти можуть використовувати будь-який метод, але протокол пошуку часто не відповідає офіційним стандартам.

SMTP визначає передачу повідомлення, а не його зміст. Таким чином, він задає оболонку повідомлення і її параметри (такі, як відправник оболонки), але не заголовок або тіло самого повідомлення. STD 10 і RFC 5321 визначають SMTP (оболонку), в той час як STD 11 і RFC 5322 - повідомлення (заголовок і тіло), офіційно званий форматом поштового повідомлення (Internet Message Format).


3. Огляд протоколу

SMTP - вимагає з'єднання текстовий протокол, по якому відправник повідомлення зв'язується з одержувачем за допомогою видачі командних рядків та отримання необхідних даних через надійний канал, в ролі якого зазвичай виступає TCP-з'єднання (Transmission Control Protocol - протокол керування передачею). SMTP-сесія складається з команд, що посилаються SMTP- клієнтом, і відповідних відповідей SMTP- сервера. Коли сесія відкрита, сервер і клієнт обмінюються її параметрами. Сесія може включати нуль і більш SMTP-операцій (транзакцій).

SMTP-операція складається з трьох послідовностей команда / відповідь (див. приклад нижче). Опис послідовностей:

  • MAIL FROM - встановлює зворотну адресу (тобто Return-Path, 53121.From, mfrom). Це адреса для повернутих листів.
  • RCPT TO - встановлює одержувача даного повідомлення. Ця команда може бути дана кілька разів, по одному на кожного одержувача. Ці адреси також є частиною оболонки.
  • DATA - для відправки тексту повідомлення. Це саме вміст листа, в протилежність його оболонці. Він складається із заголовка повідомлення і тіла повідомлення, розділених порожнім рядком. DATA, по суті, є групою команд, а сервер відповідає двічі: перший раз на саму команду DATA, для повідомлення про готовність прийняти текст; та вдруге після кінця послідовності даних, щоб прийняти або відхилити всі лист.

Крім проміжних відповідей для DATA-команди, кожна відповідь сервера може бути позитивним (код відповіді 2хх) або негативним. Останній, у свою чергу, може бути постійним (код 5хх) або тимчасовим (код 4хх). Відмова SMTP-сервера в передачі повідомлення - постійна помилка; в цьому випадку клієнт повинен відправити повернене лист. Після скидання - позитивної відповіді, повідомлення швидше за все буде відкинена. Також сервер може повідомити про те, що очікуються додаткові дані від клієнта (код 3xx).

Початкових хостом (SMTP-клієнтом) може бути як поштовий клієнт кінцевого користувача (функціонально визначається як поштовий агент - MUA), так і агент пересилки повідомлень (MTA) на сервері, тобто сервер діє як клієнт у відповідній сесії для ретрансляції повідомлення. Повністю функціональні сервера підтримують черги повідомлень для повторної передачі повідомлення в разі помилок.

MUA знає SMTP-сервер для вихідної пошти зі своїх налаштувань. SMTP-сервер, який діє як клієнт, тобто пересилає повідомлення, визначає, до якого сервера підключитися, переглядом ресурсу записів MX (Mail eXchange) DNS для домену кожного одержувача. У випадку, якщо запис MX не знайдена, сумісні MTA (не всі) повертаються до простої А-запису. Пересилають сервера також можуть бути налаштовані на використання Smart host.

SMTP-сервер, який діє як клієнт, встановлює TCP-з'єднання з сервером по розробленим для SMTP порту 25. MUA повинен використовувати порт 587 для підключення до агента надання повідомлень (MSA). Основна відмінність між MTA та MSA полягає в тому, що SMTP-аутентифікація обов'язково тільки для останнього.


3.1. SMTP і витяг повідомлень

SMTP - всього лише протокол доставки. Він не може на вимогу взяти повідомлення з віддаленого сервера. Для витягання пошти та управління поштовою скринькою розроблені інші протоколи, такі як POP і IMAP. Тим не менш, SMTP надає можливість почати на віддаленому сервері обробку черги повідомлень, при якій запитуюча система може отримувати всі спрямовані їй повідомлення (див. Remote Message Queue Starting нижче). POP і IMAP кращі, коли комп'ютер користувача включений не постійно, або ж тимчасово підключений до Інтернету.


3.2. Remote Message Queue Starting

Remote Message Queue Starting (запуск віддаленої черги повідомлень) - особливість SMTP, що дозволяє удаленнному хосту почати обробку черги повідомлень на сервері так, що він може отримувати призначені йому повідомлення за допомогою команди TURN. Однак ця особливість вважалася небезпечною і була розширена в RFC 1985 командою ETRN, яка працює надійніше завдяки заснованому на інформації DNS методу аутентифікації.

3.3. On-Demand Mail Relay

ODMR (On-Demand Mail Relay - ретрансляція пошти на вимогу) - стандартизоване в RFC 2645 SMTP-розширення, яке дозволяє проводити ретрансляцію повідомлення аутентифікованим користувачеві.

3.4. Інтернаціоналізація

Багато користувачів, чий набір символів відрізняється від латиниці, стикаються з вимогою адреси електронної пошти на латиниці. Для вирішення цієї проблеми був створений RFC 6531, що надає можливості для інтернаціоналізації для SMTP - розширення SMTPUTF8. RFC 6531 надає підтримку багатобайтові і не-ASCII символів у поштовій адресі, наприклад: δοκιμή@παράδειγμα.δοκιμή або测试@测试.测试. Поточна підтримка обмежена, але є великий інтерес в широкому поширенні RFC 6531 і пов'язаних з ним RFC в країнах з великою базою користувачів, для яких латиниця не є рідною алфавітом.


4. SMTP-сервер вихідної пошти

Поштовий клієнт повинен знати IP-адресу SMTP-сервера, який задається як частина конфігурації (звичайно у вигляді DNS-імені). Сервер буде доставляти вихідні повідомлення від імені користувача.

4.1. Обмеження доступу до сервера вихідної пошти

Адміністраторам сервера необхідно контролювати те, які клієнти можуть використовувати сервер. Це дозволяє їм боротися з такими зловживаннями, як спам. Зазвичай використовуються два рішення:

  • У минулому багато системи вводили обмеження по місцю розташування клієнта, допускаючи до використання лише тих, чий IP-адресу був серед підконтрольних адміністраторам.
  • Сучасні сервера зазвичай пропонують альтернативну систему, що вимагає аутентифікацію клієнтів для отримання доступу.

4.2. Обмеження доступу по местоположению

У цьому випадку SMTP-сервер інтернет-провайдера не дозволить допуск користувачам "за межами" мережі провайдера. Точніше, сервер може допустити лише тих користувачів, чий IP-адресу надано даними провайдером, що еквівалентно вимогу з'єднання з Інтернетом за допомогою цього провайдера. Мобільний користувач часто може виявитися в мережі, відмінної від мережі свого провайдера, і тому повідомлення не будуть відправлятися.

У даної системи є кілька різновидів. Наприклад, SMTP-сервер організації може надавати доступ тільки користувачам тій же мережі, блокуючи решти користувачів. Також сервер може проводити ряд перевірок клієнтського IP-адреси. Ці методи зазвичай використовувалися організаціями та установами, наприклад університетами, для внутрішнього користування сервером. Однак, більша їх частина тепер використовує описані нижче методи аутентифікації.

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


4.3. Аутентифікація клієнта

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

4.4. Відкритий релей

Сервер, доступний для широкої мережі і не надає ці види обмеження доступу, називають відкритим Релеєм. Зараз такі сервера вважаються поганим тоном.

4.5. Порти

Адміністратори сервера вибирають, який порт будуть використовувати клієнти для ретрансляції вихідної пошти - 25 або 587. Специфікації та багато сервера підтримують і той, і інший порти. Хоча деякі сервера підтримують порт 465 для безпечного SMTP, але краще використовувати стандартні порти і ESMTP-команди, якщо необхідна захищена сесія між клієнтом і сервером.

Деякі сервера налаштовані на відхилення всіх ретрансляції по порту 25, але користувачам, які пройшли аутентифікацію по порту 587, дозволено перенаправляти повідомлення на будь дійсну адресу.

Деякі провайдери перехоплюють порт 25, перенаправляючи трафік на свій власний SMTP-сервер незалежно від адреси призначення. Таким чином, їх користувачі не можуть отримати доступ до сервера за межами провайдерської мережі по порту 25.

Деякі сервера підтримують аутентіфіцированний доступ по додатковому, відмінному від 25, порту, дозволяючи користувачам з'єднуватися з ними, навіть якщо порт 25 заблокований.



5. Приклад найпростішої 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:  S: 250 someusername@somecompany.ru sender accepted C: RCPT TO:  S: 250 user1 @ company.tld ok C: RCPT TO:  S: 550 user2@company.tld unknown user account C: DATA S: 354 Enter mail, end with "." on a line by itself C: from: someusername@somecompany.ru / / щоб лист C: to: user1@company.tld / / не було додано C: subject: tema / / в категорію спам C: / / C: Hi! C:. S: 250 769947 message accepted for delivery C: QUIT S: 221 mail.company.tld CommuniGate Pro SMTP closing connection S: (закриває з'єднання) 

В результаті такої сесії лист буде доставлено адресату user1@company.tld, але не буде доставлено адресату user2@company.tld, тому що такої адреси не існує.


6. Додаткові розширення

Багато клієнтів запитують розширення SMTP, підтримувані сервером, за допомогою команди EHLO із специфікації розширеного SMTP (RFC 1870). HELO використовується тільки в тому випадку, якщо сервер не відповів на EHLO. Сучасні клієнти можуть використовувати ключ SIZE розширення ESMTP для запиту максимального розміру повідомлення, яке буде прийнято. Більш старі клієнти і сервери можуть спробувати передати надмірно великі повідомлення, які будуть відхилені після споживання мережевих ресурсів, включаючи час з'єднання. Користувачі можуть вручну заздалегідь визначити максимальний розмір, який приймається ESMTP-серверами. Клієнт замінює команду HELO на EHLO.

 S: 220 smtp2.example.com ESMTP Postfix  C: EHLO bob.example.org  S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]  S: 250-SIZE 14680064  S: 250-PIPELINING  S: 250 HELP 

smtp2.example.com оголошує, що він прийме повідомлення розміром не більше ніж 14,680,064 октетів (8-бітних байтів). В залежності від фактичного використання сервера, він може на даний момент не прийняти повідомлення такої величини. У найпростішому випадку, ESMTP-сервер оголосить максимальний SIZE тільки при взаємодії з користувачем через EHLO.



7. Безпека SMTP і спам

Споконвічна специфікація SMTP не включала засобів для аутентифікації відправників. Згодом, в RFC 2554 було введено розширення. Розширення SMTP (ESMTP) надає поштовим клієнтам механізм завдання механізму забезпечення безпеки для сервера, аутентифікації і профілю безпеки SASL (Simple Authentication and Security Layer) для наступних передач повідомлень.

Продукти Microsoft реалізують власний протокол - SPA (Secure Password Authentication) за допомогою розширення SMTP-AUTH.

Однак, непрактичність широкого розповсюдження реалізації та управління SMTP-AUTH означає, що проблема спаму не може бути вирішена за його допомогою.

Обширне зміна SMTP, так само як і повна його заміна, вважаються непрактичними через величезну інстальованої бази SMTP. Internet Mail 2000 був одним із претендентів для такої заміни.

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

Існує кілька пропозицій для побічних протоколів, що допомагають роботі SMTP. Дослідницька група Anti-Spam (The Anti-Spam Research Group - ASRG) - підрозділ Дослідницької групи Інтернет-технологій працює над поштової аутентифікацією і іншими пропозиціями для надання простої аутентифікації, яка буде гнучкою, легковагої і масштабованої. Недавня діяльність Інженерної ради Інтернету (IETF) включає в себе MARID (2004), що призвів до двох затвердженим IETF-експериментам в 2005, і DomainKeys Identified Mail в 2006.


8. Розширення 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 

9. Стандарти RFC


Література

  • Hughes L Internet e-mail Protocols, Standards and Implementation. - Artech House Publishers, 1998. - ISBN 0-89006-939-5
  • Hunt C sendmail Cookbook. - O'Reilly Media, 2003. - ISBN 0-596-00471-0
  • Johnson K Internet Email Protocols: A Developer's Guide. - Addison-Wesley Professional, 2000. - ISBN 0-201-43288-9
  • Loshin P Essential Email Standards: RFCs and Protocols Made Practical. - John Wiley & Sons, 1999. - ISBN 0-471-34597-0
  • Rhoton J Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. - Elsevier, 1999. - ISBN 1-55558-212-5
  • Wood D Programming Internet Mail. - O'Reilly, 1999. - ISBN 1-56592-479-7
Перегляд цього шаблону Схеми URI
Офіційні aaa : aaas : acap : cap: cid : crid: Data : dav : dict : dns : fax : file: ftp : Go : gopher : h323 : http : https : im : imap : ldap : mailto: mid : news : nfs : nntp : pop : pres: rtsp : sip : sips: snmp : tel : telnet : urn : wais : xmpp :
Неофіційні about : aim : bolo: btc : bzr : callto : chrome : cvs : daap : ed2k : ed2kftp : feed: fish: git : gizmoproject : iax2 : irc : ircs : lastfm : ldaps : magnet : mms : msnim : psyc: rsync : secondlife : skype : ssh : svn : sftp : smb : sms : soldat : steam : unreal : ut2004 : view-source : vzochat: webcal: xfire : ymsgr :
Перегляд цього шаблону Основні протоколи TCP / IP за рівнями моделі OSI ( Список портів TCP і UDP)
Фізичний
Канальний
Мережевий
Транспортний
Сеансовий
Уявлення
Прикладної

BGP HTTP HTTPS DHCP IRC SNMP Над DNS DNSSEC NNTP XMPP SIP IPP NTP SNTP Електронна пошта (SMTP POP3 IMAP 4) Передача файлів ( FTP TFTP SFTP) Віддалений доступ ( rlogin Telnet SSH RDP)

Інші прикладні