Тема 23.

Електронна поща в Интернет.

---

страницата се нуждае от дописване/преглеждане

---

Електронната поща, обикновено наричана просто e-mail / email / eMail е много стара концепция. Много. Първите системи за обмяна на съобщения между компютри са се появили не по-късно от 1966 година. Употребата на електронна поща в интернет е един от факторите за неговото развитие. E-mail системи са разработвани от организацията ISO, от комитета CCITT, от различни американски университети, и на други места. Поради това съществуват и множество стандарти - например CCITT X.400.

Поне една картинка имаше по темата. Някъде из архива е.

E-mail системата се основава на TCP/IP пакетна мрежа, но действа на принципа на комутацията на съобщения. Съобщенията се предават от субект на субект, като при приемане се съхраняват (буферират) и се препращат при първа възможност, докато не достигнат получателя. В интернет получателят се обозначава като niamodlevelpot.revresliam|xobliam#niamodlevelpot.revresliam|xobliam - например moc.liamg|repoocsmaps#moc.liamg|repoocsmaps. Доставянето е асинхронно - не е нужно адресатът да е онлайн, за да му бъде доставено съобщението.
Най-разпространената в момента форма на електронна поща се основава на протокола SMTP.

Структура на електронно съобщение

Едно e-mail съобщение се състои от плик (envelope), хедър и тяло на съобщението.

Плик (envelope)

Предназначението на плика е аналогично на това на плика в традиционната поща (напоследък често наричана snail mail): той съдържа минималното количество информация, необходимо на пощенските сървъри да доставят съобщението до получателя, а също и как да го третират по пътя. Някои от полетата, съдържащи се в плика, са:

• name
• address
• priority
• encryption

Пликът е дефиниран в RFC 821¹.

Хедър

Хедърът съдържа служебна информация за писмото. Той, както и тялото, са дефинирани в RFC 822.
Хедърът включва:

• To - E-mail адрес на първичен получател (recipient). При единствен получател, това е той.
• Cc - E-mail адрес на вторичен получател. Идва от carbon copy и е взето от дните, когато копия на писма са се правели с индигова хартия.
• Bcc - E-mail адрес на третичен получател. Идва от blind carbon copy. Теоретично, би трябвало получателите в Bcc: да получат копие от писмото, без тези в To: и Cc: да знаят това. На практика, това не се изисква по стандарт. Различните имплементации го обработват по различен начин.
• From - Името на лицето / програмата, автор на писмото.
• Sender - E-mail адрес на актуалния изпращач (адрес, от който всъщност е тръгнало писмото).
• Received - Едно или много такива полета, отразяващо движението на писмото през сървърите. Всеки запис указва една транзакция между MTA-та.
• Return-Path - Подобно на Received, съдържа информация за източника на съобщението и за обратния път до него².
• Date - Дата на изпращане на писмото.
• Reply-To - E-mail адрес, на който да се изпрати отговорът. Има смисъл, когато писмото не е дошло от автора - например, в пощенските списъци³.
• Message-Id - Уникален за изпращача идентификатор на съобщението.
• In-Reply-To - Идентификатор на съобщението, на което настоящето отговаря.
• Keywords - Ако присъства, съдържа ключови за писмото думи.
• Subject - Тема (предмет) на съобщението.
• X-<…> - Нестандартни хедъри, обикновено специфични за имплементацията. Някои от тях се използват много често и са de facto стандартни.

Списък на стандартизирани полета на хедъра / плика се намира тук.

Тяло

Тялото съдържа полезната информация на съобщението - текст и/или двоични данни.
Първоначално в тялото се е допускал само текст в ASCII. Поради недалновидност, обаче, е допусната височайша глупост: предвидено е да се използва ASCII-7 (първите 128 знака от ASCII таблицата, или нулевата страница). Това е било идеално за САЩ, но вгорчава живота на всички, които използват други символи. Години наред в държавите с друга азбука, например кирилица, съществуват проблеми с кодирането на символите, най-често поради съществуването на няколко различни схеми за борба със 7-битовото ASCII⁴, и разчитането на писмото често е въпрос на шанс - дали получателят ще приложи същата кодировка, каквато и подателят.

За борба със седемте бита са измислени много начини. Най-масовата схема прекодира ASCII-8 в двоичен код, който изпраща като ASCII-7, а клиентът го обръща отново в ASCII-8. Тя се реализира по няколко начина:

Base64 encoding

Текстът се разбива на части по 3 октета (24 бита), а те се делят на 4 групи по 6 бита, които могат да имат стойности между 0 и 63. След това групите се обръщат в ASCII-7:

Стойност	0	…	25	26	…	51	52	…	61	62	63
ASCII-7 символ	A	…	Z	a	…	z	0	…	9	+	/

Ако текстът не е достатъчно дълъг, първо се допълва със символи =.
Кодирането е икономично (около 25% надбавка).

Quoted-printable

Полезно за текст, съдържащ предимно ASCII-7 знаци. Те се запазват, а останалите се заместват с шестнайсетичната си стойност, предшествана от знак =, и цялото това се огражда в кавички. Например, главната кирилска буква А (ASCII 192 в Windows-1251) се кодира като "=C0".

Двоично кодиране - uuencoding

Наследство от Unix и неговите (стари) mail-системи. Кодира символите двоични числа, например в BCD (Binary Coded Decimal).

Все по-популярна става директната употреба на Unicode, без нужда от кодирания на символи.

MIME

Практиката с (пре)кодирането на информацията се оказва лоша - води до практическа неизползваемост на системата. Затова, след като електронната поща се разпространява извън САЩ, започват да се търсят други начини за представяне на съдържанието. В един хубав момент, в RFC 1341, допълнено от RFC 1521, и допълнено още безброй пъти, се появяват MIME (Multipurpose Internet Mail Extensions]. Това е разширение на e-mail стандарта, което описва вида на представяната в тялото информация. MIME има поне две много важни характеристики:

• Позволява пращане на съдържание, различно от обикновен текст - разнообразни двоични файлове, например.
• При текстово съдържание, указва начина на кодиране на символите.

Всъщност MIME е такава гъзария, че се възприема и от HTTP и WWW за указване на съдържанието⁵ .
MIME дефинира следните полета в хедъра:

• MIME-Version
• Content-Description - ASCII текст, описва съдържанието.
• Content-ID - подобно на Message-Id
• Content-Transfer-Encoding - Основно се ползват ASCII-7, ASCII-8, Base64, Quoted Printable, UU. Ползват се и други.
• Content-Type - Тип на съдържанието. Доста пълен списък има тук. Най-разпространени (дадените стойности са малка част от възможния набор):
  • text - plain, richtext (например, .rtf - Rich Text Format; позволява неща като bold, underline, italic)
  • image - gif, jpeg
  • audio - basic
  • application - octet-stream, postscript
  • message - rfc822, partial (тялото съдържа част от съобщението) / external-body (тялото се предава отделно)
  • multipart
• И други.

Компоненти на e-mail системата

Първите системи, разглеждани в RFC 822, са свързани чрез малки, прости мрежи, в които работят специализирани, скъпи компютри, които непрекъснато са онлайн. Затова при тях съобщенията се доставят от краен потребител до краен потребител, директно от SMTP. Сега ситуацията е по-различна. Комуникацията се осъществява по модела клиент - сървър. Според функциите си се открояват няколко вида субекти: MUA (Mail User Agent), MTA (Mail Transfer Agent), MDA (Mail Delivery Agent), MSA (Mail Submission Agent), описани в RFC 5068. Най-важните са MTA и MUA.

• MUA - Работи при крайния потребител (изпращач / получател). Създава и съобщения и ги изпраща към e-mail структурата. Получава от нея съобщения и ги предоставя на потребителя. Почти синоним на e-mail клиент. Най-често ползва протоколи като POP версия 3, работещ по подразбиране на порт 25, и IMAP, работещ по подразбиране на порт 143. Чрез тези двата протокола се реализира взаимодействието сървър -> клиент⁶.
• MTA - Основна част от SMTP, работи на e-mail сървърите. Грижи се за получаването, съхраняването, обработката и препращането на e-mail съобщения. Като негови подфункции могат да се обособят MSA и MDA. Реализира взаимодейстията клиент -> сървър и сървър -> сървър.

Обикновено процесът на изпращане и получаване на електронна поща протича така: MUA изпраща написаното от потребителя съобщение до своя пощенски сървър. Там съобщението се поема от MTA и се съхранява. Ако адресатът се обслужва от същия сървър, съобщението се съхранява в неговата пощенска кутия (mailbox) - структура, намираща се на сървъра, или директно - на потребителския компютър. Ако не, то съобщението се препраща, директно или през други сървъри (MTA-та), до пощенския сървър на клиента, където се съхранява в кутията му. E-mail системата не работи в реално време. По пътя си съобщението се съхранява от MTA-тата, в случай, че то не може да бъде препратено на момента, и се предава, когато това стане възможно. Затова изпратеното съобщение може да бъде получено моментално, а може да се забави няколко минути, а даже и няколко часа.⁷

Работа на SMTP

SMTP работи в следната последователност:

1. Създава TCP съединение с по-голям от 1023 source port и destination port 25. Извършва DNS resolving на домейна на получателя, получава от неговия DNS сървър IP адреса на пощенския сървър, който обслужва клиента, и използва това IP за сокета (който не помни: ipaddress:port). При успешно установяване, SMTP сървърът отговаря с 220 READY. (кодовете на командите са подобни, ако не същите, на тези при FTP).
2. Клиентът праща HELO hostname, къдетоhostname е FQDN на клиента. Сървърът отговаря с 250 OK.
3. Клиентът праща MAIL FROM: address, където address е e-mail адрес на изпращача, стойността на reply-to полето от хедъра. 250 OK.
4. Клиентът праща RCPT TO: address | списък от адреси на един и същи сървър. 250 OK.
5. Клиентът праща DATA. 250 OK.
6. Следва самото съобщение. Кодировката му се описва в хедъра. Краят на съобщението се обозначава с два нови реда, обозначени с <CR><LF><CR><LF>⁸.
7. Клиентът затваря сесията с QUIT. Сървърът отговаря с 221 CLOSING.

И малко за POP3

Post Office Protocol, версия 3. Използва се за достъп до съобщенията в пощенската кутия. Подобен на SMTP откъм команди. Най-голямата разлика е възможността за удостоверение (authentication) - чрез парола се контролира достъпът до пощенската кутия.

При POP3 процесът на четене протича така:

1. Клиентът установява връзка към пощенския сървър по порт 110. Сървърът отговаря с OK.
2. Клиентът праща потребителското си име и парола. Сървърът ги утвърждава с OK (или не ги утвърждава с ERR). Данните се предават в явен вид. Има възможност за криптиране / хеширане, но обикновено не се имплементира.
3. Клиентът подава команда. Сървърът я изпълнява и връща OK.
4. Клиентът подава QUIT за край на ссесията.

Някои POP3 съобщения (команди):

• USER
• PASS
• QUIT
• STAT - връща броя на съобщенията в кутията
• LIST - връща списък на писмата
• TOP <message> n - първи n реда от съобщението <message>

Още по въпроса

Introduction to email
Различаване на spam-хедъри

Footnotes

1. Трудно се прави разграничение между envelope и header. И, като цяло, e-mail стандартите не са много очевидни и, много или малко, подлежат на свободна интерпретация. В RFC 821, например, никъде не се споменава думата envelope - срещнах я чак в съпътстващото го RFC 822 и в изместващото го 2821.

2. Не знам каква е разликата.

3. Пример: Google Groups, Linux.

4. Ако съм запомнил правилно, дълго време Outlook Express е използвал по подразбиране руската KOI8-R вместо CP-855 или Windows-1251 за ново писмо, което е водело до невъзможност за разчитане на изпратените имейли. Вследствие на това, доста потребители се научили да пишат писма на латиница.

5. Някои Apache сървъри бяха настроени по подразбиране да пращат съдържанието в text/plain. Познайте какво става, когато тръгне човек да тегли, да речем, 300 MB .rar файл.

6. При webmail, като Gmail и Yahoo, съдържанието се получава чрез HTTP. POP и IMAP се ползват от пощенски клиенти като Outllook, Thunderbird, Eudora.

7. Ако някой от пощенските сървъри на ФМИ е пропаднал, например, може да се наложи да се изчака ден-два.

8. Доколкото помня, нужно е да се пратят и двата знака - <CR> (carriage return, ASCII 13) и <LF> (line feed, ASCII 10) - два пъти подред.