Митні інформаційні технології - Пашко П.В. -
Схеми фізичної реалізації електронної пошти Х.400

Нужен натяжной потолок в Киеве, Ирпене, Буче? тогда тебе сюда SkyKey
STOP! Тебе нужен реферат, курсовая, дипломная работа? тогда нажми КЛАЦ Промокод на скидку 5% для пользователей нашего сайта fr054-330

Багатошарова модель не містить жодних припущень про спосіб фізичної реалізації різних об'єктів систем обробки повідомлень.

На рис. 7.9, а відображено варіант реалізації агента пересилання повідомлень і двох агентів користувачів в одному комп'ютері. У цьому разі користувачі можуть застосовувати дуже прості термінали, які мають тільки клавіатуру і дисплей.

На рис. 7.9, б наведено систему обробки повідомлень для двох комп'ютерів, які розподіляють функції цієї системи. У першій частині знову агенти користувачів і агенти пересилання повідомлень суміщені в одному комп'ютері, що дає змогу користувачу застосовувати простий термінал. Ліворуч система містить агента пересилання повідомлень і одне або декілька сховищ повідомлень. У цьому разі функції агента користувача будуть реалізовані в терміналі користувача (ТК), який має виконувати функції обробки повідомлень. Для реалізації цих функцій необхідно використовувати персональний комп'ютер (ПК).

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

Наведені на рис. 7.9 варіанти не охоплюють усі можливі конфігурації систем обробки повідомлень. Відображені структури є тільки ілюстрацією до необмеженої кількості варіантів організації системи обробки повідомлень.

Способи фізичної реалізації системи обробки повідомлень

X.400-система і довідкова Х.500-служба

Процес доставки повідомлення потребує відомостей про адреси одержувача, а за великих обсягів мережі запам'ятати всі адреси дуже складно і необхідно мати довідкову службу, яка б допомагала отримати адреси відправника/отримувача. Рекомендації МККТТ Х.500 можна розглядати як стандарт для подібної довідкової служби.

Мета довідкової Х.500-системи — забезпечення глобальної довідкової служби. Всі користувачі потенційно мають право входу в цей довідник, використовуючи певний набір атрибутів. Входи в інформаційну базу довідника розподілено за так званим інформаційно-довідковим номером. Вершини дерева є входами: більш високі вершини — це країни, далі йдуть організації тощо.

Якщо користувач не знає адреси відправника/одержувача, а знає тільки його довідкове ім'я, то функції присвоєння виконує найближчий X.400 агент пересилання повідомлень. Агент пересилання повідомлень також може перевіряти правильність адреси відправника/одержувача, присвоєної на попередніх етапах пересилання.

Взагалі, довідкова служба повинна забезпечувати користувача інформацією щодо своїх потенційних партнерів.

Протокол SMTP

SMTP (Simple Message Transfer Protocol), або, в дослівному перекладі, простий протокол передачі повідомлень, був створений у середовищі UNIX і призначався винятково для спілкування поштових серверів між собою. У термінах моделі OSI протокол SMTP перебуває на рівні додатків.

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

— розширення протоколу спілкування сервер – сервер (власне SMTP);

— створення й поліпшення протоколу спілкування клієнт

— сервер (РОРЗ, ІМАР4);

— впровадження й розширення нового формату повідомлень (МІМЕ).

Початкова версія протоколу SMTP підтримувала обмежений набір команд і сервісів для прийому і передачі повідомлень. Останнім часом був розроблений його розширений варіант (Extended або ESMTP), що забезпечує стандартну можливість подальшого розширення і підтримку таких функцій, як підтвердження доставки (Delivery Notification Request, або DNR), узгодження максимально допустимого розміру повідомлень, переданих між серверами та примусовою ініціацією передачі накопиченої пошти (dequeue). Однак однією зі слабких сторін SMTP були і є неможливість аутентифікації вхідних з'єднань, шифрування діалогу й потоку передачі даних між серверами.

Відсутність засобів аутентифікації вхідних з'єднань не дозволила використовувати SMTP для обслуговування клієнтського доступу. Класична поштова SMTP-система вимагає наявності файлового доступу клієнта до своєї поштової скриньки для одержання та роботи з повідомленнями. Для реалізації роботи в режимі клієнт-сервер був створений протокол обслуговування поштового офісу (Post Office Protocol, або POP). Найбільш вдалою виявилася версія РОРЗ, що широко використовується в сучасних SMTP-системах. Найбільш розвинені реалізації підтримують аутентифікацію із шифруванням імені і пароля та трафіку за протоколом Secure Socket Layer (SSL). Однак під час використання протоколу РОРЗ немає можливості перегляду характеристик повідомлення без попереднього завантаження його на станцію клієнта. Для рішення проблеми перегляду й маніпуляції властивостями поштового повідомлення безпосередньо на сервері, а також для подолання низки інших функціональних обмежень був розроблений протокол ІМАР4, його підтримка в більшості комерційних систем очікується у найближчому майбутньому. Варто зазначити, що як для випадку використання класичного клієнта (команда mail), так і для випадку застосування РОРЗ або ІМАР4, відправлення підготовлених клієнтом повідомлень вимагає наявності сервера SMTP.

Спочатку SMTP-системи розраховували на передачу інформації винятково в текстовому вигляді й не були орієнтовані на передачу символів національних алфавітів, тобто використовували 7-бітний набір символів. Для рішення проблеми передачі двійкових файлів був розроблений стандарт UUENCODE, що дає змогу приймати попередньо перетворені з бінарного у текстовий вигляд довільні дані безпосередньо в текст повідомлення. Однак всеосяжним такий підхід назвати було важко, тому що в загальному випадку ніякої інформації про природу вкладення (типу переданих даних і програму, що їх створила) приймаюча сторона не мала. У міру розширення мережі Інтернет, ускладнення програмного забезпечення й активного впровадження мультимедіа назріла необхідність створення універсального формату типізації й подання двійкових даних і тексту, що містить національні символи. Таким універсальним форматом стали багатофункціональні розширення пошти (Multipurpose Internet Mail Extensions, або МІМЕ). Формат MIME виявився надзвичайно вдалим, оскільки в нього були закладені можливості необмеженого розширення, як підтримуваних типів даних, так і національних кодувань.

Повідомлення SMTP, подібно повідомленню Х.400, використовує поняття конверту та змісту, що, у свою чергу, має заголовок і тіло. Функціональне призначення їх повністю ідентичне. Склад полів у заголовку визначається форматом тіла повідомлення (UUENCODE або МІМЕ). Жодне поле не є обов'язковим, але, як правило, вказуються такі поля, як кому (То:), від кого (From:) і тема (Subject:). У випадку використання формату МІМЕ, у заголовку обов'язково повинен бути рядок "MIME-Version: 1.0". Повний перелік можливих полів у заголовку повідомлення SMTP знаходиться в RFC 2076.

Відмінною рисою SMTP-систем є те, що в них, як правило, забезпечується фактична незалежність процесу передачі від формату вмісту. За інтерпретацію вмісту їм повинна відповідати тільки клієнтська програма (mail reader). Однак платою за сумісність на рівні МТА у цьому випадку є неефективність передачі будь-яких нетекстових даних або повідомлень, що використовують символи національних алфавітів, внаслідок попередньої трансляції інформації в текстове подання. Залежно від використовуваного алгоритму перетворення розмір фактично переданих даних може зрости на 30—100 %.

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

Simple Mail Transfer Protocol не залежить від транспортного середовища й може використовуватися для доставки пошти в мережах із протоколами, відмінними від TCP/IP і Х.25. Досягається це за рахунок концепції ІРСЕ (Interprocess Communication Environment). ІРСЕ дає змогу взаємодіяти процесам, що підтримують SMTP в інтерактивному режимі, а не в режимі "STOP-GO".

X.400-система і довідкова Х.500-служба
Протокол SMTP
Модель протоколу
Формат поштового повідомлення (RFC-822)
Дисципліни роботи й команди протоколу
Адресація в SMTP-системах
Маршрутизація
МІМЕ (Multipurpose Internet Mail Extension)
Доступ до поштової скриньки за допомогою РОРЗ і IМАР
Протокол РОРЗ (Post Office Protocol version 3)
© Westudents.com.ua Всі права захищені.
Бібліотека українських підручників 2010 - 2017
Всі матеріалі представлені лише для ознайомлення і не несуть ніякої комерційної цінностію
Электронна пошта: site7smile@yandex.ru