Бележки
Първи
впечатления
IP адресиране
Рутиране
OSI
моделът
Подмрежи
IP
адреси и FQDN
Автоматично
конфигуриране
WINS и
NETBIOS имена
Примери
SMTP
Ftp,
telnet и други
Още
от командния ред
Линкове
Списък
на RFC-та
Дефиниции
Текуща страница: Примери>SMTP
Имате поща!
Естествено, за да получите писмо някой трябва да го напише и след това да знае как да Ви го изпрати. Всъщност, стига му да знае само e-mail адреса Ви, този който се грижи за изпращането се нарича SMTP (Simple Mail Transfer Protocol) и е описан основно в RFC 821.
Нека сега предположим, че аз (mareq@somedomain.com) се опитвам да пиша писмо на някой приятел (да го наречем user@otherdomain.com). Първото нещо, което си струва да се отбележи, е че и двата адреса са от вида потребител@компютър. Това е най-често срещаната форма на e-mail адресирането, макар че е напълно възможно да изпратите писмо на голяма група хора, както често правят фирми с рекламна цел. Ето го сега и примерното ми съобщение:
Date: Tue, 18 Apr 2000 15:12:46 EDT
From: mareq@somedomain.com
To: user@otherdomain.com
Subject: мач
Айде да гледаме мач следобед.
Бирата е от мен!
След като натисна бутона “Send“ SMTP влиза в действие. Моят компютър, да го наречем “изпращач“, или за по кратко И, се свързва с “получателя“ - П, който най вероятно е някакъв “mail server“. След като двете PC-та установят връзка, между тях се провежда диалог, в който И предава информацията на П. Репликите в този диалог са близки до човешкия разговор и са дефинирани прецизно от SMTP. По-долу ще видите само най-типичната и най-проста форма на комуникация между двата компютъра, като други примери може да намерите към края на RFC 821.
П: 220 OTHERDOMAIN.COM SMTP Service at 18 Apr 2000 15:17:18
EDT Ако сте проследили внимателно разговора, то сигурно сте
разбрали, че писмото ми е благополучно получено. Компютърът, който се
грижи за изпращането разполага с ограничен брой команди (като HELO - за
първоначална връзка с mail server-а, RCPT - за уточняване на получателя,
DATA - за предаването на самия текст на писмото). Сървърът, който приема
информацията има по-широк кръг от команди, като всяка от тях се състои
от цифрова и текстова част. Цифровата част се използва от самите компютри,
а текста след нея е за улеснение на потребителя. Това е типично за повечето
интернет протоколи и позволява бързо да се ориентирате в обстановката,
ако нещо не е наред. Ако вашата програма записва всеки “разговор“
в log файл, то Вие ще можете лесно да разберете какво точно се е объркало.
Трицифрените кодове, които връща сървърът всъщност не са
чак толкова сложни за запомняне, защото са доста логични. Отговор, започващ
с цифрата 2 указва, че всичко е наред, 3-ката означава, че получателят
е в процес на изчакване на допълнителна информация. Ако видите 4-ка на
първа позиция, то на лице е временна грешка (например, сървъра в момента
е зает) и e-mail-ът ще бъде изпратен по-късно. Непоправими грешки, като
неверен получател, се отбелязват с 5-ца и в такъв случай най-вероятно
писмото ще Ви бъде върнато.
Освен тази размяна на реплики между двата компютъра, SMPT
дефинира и начина, по-който трябва да изглежда написания от Вас e-mail
(по-подробно - в RFC 821 и RFC
822). Hапример, да пишете в прост текст (ASCII),
да не въвеждате редoве с повече от сто символа, или пък username-а в адреса,
на който пращате да не бъде по-дълъг от 64 символа. За щастие, за повечето
от тези неща се грижи програмата, в която оформяте съобщението си (Netscape
Messenger, Eudora..) Хубавото на повечето Интернет
стандарти е, че независимо дали имате, или нямате представа от тях, на
други им се налага да ги спазват.
Начало на страницата | The
Lair | E-mail | Информация
| US
И: HELO OTHERDOMAIN.COM
П: 250 OTHERDOMAIN.COM - Hello, SOMEDOMAIN.COM
И: MAIL From: <mareq@somedomain.com>
П: 250 MAIL accepted
И: RCPT To: <user@otherdomain.com>
П: 250 Recipient accepted
И: DATA
П: 354 Start mail input; end with
И: Date: Tue, 18 Apr 2000 15:12:46 EDT
И: From: mareq@somedomain.com
И: To: user@otherdomain.com
И: Subject: мач
И: Айде да гледаме мач следобед.
И: Бирата е от мен!
И: .
П: 250 OK
И: QUIT
П: 221 OTHERDOMAIN.COM Service closing transmission channel
Българска версия • Последно обновяване: 20.04.2000 • ©2000 Николай Мареков