Електронната поща



Дата10.04.2017
Размер96.11 Kb.
Размер96.11 Kb.











































23. Електронна поща вИнтернет
Общи положения

Електронната поща (e-mail или email) е метод за обмен на електронни съобщения. Едно съобщение се състои най-малко от съдържанието си, адрес на автора и адресите на един или повече получатели. Корените на днешната email са в Arpanet – стандарт за кодиране на съобщения - RFC 733. Преходът от Arpanet към Internet в началото на 1980-те добави постепенно новостите към основната услуга: - транспортния протокол Simple Mail Transfer ProtoCol (SMTP), RFC 821 през 1982 г. - ревизия на RFC 733 - RFC 822 - прикрепяния на мултимедия – от 1996 г. - от RFC 2045 до RFC 2049, известни като Multipurpose Internet Mail Extensions (MIME). Email се базират на модела с пълно буфериране (store-and-forward). Сървърът за електронна поща приема, препраща, доставя или съхранява съобщения за сметка на потребителите. Тяхна задача е само да се свържат към email инфраструктурата с помощта на компютрите си.
Терминология

Mail-box – файл или директория/и от файлове, където се съхраняват входящите съобщения.

mail user agent (MUA) е приложна програма, стартирана от потребителя. Използва се за оформяне и изпращане на съобщения, както и за показване, сортиране като файлове и принтиране на получени в кутията съобщения. Такива са elm, mailx, mh, zmail, Mozilla Thunderbird, MS Outlook и др. Mail transfer agent (MTA) осъществява маршрутизацията на съобщенията, подадени от MUA, до получателя. Най-популярният MTA е sendmail. Delivery agent поставя съобщението в пощенската кутия на потребителя. Най- популярният DA е mail.loCal.
AliCe си пише с Bob. Какво става

1.mail user agent (MUA) на Алис форматира съобщението в e-mail формат и с помощта на SMTP го изпраща към местния mail transfer agent (MTA) - smtp.a.org. 2. MTA гледа за крайния адрес, според SMTP протокола (а не в главата на съобщението) - bob@b.org. В e-mail адреса частта пред @ е локалната част, най-често потребителското име на получателя. Частта след @ е име на домейна. MTA по името на домейна определя пълното домейн име на пощенския сървър в DNS. 3. DNS сървърът за домейн b.org - ns.b.org, отговаря с MX записи, изброяващи пощенските сървъри в този домейн, в случая mx.b.org. 4. smtp.a.org изпраща съобщението до mx.b.org по SMTP, който го доставя до пощенската кутия (mailbox) на bob. 5. Bob натиска бутон "get mail" на своя MUA, с което изтегля съобщението с помощта на Post OffiCe ProtoCol (POP3).


Алтернативи на последователността

liCe може да няма MUA на компютъра си, а да се свърже към webmail услуга. На компютъра на AliCe може да е “качен” MTA, т.е да прескочи стъпка 1. Bob има много начини да изтегли пощата си, например, по протокол Internet Message ACCess ProtoCol, като се логне на mx.b.org и си я чете директно от там, или и той с webmail. В един домейн има няколко пощенски сървъра, така че те могат да продължат да приемат поща, даже когато главният е отпаднал. За повишаване на сигурността и конфиденциалността е добре пощата да се криптира (OpenPGP, X.500 сертификати). Но това е друга тема.

open mail relay

MTAs, които приемат съобщения от произволни податели и полагат максимални усилия да ги препратят по посока към получателите. Такива MTAs се наричат open mail relay. В зората на Internet, когато мрежите не бяха надеждни, това усилие беше похвално. Да може съобщението все пак да достигне целта си през един или повече relay. Но от този механизъм се възползваха недобросъвестни “изпращачи” на спам и друга нерегламентирана поща. Затова днешните MTAs не са open mail relays и не приемат поща от open mail relays, която си чист спам. Това важи и за сървърите СУ. Използваме и отворен софтуер SpamAssassin.


Формати

Форматът на e-mail съобщенията е дефиниран в RFC 5322 и серия от RFC-та, RFC 2045 до RFC 2049, "Multipurpose Internet Mail Extensions" или MIME. e-mail съобщенията се състоят от два основни дяла, отделени с празен ред: Header (глава) Структурирано е от полета, обобщение (summary), подател (sender), получател (reCeiver) и др. Body (тяло) Самото съобщение като неструктуриран текст. Понякога завършва и с “подпис”, signature bloCk.


Полета в заглавието

Заглавието включва най-малко следните полета: From: e-mail address и евентуално името на изпращача. При подателя се попълва автоматично. To: Адрес(ите) и евентуално име(ната) на

получател(ите). CC: До кой да се изпрати видимо за получателя To: копие. BCC: Blind Carbon Copy До кой да се изпрати невидимо за получателя To: копие. SubjeCt: Или Относно: Предмета на съобщението. Date: Дата и час на изпращане в локалното време. Поставя се автоматично.
Спекулации с "From" С полето "From" може лесно да се заблуждава, затова се препоръчва да се ползва цифрово подписване (OpenPGP или X.500 сертификат).
Други важни полета

In-Reply-To: Message-ID на съобщението, на което настоящото е отговор. ReCeived: Проследява пътя, по който е минало съобщението, през кои пощенски сървъри. Показва кой е истинския подател по IP адрес. ReferenCes: Message-ID на това съобщение и на това, на което е отговор. Reply-To: Адресът за отговор на подателя.

Кодиране. UTF-8.

Първоначално E-mail е била 7-bit ASCII. Стандартът MIME въведе предаване и на не-ASCII данни.



UTF-8 (8-bit UCS1/UniCode Transformation Format) е кодиране на знаците с променлива дължина за UniCode2.Представя всеки знак в UniCode стандарта, но в същевременно е обратно съвместим с ASCII. Затова става все по-предпочитан за e-mail, web и др. UTF-8 кодира всеки знак (Code point) с 1 до 4 байта, като с един байт се кодират 128 US-ASCII знаците. Internet Mail Consortium (IMC) препоръчва всички email програми дa са в състояние да изобразяват и създават поща с помощта UTF-8.

1.Universal CharaCter Set (UCS) ISO/IEC 10646 стандарт, разработен съвместно с UniCode Consortium.

2.UniCode осигурява уникален номер за всеки знак, независимо от платформата, независимо от програмата, независимо от езика
UTF-8

Първите 128 знака (US-ASCII) им трябва 1 байт. Следващите 1920 – 2 байта. Това са латински

букви с диакрити, гръцки, кирилица, арменски, арабски, иврит и др. 3 байта са необходими за за останалите лингвистични знаци. 4 байта – за знаци в други равнини на UniCode, рядко използвани в практиката.

Диакрити И обикновен текст и HTML се допускат в e-mail. Малка буква a с диакрит:


SMTP

Протоколът за изпращане на поща е SMTP (Simple Mail Transfer ProtoCol). Базира се на транспортен протокол TCP. От клиента, от порт с номер по-голям от 1024, се прави заявка за съединение към IP адреса на пощенския сървър на порт 25, т.е. порт 25 стои отворен в пощенския сървър и чака заявка за съединение. Ако сървърът е в състояние да получи заявката, отговаря с 220, което означава готов. След това клиентът изпраща съобщение HELLO, а при успех сървърът отговаря с 250. След това клиентът изпраща MAIL FROM (от кого е пощата), RCPT TO (кой е получателя) и накрая се прехвърля самото съобщение, след което връзката се разпада. Описаното си е едно TCP/IP съединение. В неговите рамки се обменят ASCII съобщения, които са с определена структура.


Пример на SMTP сесия

По-долу имате един типичен пример на изпращане на съобщение по SMTP до две пощенски кутии (alice и theboss) в един и същ домейн (example.com). “Репликите” на сървъра са означени със (S:), а на клиента - с (C:). След като изпращачът на съобщението (STMP Client) установи надежден канал получателя (SMTP server), сесията се отваря с поздравление от страна на сървъра. Клиентът започва диалог, отговаряйки с команда HELO, в която се идентифицира.


POP3

Крайният получател на писмото не е SMTP-сървъра. В него се събират изпратените писма до съответния домейн. Сървърът трупа тези писма на диск при себе си. С помощта на друг протокол крайният получател изтегля получените писма от пощенския сървър. Например, POP3 (Post OffiCe ProtoCol). При него сървърът слуша на порт 110. За разлика от SMTP, POP3 поддържа автентикация на клиента (username + password), т.е. притежателят на пощенската кутия е регистриран като POP3 потребител. Когато клиентът се свърже към POP3 сървъра, той първо се идентифицира, след което може да извърши други команди за прочитане на получените от него mail-ове.


IMAP

Internet Message ACCess ProtoCol (IMAP или IMAP4) “слуша” на порт 143 и е другата възможност крайният клиент да получи достъп до пощата си, стояща на отдалечен сървър. Сегашната версия, IMAP version 4 revision 1 (IMAP4rev1) е дефинирана в RFC 3501. IMAP поддържа и online, и offline режими. E-mail клиенти с IMAP оставят съобщенията на сървъра, докато потребителят не реши да ги изтрие. IMAP позволява повече от един клиент да има достъп до една и съща пощенска кутия. Т.е можете да имате достъп до пощата си едновременно от няколко места. За разлика от POP3, IMAP4 клиентите са свързани за сървъра, докато потребителският интерфейс е активен. Потребителите изтеглят съобщения на диска си само по желание. IMAP4 клиентите могат да създават, преименуват и/или изтриват пощенски кутии (потребителят ги вижда като папки) на сървъра и да местят съобщения между кутиите. POP3 и IMAP услуги предлагат Cyrus IMAP server (http://Cyrusimap.web.Cmu.edu/) и DoveCot (www.doveCot.org).


IMAP4 команди


Документация на mail решение

Системата работи в рамките на УИЦ на СУ, като върху нея се хостват няколко домейна. Sendmail за МТА Cyrus за MDA RedHat DireCtory Server за LDAP база за потребителски акаунти и конфигурация на sendmail phpLDAPadmin - за външно управление на LDAP директорията Saslauthd за посредник ежду Cyrus и LDAP базата Spamassassin за антиспам защита Clamav за антивирусна защита http://www.mimedefang.org/ за връзка на sendmail със антивирусната защита и за допълнителни филтри SquirrelMail и HastyMail за уеб достъп до пощенските кутии.


Пощенски концентратори

Пощенски концентратори (mail hubs) са SMTP сървъри. Замисълът на изграждането им е цялата

входяща електронна поща за пощенски домейни в мрежата на СУ, да преминава през тях.

Избягва се риск от пробив в сървъри за електронна поща, които не са обект на квалифицирана поддръжка и наблюдение (повечето факултетски сървъри за електронна поща).


Алгоритъм на MX йерархия вDNS.

MX йерархия, която обслужва схема на доставка на електронна поща чрез пощенските концентратори:

$ORIGIN domain.uni-sofia.bg. //MX 10 mail.faculty.uni-sofia.bg//MX 20 ns.uni-sofia.bg.//MX 20 ady.uni-sofia.bg.
MX йерархия

Съгласно тази MX йерархия при инциране на сесия за предаване на писмо към получател с пощенска кутия в домейна faculty.uni-sofia.bg: - опит да се установи SMTP сесия към mail.faculty.uni-sofia.bg. Ако този опит пропадне: - установяване на SMTP сесия към един от двата SMTP сървъра, с MX приоритет 20 (ns.uni-sofia.bg или ady.uni-sofia.bg).


Принцип на действие на схемата

Сървър от интернет изпраща електронно писмо до получател с кутия в пощенския домейн faculty.uni-sofia.bg. Изпращачът използва MX йерархията инеговият пощенски процес намира хоста с най-малък числов идентификатор, mail.faculty.uni-sofia.bg. Иницира се SMTP сесия от изпращача към mail.faculty.uni-sofia.bg.


Маршрутизатор пред сървъра faculty.uni-sofia.bg отхвърля пакета за инициране на SMTP сесията,като връща ICMP съобщение "ICMP port unreaChable" или "ICMP host unreaChable". След като изпращача получи това ICMP съобщение, избира в случаен ред един от двата пощенски концентратора (ns.uni-sofia.bg или ady.uni-sofia.bg) и отново ще иницира SMTP сесия към избрания концентратор. Концентраторът приема писмото и после го доставя до faculty.uni-sofia.bg.
SquirrelMail и Hastymail

squirrelmail.org е с вградена PHP поддръжка за IMAP и SMTP, страниците са чист HTML 4.0



(не е необходим JavaSCript) за съвместимост с всички браузъри. mailbox.uni-sofia.bg hastymail.org - IMAP/SMTP клиент, писан на PHP. Съвместим с PDAs, мобилни апарати, текстови и други браузъри.mailbox.uni-sofia.bg/mobile

Сподели с приятели:


©zdrasti.info 2017
отнасят до администрацията

    Начална страница