Hазад до Змiсту

Електронна пошта Internet E-mail

1. Введення
2. Internet e-mail адресацiя
3. Формат поштових повiдомлень
4. MIME - стандарт поштового повiдомлення
5. Модель роботи SMTP
6. POPv3 - поштовий протокол для роботи в офiсi
7. IMAPv4 - протокол доступу до електоронної пошти Internet

Електронна пошта (e-mail), мабуть, найбiльш поширений сервiс у Internet. Швидкий i простий зв'язок мiж людьми всiєї земної кулi, формування партнерства, загальних iнтересiв - усе це риси e-mail. Але обмiн iдеями й iнформацiєю мiж окремими людьми - це ще не все. Ви завжди можете звернутися з "широкомовним" запитом, одержати думки, вiдгуки, необхiднi документи, брати участь у дискусiях, як i тисячi iнших людей, що мають доступ до Internet.
В Internet для роботи з електронною поштою використовуються прикладнi протоколи SMTP, POP, IMAP.
Протокол SMTP (Simple Mail Transfer Protocol - простий протокол передачi пошти) пiдтримує передачу повiдомлень мiж довiльними вузлами Internet. Маючи механiзми промiжного збереження пошти i пiдвищення надiйностi доставки, протокол SMTP припускає користування рiзноманiтних транспортних служб i поштових серверiв. Вiн може працювати навiть у мережах, що не пiдтримують стiк протоколiв TCP/IP. Протокол SMTP дозволяє групувати повiдомлення на адресу одного одержувача i розмноження копiй e-mail- повiдомлення для передачi за рiзними адресами.
POP (Post Office Protocol) дає кiнцевому користувачу доступ до до його електронних повiдомлень. POP-клiєнти при запитi користувача на одержання пошти зажадають ввести пароль, що пiдвищує конфiденцiйнiсть листування.
Запити програм-клiєнтiв вiдстежуються демоном (daemon), процесом, що знаходиться у "сплячому" станi, деякий час в UNIX-системах. Так, pop3d - демон, що дозволяє не тiльки одержати листа, але й вiдправити свої повiдомлення через e-mail.

Пiсля того, як визначилися iз своїм адмiнiстратором у вiдношеннi свого iдентифiкатора i пароля, ви одержуєте свою унiкальну адресу i вiдповiдно можливiсть вiдправляти й одержувати поштовi повiдомлення через Internet.
Ваша адреса, як i адреса будь-якого iншого користувача, детально описує, хто вiн (вона) i де вiн (вона) розмiщуються в мережi. Електронна пошта знаходить адресата завдяки унiкальностi його адреси, що розпiзнається кожним комп'ютером у мережi.
Абсолютно кожен комп'ютер розумiє (i завдяки цьому iснує в мережi) загальну структуру адрес e-mail, що зветься DNS (domain name system - система доменних iмен). Саме DNS, "маючи деревоподiбну" схему, визначає кожну людину на кожному комп'ютерi в мережi, у будь-якому його вузлi, у кожнiй органiзацiї, залученiй до Internet.
У загальному виглядi Internet-адреси записуються як:

mailbox@domain

На жаль, рамки даного посiбника не дозволяють докладно розiбрати всi типи поштових повiдомлень, рiзновиди кодувань i представлень даних. Доступний i докладний виклад цiєї теми може скласти декiлька об'ємних томiв . У даному роздiлi будуть коротко викладенi найбiльш поширенi типи форматiв та їх взаємодiя мiж собою.
Будь-яке повiдомлення складається з конверта повiдомлення i тiла повiдомлення. Конверт мiстить iнформацiю, необхiдну для доставки й обробки повiдомлення. Тiло повiдомлення мiстить iнформацiю, яку вiдправник передає одержувачу. Iншими словами, конверт являє собою каркас, на який накладаються данi користувача. Конверт i данi в повiдомленнi тiсно взаємозв'язанi один з одним, усi поштовi системи для побудови конверта використовують iнформацiю тiла повiдомлення. Структура конверта, як правило, задається локальним поштовим програмним забезпеченням. Тому перед тим як вiдправляти данi у певному конвертi, потрiбно переконатися, що одержувач цих даних зумiє витягти їх з конверта.
У найпростiшому випадку конверт повiдомлення складається тiльки з заголовка. Заголовок вiддiлений вiд тiла повiдомлення порожнiм рядком. Заголовок складається з декiлькох рядкiв, що мiстять iнформацiю про повiдомлення.
Кожен рядок заголовка мiстить iм'я поля заголовка i данi поля заголовка. Iм'я поля вiддiлене вiд даних символом ":". Назви полiв повиннi складатися iз символiв ASCII вiд 32 до 126. Кожен рядок закiнчується <CRLF>. Певнi поля даних повиннi мати задану структуру, наприклад, поля "Date:", "From:" i т.д., iншi поля можуть мати довiльну структуру, наприклад, поля "Subject:", "Comments:" та iн.
Розглянемо склад i структуру основних полiв повiдомлення на наступному найпростiшому прикладi:

From: Somebody M.S.<mike@joke.ru>
To: zol@fun.ru
Date: Wed, 10 Sep 1997 16:17:50 +0300
Subject: Hello
Message-ID: <some.string@joke. ru>

Hello!
How do you do?

Це текст повiдомлення разом iз заголовком повiдомлення. Як ви бачите, повiдомлення досить небагатослiвне. Бiльша його частина являє собою заголовок. Розберемо докладнiше склад i структуру полiв конверта повiдомлення.

· Поле "From:" мiстить адресу вiдправника. Це поле мiстить адресу автора повiдомлення. Як правило, цей iдентифiкатор встановлюється в параметрах настроювання програми поштового клiєнта. Якби вiдправник доручив кому-небудь iншому вiдправити за нього повiдомлення, наприклад, своєму секретарю, повiдомлення мiстило б поле "Sender:". У цьому полi був би зазначений реальний вiдправник повiдомлення, тобто iдентифiкатор користувача, що ввiйшов у поштову систему i вiдправив даний лист, користуючись, наприклад, настроюваннями програми клiєнта автора повiдомлення. Наприклад, якби повiдомлення було вiдправлено секретарем lisa@joke.ru, воно мiстило б наступне:

From: mike@joke.ru (mike@joke.ru)
Sender: lisa@joke.ru

Поле "From:" може мiстити декiлька адрес вiдправникiв, вiд iменi яких було вiдправлене повiдомлення, але не повинно мiстити групову адресу, наприклад:

From: mike@ joke. ru,
vlad@joke. ru
Sender: lisa@joke.ru

Поле "To:" мiстить адресу(и) одержувача(iв) - кому призначене дане повiдомлення. Будь-яке повiдомлення повинно мiстити або поле "То:", або поле "Сс:" - яке мiстить адреси одержувачiв копiй даного повiдомлення, наприклад:

То: Oden@Mad-Host,
lrving@ Other-Host
Сс: Simmons@bra.x400.icl.co.uk, Blob@ultra.x400.icl.uk

·Поле "Date:" мiстить дату вiдправлення повiдомлення поштовою системою. Поле дати мiстить дату, час i годинну зону. Формат дати також залежить вiд поштової системи.

Поле "Subject:" мiстить тему даного повiдомлення, заповнюється користувачем самостiйно, вiдповiдно до утримування iнформацiйної частини повiдомлення.

Поле "Message-Id:" мiстить унiкальний iдентифiкатор повiдомлення. Вiн використовується для посилань на дане повiдомлення iнших повiдомлень та iдентифiкацiї частин даного повiдомлення. Склад iдентифiкатора визначається типом поштової системи i, як правило, складається з рядка символiв i адреси хоста вiдправника.

У повiдомленнi може бути поле "Reply-To:" - де зазначена поштова скринька, куди слiд надсилати вiдповiдi на дане повiдомлення. Наприклад, якщо вiдправник, що має адресу mike@joke.ru, захоче, щоб вiдповiдь на його повiдомлення одержав його секретар, вiн може зазначити:

Reply-To: lisa@joke.ru

Вiдповiдi на повiдомлення, у заголовку якого є поле "Reply-To:", вiдправляються за зазначеною в цьому полi адресою. Якщо цього поля немає, вiдповiдi надсилаються за адресою, зазначеною в полi "From:".

Мiнiмальний заголовок повiдомлення повинен мiстити поля:"Date:", "From:", "То:" або "Сс:". Усi iншi поля не є обов'язковими у форматi заголовка повiдомлення, i їх наявнiсть i змiст безпосередньо залежать вiд типу поштової системи, що використовується.
При передаваннi повiдомлення через промiжнi поштовi сервери до заголовка добудовуються записи "received:", що мiстять поля з адресами й часом обробки повiдомлення промiжними серверами, наприклад:

Received: from ns. joke. ru (ns.joke.ru [199.86.42.18])
by bulldozer.arcom.spb.su (8.8.5/t/97-Mar-14) with ESMTP id QAA10700
for <zol@joke.ru> Wed, 10 Sep 1997 16:24:02 +0400 (MSD)

Заголовок також може мiстити запис типу i версiї програмного забезпечення клiєнта ("X-Mailer:"), коментарi ("Comments:"), прiоритетнiсть ("Priority:") та iн., наприклад:

Priority: normal
X-rnailer: Pegasus Mail v3.22

Черговiсть полiв заголовка визначається поштовою системою, але, як правило, вони розмiщуються таким чином: "Received:", "Date:", "From:", "Subject:", "Sender:", "Reply-To:", "To:", "Cc:", "Comment:", "X-Mailer:", "Message-ID:" та iн.
На початковому етапi розвитку електронної пошти було цiлком достатньо передавати мiж користувачами тiльки текстовi повiдомлення, що мiстили тiльки символи з набору ASCII. Якщо користувачу потрiбно було вiдправити зображення або файл, що виконується , вiн кодував його символами ASCII i вставляв у текст повiдомлення.
Iз зростанням популярностi електронної пошти i розширенням можливостей комп'ютерiв i лiнiй передачi, з'явилася необхiднiсть передавати поштою тексти, написанi рiзними нацiональними мовами, зображення, файли, що виконуються , вiдео та iншi бiнарнi данi в унiфiкованому форматi. Стара схема передавання таких даних ставала все бiльш незручною через те, що:

• Рiзнi клiєнти працювали з рiзноманiтними типами кодування, що часто призводило до неможливостi прочитати адресатом отриманi данi.

• Не була визначена структура розмiщення й iдентифiкацiї типу кодованих даних. Щоб зрозумiти, що являє собою отримана iнформацiя, її треба було вийняти з повiдомлення i розкодувати.
  У результатi було сильно ускладнено, а реально i унеможливлено, розвиток програмних засобiв перегляду даних повiдомлення "на льоту", тобто щоб програмне забезпечення клiєнта могло автоматично розпiзнавати тип даних i подавати їх користувачу вiдразу пiд час перегляду повiдомлення.

Для бiльш зручної роботи зi складовими i нестандартними (не ASCII) повiдомленнями був розроблений стандарт MIME (Multipurpose Internet Mail Extensions, Багатоцiльове розширення електронної пошти).
Стандарт MIME не замiнює, а розширює iснуючий дотепер засiб форматування повiдомлень. MIME являє собою новий формат подання даних, що дозволяє поштовому клiєнту зручний i гнучкий iнтерфейс роботи з електронною поштою. MIME - це, образно говорячи, новий конверт, у який ви можете покласти рiзноманiтний текст, графiчнi зображення, вiдеофрагменти i вiдправити адресату, який, в свою чергу, може швидко i без проблем скористатися всiєю отриманою iнформацiєю. Повiдомлення побудоване з використанням MIME, якщо в його заголовку присутнi такi поля:

• Стандарт MIME iдентифiкується в поштовому повiдомленнi полем "Mime-Version:", що мiстить рядок версiї MIME розширення даного повiдомлення.

  Наприклад: "Mime-Version: 1.0".

• Поле "Content-Type:" вказує склад повiдомлення:
  1. "text" - повiдомлення мiстить текстову iнформацiю у виглядi послiдовностi символiв iз набору, визначеного параметром "charset" (us-ascii, iso-8859-1, koi8-r, windows-1251 та iн.).

     Наприклад: "Content-Type: text/plain; charset="iso-8859-l""

  2. "multipart" - означає, що дане повiдомлення складається з декiлькох окремих блокiв, кожен з яких описує свiй склад самостiйно. Даний тип має параметр "boundary", що мiстить рядок-роздiльник частин повiдомлення.

     Наприклад:
     "Content-Type: multipart/mixed; boundary="this is a separator""

  3. "application", "image", "audio", "video" - означають, що повiдомлення мiстить бiнарнi данi визначеного типу.

     Наприклад:
     "Content-Type: application/rnsword; name="file.doc"" або "Content-Type: image/gif; name="pic.gif""

  4. "message" - повiдомлення мiстить iнше повiдомлення.

     Наприклад, рядок
     "Content-Type: message/RFC-822"

     вказує, що далi випливає повiдомлення, вiдформатоване вiдповiдно до правил, сформульованих у документi RFC-822.

  Примiтка - RFC-822 - це основний документ форматiв поштових повiдомлень. Вiн описує тiльки найголовнiшi структури поштових повiдомлень без яких-небудь розширень. Якщо зазначено, що повiдомлення сформоване на пiдставi RFC-822, то це значить, що дане повiдомлення складене в канонiчному виглядi.

• Поле "Content-Transfer-Encoding:" мiстить iдентифiкатор типу кодування, що використовується в даному повiдомленнi або його частинi: "base64", "quoted-printable", "7bit", "8bit", "binary" або iн.
  

Особливiсть типiв кодування - "7bit", "8bit", "binary" -полягає в тому, що вони не припускають нiякого кодування. Цi типи тiльки позначають, що данi поданi у визначеному виглядi. "7bit" - данi мiстять тiльки ASCII- символи, "8bit" i "binary" - вказують на те, що данi мiстять не тiльки ASCII-символи. Рiзниця мiж типами "8bit" i "binary" полягає в обмеженнi довжини рядка даних. У типу "8bit" рядок обмежений довжиною рядка SMTP-протокола - 1000 байт, а типу "binary" таких обмежень немає.

Примiтка - Кодування "8bit", як правило, використовується для передавання текстових повiдомлень рiзними нацiональними мовами, а кодування "binary" - для передавання графiки, вiдео i т.п. Для передавання даних у цих кодуваннях сервери SMTP повиннi вмiти працювати з 8-бiтними даними, тобто пiдтримувати розширення протоколу SMTP-ESMTP.

Кодування "quoted-printable", як правило, призначене для кодування текстiв рiзними нацiональними мовами. Бiльш докладну iнформацiю про це кодування можна знайти в RFC-1341.
Кодування "base64" використовується, як правило, для представлення частини повiдомлення, що не зчитується: зображень, бiнарних файлiв, вiдео тощо.
Кодування "base64", "quoted-printable", "7bit" пiдтримуються практично всiма поштовими серверами.
Рамки даного посiбника не дозволяють бiльш детально зупинятися на обговореннi значень MIME-параметрiв i їхнiх комбiнацiй. Для того щоб бiльш детальнiше познайомитися з можливостями MIME i форматами листiв електронної пошти, вам належить вивчити вiдповiднi RFC, наприклад:
RFC-1341, RFC-1342, RFC-1521, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049

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

Протокол SMTP спроектований на основi такої моделi взаємодiї: за запитом користувача вiдправник SMTP (sender - SMTP) встановлює двобiчний канал з одержувачем SMTP (receiver - SMTP). Одержувачем SMTP може бути як хост призначення поштового повiдомлення, так i якийсь промiжний хост. Команди SMTP генеруються вiдправником i вiдправляються одержувачу SMTP, що, в свою чергу, вiдправляє вiдповiдi опрацювання отриманих команд вiдправнику SMTP.
Схема роботи SMTP-протоколу
Найпростiший алгоритм роботи протоколу має такий вигляд:

1. Пiсля встановлення каналу SMTP-з'єднання за будь-яким транспортним протоколом вiдправник SMTP посилає команду MAIL, що iдентифiкує атрибути вiдправника пошти, наприклад, його адресу. Якщо одержувач SMTP може прийняти поштове повiдомлення, вiн вiдправляє у вiдповiдь команду ОК.
2. Пiсля цього вiдправник SMTP вiдправляє команду RCPT, що iдентифiкує атрибути одержувача пошти, наприклад, адресу поштової скриньки. Якщо одержувач SMTP готовий прийняти пошту в дану поштову скриньку, вiн вiдповiдає командою ОК, якщо нi, вiн вiдмовляє прийняти пошту в зазначену поштову скриньку. Якщо вiдправник зазначив декiлька поштових скриньок, у якi варто помiстити повiдомлення, то одержувач SMTP повiдомлення може вiдмовити частинi з них, при цьому транзакцiя з'єднання не закiнчується.
3. Вiдправник SMTP вiдправляє данi одержувачу SMTP. Якщо одержувач успiшно прийняв усi данi, вiн вiдправляє команду ОК.

SMTP пiдтримує декiлька механiзмiв передавання пошти: вiд хоста користувача - вiдправника до хосту користувача - одержувача, коли два хости сполученi мiж собою через той самий транспортний сервiс або через сервери SMTP (тобто хости - посередники), якщо вiдправник i одержувач не можуть з'єднатися.
Аргументи команди MAIL мiстять iм'я домену вiдправника пошти, тобто SMTP-адресу поштової скриньки - зворотну адресу. Аргументи команди RCPT мiстять адресу поштової скриньки одержувача повiдомлення. Цi параметри не змiнюються в процесi передавання повiдомлення i використовуються SMTP-серверами, наприклад, для повернення повiдомлень, якi не були доставленi.
SMTP-команди мають суворо визначений синтаксис. Вiдповiдi опрацювання команд мають чисельнi коди. Команди i вiдповiдi являють собою рядки iз символiв ASCII. Команди i вiдповiдi не залежать вiд регiстра символiв (чого не можна сказати про iмена поштових скри ньок). Якщо транспортний сервiс не пiдтримує 8-бiтний канал, кожен iз 7-бiтних символiв передається зi старшим (нульовим) бiтом, що допiвнює нулю.
Транзакцiя SMTP вiдправлення пошти складається з трьох крокiв. Початок транзакцiї задається командою MAIL, що идентифiкує вiдправника, потiм випливає серiя команд RCPT, що визначають поштовi скриньки одержувачiв, потiм подається команда DATA для передачi тексту повiдомлення. Завершує передачу даних командний рядок закриття транзакцiї.

Для невеликих органiзацiй невигiдно тримати у себе систему для передавання повiдомлень (message transport system). Це позв'язано з тим, що в невеликих органiзацiях, якi не спецiалiзуються на комп'ютерних технологiях, як правило, робочi станцiї клiєнтiв мережi не мають досить ресурсiв (продуктивностi або дискового простору) для забезпечення роботи повного SMTP-сервера. Крiм того, таким користувачам електронної пошти може бути просто невигiдно тримати персональний комп'ютер постiйно пiдключений до Internet.
Для вирiшення цiєї проблеми був розроблений поштовий протокол для роботи в офiсi -- POP (Post Office Protocol). Його найбiльш поширений варiант -РОРЗ (Протокол поштового вiддiлення версiї 3). Цей протокол дозволяє робочим станцiям динамiчно одержувати доступ до своїх поштових скриньок, розташованих на серверi, призначеному для обслуговування електронної пошти в данiй органiзацiї.
РОРЗ - це найпростiший протокол для роботи користувача з вмiстом своєї поштової скриньки. Вiн дозволяє тiльки забрати пошту з поштової скриньки сервера на робочу станцiю клiєнта i видалити її з поштової скриньки на серверi. Всю подальшу обробку поштове повiдомлення проходить на комп'ютерi клiєнта.
POP-сервер не вiдповiдає за вiдправлення пошти, вiн працює тiльки як унiверсальна поштова скринька для групи користувачiв. Коли користувачу необхiдно вiдправити повiдомлення, вiн повинен встановити з'єднання з яким-небудь SMTP-сервером i вiдправити туди свої повiдомлення по SMTP. Цей SMTP-сервер може бути тим же хостом, де працює РОРЗ-сервер, а може розташовуватися зовсiм в iншому мiсцi (в iншому доменi або взагалi де завгодно в Internet).
Як правило, пiд час роботи з електронною поштою невеликi органiзацiї використовують для одержання своєї кореспонденцiї РОРЗ-сервер, встановлений на будь-якому комп'ютерi в офiсi, а вiдправляють пошту по SMTP на один iз добре доступних загальновiдомих SMTP-серверiв мiста (знайти такi зовсiм нескладно).
РОР3-сервiс, як правило, встановлюється на 110-й TCP-порт сервера, що буде знаходитися в режимi очiкування вхiдного з'єднання. Коли клiєнт хоче скористатися POP3-сервiсом, вiн просто вiдкриває TCP-зiєднання з портом 110 цього хоста. Пiсля вiдкриття з'єднання сервiс РОРЗ вiдправляє клiєнту, що зiєднався, привiтальне повiдомлення. Пiсля цього клiєнт i сервер починають обмiн командами i даними. По закiнченнi обмiну POP3-канал закривається.
Бiльш докладну iнформацiю про протокол POP3 можна знайти на Web-серверi Сумського державного унiверситета за адресою http://www.ssu.sumy.ua

• RFC-1081, RFC- 1082
• RFC- 1225, RFC- 1725
• RFC- 1939

Протокол IMAP4 (Internet Message Access Protocol, Version 4, Протокол доступу до електронної пошти Internet, версiя 4) дозволяє клiєнтам одержувати доступ i манiпулювати повiдомленнями електронної пошти на серверi.
Протокол IМАР4 вiдрiзняється вiд протоколу РОРЗ тим, що iМАР4 пiдтримує роботу iз системою каталогiв (або папок) повiдомлень. IМАР4 дозволяє керувати каталогами (папками) вiддалених повiдомлень так само, якби вони розташовувалися у локальному комп'ютерi. IМАР4 дозволяє клiєнту створювати, видаляти та перейменовувати поштовi скриньки, перевiряти наявнiсть нових повiдомлень i видаляти старi. Завдяки тому що IМАР4 пiдтримує механiзм унiкальної iдентифiкацiї кожного повiдомлення в поштовiй папцi клiєнта, вiн дозволяє читати з поштової скриньки тiльки повiдомлення, що задовольняють визначенi умови або їх частини, змiнювати атрибути повiдомлень i перемiщати окремi повiдомлення.
Структура папок значною мiрою залежить вiд типу поштової системи, але в будь-якiй системi клiєнт має спецiальний каталог INBOX, до якого потрапляють повiдомлення, що надiйшли клiєнту.
Протокол IМАР4 працює поверх транспортного протоколу, що забезпечує надiйний i достовiрний канал передавання даних мiж клiєнтом i сервером IМАР4. Пiд час роботи з TCP IМАР4 використовує 143-й порт. Команди i данi IМАР4 передаються за транспортним протоколом в тому виглядi, у якому їх вiдправляє сервер або користувач.
Принцип передавання даних IМАР4 такий же, як i в iнших подiбних протоколах. Спочатку клiєнт i сервер обмiнюються вiтаннями. Потiм клiєнт вiдправляє на сервер команди i данi. Сервер вiдповiдно передає клiєнту вiдповiдi на обробку команд i даних. Пiсля завершення обмiну канал закривається.

Бiльш докладну iнформацiю вiдносно протоколу IMAP4 можна знайти на Web-серверi Сумського державного унiверситета за адресою http://www.ssu.sumy.ua в RFC-1730, RFC- 2060, RFC- 2062 .

Сервiси Internet Кафедра прикладної математики Сумський державний унiверситет

Автори: Любчак В.О. Божко О.I. lena@ssu.sumy.ua