SMTP

SMTP (Simple Mail Transfer Protocol) е интернет стандарт за пренос на електронна поща.

SMTP протоколът се използва от повечето имейл системи, които изпращат поща. Писмата след това могат да се изтеглят с POP3 или IMAP от локален клиент или програма.

SMTP комуникацията между имейл сървъри се осъществява през TCP порт 25. Имейл клиентите, от друга страна, често изпращат имейлите до имейл сървъра през порт 587.

Широко разпространение е получил в началото на 80-те години на 20 век. Преди това е бил използван Unix to Unix Copy Program протоколът, който изисква от изпращача пълен маршрут до получателя или постоянно съединение между компютрите на изпращача и получателя. SMTP протоколът е създаден да бъде еднакво полезен на който и да е компютър и потребител.

SMTP дизайнът изглежда така:

                  ┌──────────┐                ┌──────────┐
 ┌───────────┐    │          │                │          │
 │Потребител │<──>│          │      SMTP      │          │
 └───────────┘    │  Клиент  │команди/отговори│  Сървър  │
   ┌───────┐      │   SMTP   │<──────────────>│   SMTP   │    ┌───────┐
   │Файлова│<────>│          │     и поща     │          │<──>│Файлова│
   │система│      │          │                │          │    │система│
   └───────┘      └──────────┘                └──────────┘    └───────┘
                  SMTP клиент                 SMTP сървър

История

Най-различни форми на електронни съобщения от типа „равен към равен“ (на английски: peer-to-peer) са използвани през 60-те години на 20 век. Колкото повече ставали свързани компютрите помежду си, особено в правителствената мрежа ARPANET, били разработени стандарти за да могат потребителите на различни системи да комуникират. SMTP се появил измежду тези стандарти през 70-те години.

Корените на SMTP могат да бъдат проследени до две нововъведения от 1971: протокола Mail Box, чието вграждане е обсъдено в RFC 196, и програмата SNDMSG, която според RFC 2235 Рей Томлинсън от BBN изобретил за TENEX компютрите, така че да изпращат пощенски съобщения в ARPANET мрежата.^[1]^[2]^[3] По-малко от 50 хоста били свързани към ARPANET по това време.^[4]

Последващите вариации включват FTP Mail^[5] и Mail Protocol, и двете от 1973.^[6] Разработването продължило през 70-те, докато ARPANET се превърнала в съвременния интернет около 1980 г. След това Джон Пъстел предложил Mail Transfer Protocol през 1980 г., който премахнал зависимостта на пощенските съобщения от FTP.^[7] SMTP е публикуван като RFC 788 през ноември 1981 г., отново от Пъстел.

SMTP стандартът е разработен по почти същото време като Usenet, комуникационна мрежа от типа „един към няколко“ с известни прилики.

SMTP става широко разпространен в началото на 80-те. По това време той е включен в Unix to Unix Copy Program (UUCP) пощата, която се справя по-добре с управлението на имейл трансферите между взаимносвързани машини. SMTP, от друга страна, работи най-добре, когато и подателят, и получателят са свързани към мрежата през цялото време. И двете използват механизми за съхраняване и препращане на информацията и представляват добри примери на push технологията. Въпреки че нюзгрупите на Usenet все още са включени в UUCP сървърите,^[8] UUCP пощата практически е изчезнала^[9].

Излязла в 4.1cBSD, точно след RFC 788, Sendmail е една от първите (ако не и първата) програми за трансфер на имейл, която включва SMTP.^[10] През времето, докато BSD Unix става най-популярната операционна система в интернет, sendmail става най-разпространеният пощенски клиент.^[11] Други популярни SMTP програми включват Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, Sun Java System Messaging Server.

Изпращането на съобщения (RFC 2476) и SMTP-AUTH (RFC 2554) са представени през 1998 и 1999, описвайки нови тенденции в изпращането на имейл. Първоначално SMTP сървърите били вътрешни за организация, получавайки пощата на организацията отвън, и насочвали съобщенията от организацията навън. Но с течение на времето SMTP сървърите (имейл клиентите) на практика разширили своята роля, така че вече да насочват поща извън самата организация (например директор в компанията желае да изпрати имейл, докато е на пътуване, използвайки фирмения SMTP сървър). Този проблем, вследствие на бързото разрастване и популярността на световната мрежа, означавал, че SMTP трябва да включва определени правила и методи за предаването на пощата и разпознаването (оторизирането) на потребителите, за да предотврати злоупотреби като разпространението на нежелана електронна поща (спам). Започнала работа по стандарт (RFC 2476) за допълване на грешни или непълни адреси, защото пощенските сървъри често се налагало да преработват имейл съобщение с липсващо домейн име на имейл адрес например. Това поведение е полезно, когато съобщението се редактира при източника му, но опасно, когато съобщението произлиза от другаде и само се препредава. Явно единственият начин да се разреши редактирането на съобщения е пощата да се раздели на такава, която произлиза от сървъра, и такава, която се препредава от него. Това разделяне на изпращане и препредаване на пощата бързо станало основата на модерната практика за сигурност на електронната поща.

Този протокол започнал като базиран на ASCII текст и не се налагало да работи с двоични файлове или със символи извън тези от английската азбука. Били разработени стандарти като Multipurpose Internet Mail Extensions (MIME), за да бъдат кодирани двоични файлове така, че да бъдат трансферирани чрез SMTP. „Моджибейк“ (Mojibake) все още бил проблем поради различните кодирания на символите от различни доставчици, въпреки че имейл адресите можело да бъдат само в ASCII код. SMTPUTF8 разширението беше създадено, за да позволи поддръжката на UTF-8 текст, като по този начин станало възможно използването на международно съдържание и адреси, различни от тези на латински символи като кирилицата и китайския.

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

Модел за изпращане на писма

Сините стрелки могат да бъдат различни SMTP вариации.

Електронното писмо се предава от имейл клиент (mail user agent) до пощенския сървър (на английски: mail submission agent), използвайки SMTP върху TCP. Повечето доставчици на поща все още дават възможност за ползване на традиционния порт 25. Оттам MSA доставя поща на негов представител (на английски: mail transfer agent). Често тези два агента са само различни копия на един и същ софтуер, стартиран с различни опции на една и съща машина. Локално обработка може да се направи или на една машина, или разделени между различни машини. MTA, за да локализира хоста, използва DNS (Domain name system), за да се запознае с домейна на получателя (частта от адреса отдясно на @). Върнатият запис съдържа името на хоста. MTA след това се свързва с обменния сървър като SMTP клиент. След като MX приема входящо съобщение, той го праща на агента за доставка на поща на английски: mail delivery agent за локална доставка на пощата. MDA запазва съобщението в подходящ формат. Отново съобщението може да бъде получено чрез няколко компютъра или само чрез един. В дадения случай са ползвани два (MX и MDA). Веднъж получено съобщението в локалния сървър, то е съхранено за групиране и изпращане към заверени имейл клиенти. Съобщението се получава от потребителска програма, наречена „имейл клиент“, използващ IMAP (Internet Message Access Protocol) или POP (Post Office Protocol), който улеснява достъпа до пощата и управлява съхраняването на писма.

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

В примера по-долу е показан типичен пример за изпращане на съобщение през SMTP до две пощенски кутии (peter и maria), които се намират в един и същи мейл домейн (mymail.com). Със Server и Client са обозначени съответно мейл сървърът и клиентът, като тези имена не са част от кореспонденцията, а само илюстрират кои от обменените съобщения са респективно от сървъра или клиента.

Когато изпращачът на съобщението (SMTP клиентът) осъществи комуникационен канал с получателя (SMTP сървъра), сървърът отваря сесия, като изпраща своето пълно име на домейн, в случая smtp.mymail.com. Клиентът започва диалога, като отговаря с командата HELLO и своето пълно име на домейн (или когато такова липсва, с адреса си).

Server: 220 smtp.mymail.com ESMTP Postfix Client: HELO relay.mymail.com Server: 250 Hello relay.mymail.com, I am glad to meet you Client: MAIL FROM:<ivo@mymail.com> Server: 250 Ok Client: RCPT TO:<peter@mymail.com> Server: 250 Ok Client: RCPT TO:<maria@mymail.com> Server: 250 Ok Client: DATA Server: 354 End data with <CR><LF>.<CR><LF> Client: From: "Иво" <ivo@mymail.com> Client: To: "Петър" <peter@mymail.com> Client: Cc: maria@mymail.com Client: Date: 20 август 2013 г. 14:00:10 -0500 Client: Subject: Тестово съобщение Client: Client: Здравей Петър. Client: Това е тестови имейл. Client: Поздрави, Client: Иво Client:. Server: 250 Ok: queued as 12345 Client: QUIT Server: 221 Bye

Клиентът уведомява получателя за изпращача на имейла чрез MAIL FROM команда. В този пример имейл съобщението е изпратено до два адреса на един и същи SMTP сървър: един в полето To и един в полето Cc. Съответната SMTP команда е RCPT TO. Всяко успешно получаване и изпълнение на команда се потвърждава от сървъра чрез код на резултата и съобщение за отговор (например: 250 Ok).

Прехвърлянето на тялото на съобщението започва с командата DATA, след което се изпраща ред по ред и завършва с комбинация за край на информацията. Тази комбинация се състои от нов ред (<CR><LF>), една точка (.), последвана от нов ред. Поради това, че е възможно да има съобщение само с точка (.) в съдържанието си, клиентът изпраща две точки (..) всеки път, когато един ред започва с точка; съответно сървърът заменя всяка последователност от две точки в началото на реда с единична такава. Този метод се нарича „запълване с точки“ (на английски: dot-stuffing).

Положителният отговор на сървъра на комбинацията за край на информация означава, че сървърът поема отговорност за доставяне на съобщението. Възможно е да се получи дублиране на съобщението, ако възникне грешка при комуникацията на този етап, например при загуба на захранване: Докато изпращачът не получи отговор 250, той предполага, че съобщението не е доставено. От друга страна, след като получателят е решил да приеме съобщението, трябва да предположи, че му е доставено, и да увери изпращача. Тоест през този интервал от време и двете страни имат активно копие на съобщението, което ще се опитат да доставят. Вероятността да се появи проблем в комуникацията на точно този етап е правопропорционална на количеството филтриране, което извършва сървърът на съдържанието с цел превенция на спама. Времето за изчакване в този случай е фиксирано на 10 минути.

Командата QUIT прекратява сесията. Ако имейлът има получатели, които се намират другаде, клиентът ще изпълни QUIT и ще се свърже към съответен SMTP сървър за последващи получатели, след като текущата е изпълнена. Информацията, която клиентът изпраща в командата HELO и MAIL FROM се добавя (не в примера по-горе) като допълнение в заглавните полета на съобщението. Добавят се и полетата „получено“ и „път за връщане“.

SMTP протокол

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

Команди при изпращане

HELO – Обозначава началото на комуникацията с пощенския сървър. Може да съдържа и домейн име, така че пощенският сървър да получи веднага тази информация.
MAIL – Показва кой е подателят. Например: MAIL FROM: <ivan@stoyanov.com>. Важно е да се отбележи, че на този имейл адрес ще се върне отговорът, ако доставянето е неуспешно.
RCPT – Показва кой е получателят. Например: RCPT TO: <petar@georgiev.com>. Възможно е да посочите повече от един получател, като изпратите няколко RCPT команди.
DATA – Информира, че ще изпратите текста или тялото на съобщението. Съобщението трябва да завърши със следната комбинация: \r\n.\r\n.
QUIT – Маркира края на комуникацията по изпращането.
EXPN – Показва, че се използва списък за изпращане.
SEND – Изпраща съобщение до терминала на потребителя, вместо до пощенската му кутия.
VRFY – Проверява наличието на такъв получател за този адрес. Тази команда не е вградена във всички пощенски сървъри и може да бъде блокирана от защитни стени.
Всяка команда ще получи отговор във вид на 3 цифрено число, последвано от кратко текстово описание на отговора.

Например: 250 OK

Команди за отговор

211 – Състояние на сървъра.
220 – Сървърът е в готовност.
221 – Приключване на комуникацията от сървъра.
250 – Операцията е изпълнена успешно.
251 – Посоченият потребител или адрес не се намира на този сървър, но той ще предаде съобщението.
354 – Това е отговорът на пощенския сървър на командата DATA. Изчаква, докато не получи следната комбинация: \r\n.\r\n.
421 – Пощенският сървър ще бъде спрян, запазете съобщението и опитайте отново по-късно.
450 – Пощенската кутия е заета, изчакайте и опитайте отново.
452 – Командата не беше изпълнена поради недостатъчно пространство за съхранение.
500 – Последната команда съдържа синтактична грешка или е твърде дълга.
502 – Пощенският сървър не поддържа тази команда.
550 – Пощенската кутия не може да бъда намерена или нямате съответни права за достъп.
552 – Пощенската кутия на получателя няма достатъчно пространство за да бъде доставено съобщението ви. Запазете съобщението и опитайте отново по-късно.
554 – Доставянето на съобщението е неуспешно по неизвестна причина.
Тези трицифрени числа и краткото им текстово описание най-често са включени в отчета, който пощенският сървър изпраща на подателя при неуспешно доставяне на имейл съобщението.

Сигурност и спам

Първоначалната SMTP спецификация не включва метод за автентикация на подателя. Впоследствие SMTP-AUTH разширението е определено в RFC 2554.^[12] ESMTP предоставя механизъм за имейл клиентите да определят метода на защита към пощенския сървър, да оторизират размяната и да определят профил на защита (Simple Authentication and Security Layer, SASL) за последваща обмяна на съобщения. Продуктите на Microsoft имат вграден собствен Secure Password Authentication (SPA) протокол чрез SMTP-AUTH разширението. Масовото използване на SMTP-AUTH обаче означава, че той не може да се справи със спам заплахите.

Голямата промяна на SMTP или пълното му премахване не е практично поради големия брой инсталации на SMTP и ефекта им върху мрежата.

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

Вижте също

Източници

↑ The First Network Email, Ray Tomlinson, BBN
↑ Picture of "The First Email Computer Архив на оригинала от 2010-08-24 в Wayback Machine." by Dan Murphy, a PDP-10
↑ Dan Murphy's TENEX and TOPS-20 Papers
↑ RFC 2235
↑ RFC 469 – Network Mail Meeting Summary
↑ RFC 524 – A Proposed Mail Protocol
↑ RFC 772 – Mail Transfer Protocol
↑ Tldp.org
↑ draft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project
↑ Eric Allman. Sendmail – An Internetwork Mail Router. University of California, 1983. Посетен на 29 юни 2012.
↑ Craig Partridge. The Technical Development of Internet Email. IEEE Computer Society, 2008. DOI:10.1109/MAHC.2008.32. Архив на оригинала от 2011-05-12 в Wayback Machine.
↑ RFC 2554, SMTP Service Extension for Authentication, J. Myers (March 1999)

Литература

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.

[1] The First Network Email, Ray Tomlinson, BBN

[2] Picture of "The First Email Computer Архив на оригинала от 2010-08-24 в Wayback Machine." by Dan Murphy, a PDP-10

[3] Dan Murphy's TENEX and TOPS-20 Papers

[4] RFC 2235

[5] RFC 469 – Network Mail Meeting Summary

[6] RFC 524 – A Proposed Mail Protocol

[7] RFC 772 – Mail Transfer Protocol

[8] Tldp.org

[9] raft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project

[10] Eric Allman. Sendmail – An Internetwork Mail Router. University of California, 1983. Посетен на 29 юни 2012.

[11] Craig Partridge. The Technical Development of Internet Email. IEEE Computer Society, 2008. DOI:10.1109/MAHC.2008.32. Архив на оригинала от 2011-05-12 в Wayback Machine.

[12] RFC 2554, SMTP Service Extension for Authentication, J. Myers (March 1999)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]