SMTP

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене

SMTP (Simple Mail Transfer Protocol) е Интернет стандарт host-to-host имейл транспортен протокол и традиционно оперира с TCP порт 25. SMTP протокола се използва от повечето имейл системи, който изпращат поща. Писмата след това могат да се изтеглят с POP3 или IMAP от локален клиент или програма. Широко разпространение е получил в началото на 80-те години (1980). Преди това е бил използван (Unix to Unix Copy Program) протокола, който изисква от изпращача пълен маршрут до получателя или постоянно съединение между компютрите на изпращача и получателя. SMTP протокола е създаден да бъде еднакво полезен на който и да е компютър и потребител.

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

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

История[редактиране | edit source]

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

Корените на SMTP могат да бъдат проследени до две нововъведения от 1971: протокола Mail Box, чието вграждане е обсъдено в RFC 196, и програмата SNDMSG, която, според RFC 2235, Ray Tomlinson от 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 става най-разпространение пощенски клиент (MTA (mail transfer agent)).[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 спецификации, сред които Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, и Keith Moore.

Модел за изпращане на писма[редактиране | edit source]

Сините стрелки могат да бъдат различни 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), който така улеснява достъпа до пощата и управлява съхраняват поща. Вместо IMAP също така може да се ползва и POP (Post Office Protocol).

Примерна SMTP сесия[редактиране | edit source]

В примера по долу е показан, типичен пример за изпращане на съобщение през 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 протокол[редактиране | edit source]

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

Команди при изпращане[редактиране | edit source]

  • 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

Команди за отговор[редактиране | edit source]

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

Сигурност и СПАМ[редактиране | edit source]

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

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

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

Виж също[редактиране | edit source]

Източници[редактиране | edit source]

  1. The First Network Email, Ray Tomlinson, BBN
  2. Picture of "The First Email Computer" 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. draft-barber-uucp-project-conclusion-05 - The Conclusion of the UUCP Mapping Project
  10. Eric Allman (1983), „Sendmail — An Internetwork Mail Router“, BSD UNIX documentation set, Berkeley: University of California, http://docs.freebsd.org/44doc/smm/09.sendmail/paper.pdf, посетен 29 June 2012 
  11. Craig Partridge (2008), „The Technical Development of Internet Email“, IEEE Annals of the History of Computing, IEEE Computer Society, doi:10.1109/MAHC.2008.32, http://www.ir.bbn.com/~craig/email.pdf 
  12. RFC 2554, SMTP Service Extension for Authentication, J. Myers (March 1999)

Литература[редактиране | edit source]

  • 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.