SMTP(Simpleng Mail Transfer Protocol- simpleng mail transfer protocol) ay protocol ng network, inilaan para sa paghahatid email sa mga TCP/IP network. ESMTP(English Extended SMTP) - isang scalable na extension ng SMTP protocol. Sa kasalukuyan, ang "SMTP protocol" ay karaniwang tumutukoy sa ESMTP at sa mga extension nito. Gumagamit ang SMTP ng TCP Ports 25.
Gumagamit ang SMTP protocol ng mga simpleng ASCII text command at nagbabalik ng tatlong character na naka-encode na mga tugon gamit ang mga text message. Ang SMTP protocol ay inilarawan sa Internet Request For Comment (RFC) number 821, na binuo ng Internet Engineering Task Force (IETF) at inilathala noong Agosto 21, 1982. Simula noon, sumailalim ito sa ilang mga pagbabago, ngunit sa pangkalahatan ang mga pangunahing utos ng protocol ay hindi nagbago.
Mga Pangunahing Utos ng SMTP Client
Koponan ng HELO
Sa pamamagitan ng kahulugan, ang mga command ng SMTP protocol ay apat na character ang haba. Ang pagbati na ipinadala ng kliyente sa server ay ang HELO command. Ang format ng command ay ang mga sumusunod:
HELO domain name
Ang layunin ng HELO command ay upang ipakita ang kliyente sa SMTP server. Sa kasamaang palad, ang paraan ng pag-access na ito ay binuo sa paunang yugto ng pag-unlad ng Internet, kapag walang napakaraming mga pagtatangka ng hindi awtorisadong pagpasok sa Internet. mga sistema ng kompyuter. Tulad ng nakikita mo, maaaring tawagin ng kliyente ang sarili nito sa anumang pangalan sa command line. Ito ay humantong sa katotohanan na sa kasalukuyan karamihan sa mga SMTP server ay gumagamit ng utos na ito nang pormal. Kung talagang sinubukan nilang kilalanin ang kliyente, pagkatapos ay isang mekanismo ang isinaaktibo baligtad na conversion DNS para sa layunin ng pagtukoy sa aktwal na pangalan ng host ng kliyente ayon sa sistema ng domain name batay sa IP address nito. Karaniwan, para sa mga kadahilanang pangseguridad, tatanggihan ng mga SMTP server ang mga koneksyon sa mga host na ang IP address ay hindi nareresolba sa isang kaukulang hostname. Nagpapadala utos na ito
Kapag nagtatrabaho sa SMTP protocol, dapat mong makilala ang pagitan ng mga SMTP client. Ang mga gumagamit ng kliyente at mga host ng kliyente ay hindi pareho. Kapag gumagawa ng isang mensaheng email, ang gumagamit ng sistema ng email ay isa ring kliyente ng kanyang lokal na host. Kapag naipadala na ang mensaheng mail, hindi na ito kliyente ng proseso ng SMTP. Ngayon, pinangangasiwaan ng kanyang lokal na host computer ang proseso ng paghahatid ng mensahe at nagsisilbing SMTP client mismo. Kapag kumonekta ang localhost sa malayong host upang magpadala ng mensahe gamit ang SMTP protocol, ito ay gumaganap bilang isang kliyente ng proseso ng SMTP. Ang HELO command ay nag-a-advertise ng lokal na pangalan ng host bilang kliyente, hindi tunay na gumagamit
na nagpadala ng mensahe. Kadalasan ang mga konseptong ito ay nalilito, na nagpapahirap sa paglutas ng mga problema na lumitaw sa mga sistema ng email.
utos ng AUTH
Ang pagpapalawak ng isang pag-uusap sa SMTP gamit ang AUTH command ay inilarawan sa RFC 4954.
PLAIN (Gumagamit ng Base64 encoding.)
LOGIN (Gumagamit ng Base64 encoding.)
GSSAPI (Generic Security Services Application Program Interface)
DIGEST-MD5 (Pagpapatunay sa pag-access sa Digest)
Ang pagkakaiba lamang sa pagitan ng PLAIN at LOGIN ay na sa unang opsyon ang login + password ay ipinadala sa isang linya, at sa pangalawang opsyon - una ang pag-login, pagkatapos ay ang password. Ngunit lahat ng mga ito ay kinakailangang naka-encode sa Base64.
MAIL command
Ang MAIL command ay ginagamit upang magtatag ng isang email session sa server pagkatapos maipadala ang HELO command. Ipinapahiwatig nito kung kanino nanggagaling ang mensahe. Ang format ng utos ng MAIL ay ang mga sumusunod:
MAIL reverse-path
Ang argumento ng reverse-path ay hindi lamang tumutukoy sa nagpadala ng mensahe, ngunit tumutukoy din ng ruta kung saan maibabalik ang mensahe kung hindi ito maihatid. Kung ang nagpadala ay ang user sa computer ng kliyente na nagpasimula ng SMTP session, ang format ng command ay magiging tulad ng sumusunod: MAIL MULA SA:
[email protected] Tandaan na ang FROM field ay tumutukoy sa email address ng nagpadala ng mensahe, kasama ang buong pangalan
Koponan ng RCPT
Tinutukoy ng RCPT command ang mga tatanggap ng isang mensahe. Maaaring makatanggap ng parehong mensahe ang maraming user. Karaniwan, ang bawat tatanggap ay tinukoy sa isang hiwalay na linya na may utos ng RCPT. Ang RCPT command format ay ang mga sumusunod:
Pasulong na landas ng RCPT
Tinutukoy ng argumento ng forward-path kung saan ipinapasa ang email. Karaniwang isasama nito ang buong email address, ngunit maaari ring isama ang lokal na SMTP server username. Isaalang-alang halimbawa ang sumusunod na utos:
RCPT TO: haley
Ang utos na ito ay tumutukoy na ang mensahe ay dapat ipadala sa user haley sa SMTP server na nagpoproseso ng mga mensahe. Sa parehong paraan, maaari kang magpadala ng mga mensahe sa mga gumagamit ng iba pang mga computer na hindi gumagamit ng SMTP server kung saan ipinadala ang mensahe. Isaalang-alang, halimbawa, ang sumusunod na utos:
RCPT SA: MAIL MULA SA:
Pinipilit ng isang command na ipinadala sa isang SMTP server na pinangalanang shardrach.smallorg.org ang server na magpasya kung ihahatid ang mensahe. Dahil ang user ay hindi nakarehistro sa lokal na shardrach server, ang server ay kailangang matukoy kung ano ang susunod na gagawin sa mensahe. Sa kasong ito, mayroong tatlong posibleng pagkilos para sa shardrach host. Tingnan natin ang mga ito nang mas malapitan.
Maaaring ipasa ng shardrach host ang mensahe sa tatanggap at ibalik ang isang positibong tugon sa nagpadala (OK). Sa kasong ito, idinagdag niya ang kanyang pangalan sa field
Hindi maipasa ng host shardrach ang mensahe at inaabisuhan ang nagpadala, habang kinukumpirma na tama ang address ng host na meshach.smallorg.org. Kaya maaaring subukan ng nagpadala na muling ipadala ang mensahe nang direkta sa meshach.smallorg.org.
Hindi maipapasa ng host shardrach ang mensahe at nagpapadala ng abiso na hindi maisagawa ang operasyong ito sa server na ito. Pagkatapos ang mga dahilan para sa kung ano ang nangyari ay dapat na pag-aralan ng system administrator.
Sa mga unang araw ng Internet, ang mga mensaheng email ay ipinadala nang walang taros sa pagitan ng mga computer sa buong mundo gamit ang orihinal na algorithm ng paghahatid. mga mensaheng mail.
DATA command
Ang command na ito ay ang pangunahing isa sa SMTP protocol. Pagkatapos iproseso ang MAIL at RCPT command, ang DATA command ay ginagamit upang ipadala ang impormasyong bahagi ng mensahe. Ang format ng utos ng DATA ay ang mga sumusunod:
Ang lahat ng sumusunod sa utos na ito ay binibigyang kahulugan bilang isang mensaheng ipapadala. Karaniwang idinadagdag ng SMTP server ang header ng mensahe na may timestamp at impormasyon ng return-path. Ang programa ng kliyente ay nagpapahiwatig ng pagtatapos ng mensahe sa pamamagitan ng pagpasa ng isang linya na sinusundan ng isang tuldok. Ang format ng linyang ito ay ang mga sumusunod:
Matapos matanggap ang pagkakasunud-sunod na ito, ang SMTP server ay "naiintindihan" na ang paghahatid ng mensahe ay kumpleto na at dapat magbalik ng isang response code na mag-aabiso sa kliyente na ang mensahe nito ay tinanggap.
IPADALA ang utos
Ang SEND command ay ginagamit upang magpadala ng mga mensaheng mail nang direkta sa terminal ng nakarehistrong user ng system. Ang command na ito ay isinasagawa lamang kapag ang user ay naka-log in at kadalasan ay isang pop-up na mensahe, katulad ng write command sa UNIX. Ang utos na ito ay may malubhang disbentaha: sa tulong nito, ang isang panlabas na gumagamit ay madaling matukoy kung sino ang nasa sa ngayon ay nasa sistema. Ang "pagkakataon" na ito ay matagal nang aktibong pinagsamantalahan ng mga hacker upang makakuha ng mga ID ng gumagamit ng Internet mula sa mga hindi pinaghihinalaang biktima na naka-log in sa system. Dahil sa mga alalahanin sa seguridad, karamihan sa mga SMTP software package ngayon ay hindi na naglalaman ng command na ito.
RSET na utos
Ang RSET command ay maikli para sa pag-reset. Kung nalilito ang kliyente tungkol sa mga tugon na natatanggap nito mula sa server, o nagpasya na nawala ang koneksyon, maaari itong magpadala ng RSET na utos at ibalik ang session sa panimulang punto nito - isagawa ang HELO command. Sa kasong ito, kakanselahin ang lahat ng naunang ipinadalang command - MAIL, RCPT at DATA. Kadalasan ang utos na ito ay ginagamit bilang isang " huling paraan" kapag nawala ang client ng command sequence o nakatanggap ng hindi inaasahang tugon mula sa server.
VRFY
Ang VRFY command ay maikli para sa pag-verify. Maaari itong magamit upang matukoy kung ang isang server ay maaaring maghatid ng mail sa isang partikular na tatanggap bago isagawa ang RCPT command. Ang format ng command na ito ay ang mga sumusunod:
username ng VRFY
Sa pagtanggap ng command na ito, tinutukoy ng SMTP server kung mayroon itong user sa lokal na server na may ibinigay na pangalan. Kung ang naturang user ay natagpuan, ang server ay magbabalik ng isang tugon nang buo postal address gumagamit. Kung walang ganoong user sa lokal na server, maaaring magbalik ang SMTP server ng negatibong tugon sa kliyente o ipahiwatig na ipapasa nito ang lahat ng mensahe sa isang malayuang gumagamit. Ito ay depende sa kung ang SMTP server ay magpapasa ng mga mensahe sa malayong kliyente.
Ang VRFY command ay maaaring maging isang epektibong tool kapag nag-troubleshoot ng mga problema sa email. Kadalasan, kapag nagpapadala ng mga mensaheng email, mali ang spelling ng mga user sa destinasyon o pangalan ng host at pagkatapos ay nagtataka kung bakit hindi natanggap ang kanilang mga mensahe. Siyempre, ang una nilang gagawin ay magreklamo sa administrator sistema ng koreo sa kasuklam-suklam na pagganap ng sistema ng email. Bilang isang email system administrator, maaari mong suriin ang functionality ng mga email address sa dalawang paraan. Una, gamit ang DNS host command, na nagbibigay-daan sa iyong matukoy ang kawastuhan ng domain name at ang pagkakaroon ng mail server na nagsisilbi sa domain. At pangalawa, pwede kang sumama gamit ang telnet sa port 25 ng mail server at pagkatapos ay mag-isyu ng VRFY command, na tutukuyin kung tama ang username. Ang listahan 5.3 ay nagpapakita ng isang halimbawa ng paggamit ng VRFY command upang patunayan ang mga username.
1 [riley@ shadrach riley] $ telnet localhost 25 2 Sinusubukan ang 127.0.0.1... 3 Nakakonekta sa localhost. 4 Ang karakter sa pagtakas ay "^]" . 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/ 8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], natutuwa akong makilala ka 8 VRFY rich 9 250< rich@ shadrach,smallorg.org>10 VRFY prez@ mechach.smallorg.org 11 252< prez@ mechach.smallorg.org>12 VRFY jessica 13 550 jessica... Hindi kilala ang user 14 QUIT 15 221 shadrach.smallorg.org pagsasara ng koneksyon 16 Sarado ang koneksyon ng -foreign host. 17 [riley@shadrach riley]$Ipinapakita ng mga linya 8-13 ang output ng VRFY command. Sinusubukan ng Linya 8 na magsagawa ng VRFY sa lokal na gumagamit mayaman. Kinukumpirma ng tugon ng SMTP server sa linya 9 na mayroong user na may ganoong pangalan sa system, at ibinalik ang buong email address ng kliyente. Ang linya 10 ay nagpapakita ng isa pang opsyon para sa pagtukoy ng VRFY command. Dito sinusubukan ng kliyente na mag-isyu ng VRFY command sa user sa malayong computer. Ang tugon na natanggap sa linya 11 mula sa shadrach system ay iba sa resulta na natanggap sa linya 9. Ang seksyon ng Mga Tugon ng Server ay tinatalakay ang kahulugan ng mga code na ibinalik ng server nang mas detalyado. Sa aming kaso, tandaan na ang shadrach system ay nag-aabiso sa kliyente na ang mail ay ipapasa sa user prez sa remote server na meshach.smallorg.org. Ang linya 12 ay nagpapakita ng isang pagtatangka upang suriin ang isang hindi umiiral na pangalan sa sistema ng meshach. Ang tugon ng SMTP server sa linya 13 ay maliwanag.
Suriin ang pagkakaroon ng user gamit ang bash at curl. $echo -e "VRFY MAIL MULA SA:\nQUIT"|
curl telnet:// mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 username@ example.com 221 2.0.0 Bye
Koponan ng NOOP
Ang NOOP command ay maikli para sa walang operasyon. Ang command na ito ay walang epekto sa SMTP server maliban na ang server ay nagbabalik ng positibong response code dito. Ginagamit ito kapag sinusubukan ang isang koneksyon nang hindi nagpapasa ng mensahe.
QUIT command Ginagawa ng QUIT command kung ano mismo ang sinasabi nito, i.e. nagpapaalam sa SMTP server na natapos na ang computer ng kliyente kasalukuyang sesyon
at gustong isara ang koneksyon. Ang SMTP server ay dapat tumugon sa utos na ito at pagkatapos ay simulan at isara ang koneksyon sa TCP. Kung tinanggap ng server ang QUIT command habang nagpapadala ng mail, ang lahat ng data na ipinadala sa panahon ng session ay dapat sirain at hindi makakarating sa tatanggap.
Format ng mensahe (Email)
Mga karaniwang field ng header ayon sa RFC 822 Ang RFC 822 ay nangangailangan na ang isang mensahe ay hatiin sa dalawang bahagi. Ang unang bahagi ay tinatawag na header. Ang lahat ng data na nagpapakilala sa mensahe ay ipinasok dito. Ang ikalawang bahagi ay tinatawag na katawan ng mensahe. Ang header ay binubuo ng mga patlang ng data na ginagamit bilang karagdagang impormasyon ay kinakailangan sa mensahe. Dapat paghiwalayin ang mga field ng header at katawan ng mensahe walang laman na linya
. Walang partikular na pagkakasunud-sunod para sa mga field ng header, i.e. Ang mga patlang ng header ay maaaring ilagay sa anumang pagkakasunud-sunod. Bukod pa rito, maaaring ulitin ang mga field ng header sa loob ng parehong mensahe. Ang figure ay nagpapakita ng pangkalahatang view ng isang email na mensahe na sumusunod sa mga kinakailangan ng RFC 822.
Format ng mensahe ayon sa RFC 822
Natanggap na field ng header
Ang format ng field ng Natanggap: header ay ang mga sumusunod:
Ang Natanggap na patlang ng header ay ginagamit upang tukuyin ang mga SMTP server na kasangkot sa proseso ng paghahatid ng mensahe mula sa nagpadala sa tatanggap. Ang bawat server ay nagdaragdag ng sarili nitong Natanggap na field sa mensaheng mail, na nagsasaad ng partikular na impormasyon tungkol sa sarili nito. Ang mga subfield sa Natanggap na patlang ay nagpapahiwatig ng landas, protocol, at mga computer na lumahok sa pagpapadala ng mensahe.
Field ng header ng Return-Path
Ang format ng field ng header na ito ay ang mga sumusunod:
Pabalik-Path: ruta
Ang huling SMTP server sa forwarding chain ay nagdaragdag ng field na Return-Path sa mensahe. Ang layunin nito ay upang matukoy ang ruta kung saan nakarating ang mensahe sa tatanggap. Kung direktang ipinadala ang mensahe sa server ng tatanggap, isang address lang ang ipapakita sa field na ito. Kung hindi, ito ay ipapakita dito buong listahan mga server kung saan ipinasa ang mensahe upang maabot ang tatanggap. Maaaring iba sa MAIL FROM (iyon ay, ang return address ay maaaring tukuyin na iba sa address ng nagpadala).
Field ng header ng pinagmulan
Ipinapahiwatig ng field ng Originator ang address ng nagpadala ng mensahe. Ang impormasyong ito ay lubhang kapaki-pakinabang sa mga sitwasyon kung saan ang mga mensahe ay ilang beses na tinanggihan ng mga pribadong network bago sila makarating sa Internet. Ang format ng field na ito ay ang mga sumusunod:
Reply-To: address
Ang field ng Originator ay isang maliit na pantulong na field lamang sa mga field ng multi-kulay na header. Maaari itong magamit bilang isang mas madaling landas para sa maliliit na SMTP packet. Inaalis nito ang pangangailangan para sa mas kumplikadong mga field ng header na tumutukoy sa nagpadala.
Ipadala muli ang field ng header
Tinutukoy ng field ng Resent header ang isang mensaheng mail na sa ilang kadahilanan ay kinailangang ipadala muli ng kliyente. Ang format ng field na ito ay ang mga sumusunod:
Resent-Reply-To: address
Mga patlang ng tunay na header
Tinutukoy ng data ng field ng header ang nagpadala email. Mga tunay na format ng field:
Mula sa: user-name Sender: user-name
Tinutukoy ng field na Mula kay: ang may-akda ng mensahe. Kadalasan ang From: at Sender: field ay iisang user, kaya isa lang sa mga field na ito ang talagang kinakailangan. Sa kaso kung saan ang nagpadala ng mail ay hindi ang may-akda ng mensahe, ngunit ito ay ipinadala lamang mula sa kanyang address, ang parehong mga field ay dapat pa ring tukuyin - tinitiyak nito na ang mensahe ay ibinalik sa nagpadala kung ang paghahatid sa addressee ay imposible. . Mga field ng resent-authentic na header
Tinutukoy ng mga field na Resent-authentic ang nagpadala ng isang mensahe na muling ipinadala ng programa ng kliyente para sa ilang kadahilanan. Ang format ng mga field na ito ay ang mga sumusunod:
Resent-From: date-time Resent-Sender: date-time Ang mga field na Resent-From: at Resent-Sender: ay gumagana nang katulad sa mga field na Mula kay: at Sender:. Sinasalamin lamang nila na ang mensahe ay muling ipinadala ng kliyente sa hindi malamang dahilan.
Mga field ng header ng petsa
Ang mga field ng header ng petsa ay ginagamit upang maglagay ng timestamp sa mensahe kapag ipinadala ito mula sa kliyente patungo sa server. Ang mga field ng Petsa ay may sumusunod na format:
Petsa: date-time Resent-Date: date-time Ipapasa ng field na Petsa: ang impormasyon sa header ng mensahe nang eksakto sa orihinal na mensahe. Maaaring maging kapaki-pakinabang ang opsyong ito kapag sinusubaybayan ang timing ng mga tugon, lalo na ang maraming tugon.
Mga field ng header ng patutunguhan
Isinasaad ng mga field ng Destination header ang mga email address ng mga tatanggap ng mensahe. Ang mga field na ito ay puro impormasyon. Ang SMTP server ay hindi magpapadala ng mensahe sa mailbox ng user sa anumang kaso hanggang sa matanggap nito ang RCPT command na ibinigay para sa ibinigay na gumagamit(tingnan ang seksyong "Mga Pangunahing Utos ng SMTP Client"). Ang format ng mga field na ito ay ang mga sumusunod:
Sa: address Resent-To: address CC: address Resent-CC: address BCC: address Resent-BCC: address
Ang To:, CC:, at BCC: na mga field ay nagtatakda ng karaniwang algorithm sa pagproseso ng email. Karamihan sa mga pakete ng email ay gumagamit ng terminolohiya na ito upang pag-uri-uriin ang mga tatanggap ng mensahe. CC field: Katulad ng isang memo, at ang mga tatanggap na tinukoy dito ay dapat makatanggap ng "kopya" ng mensahe. Ang isa pang bagong konsepto na ipinakilala ng mga email system ay BCC: o blind carbon copy. Ang field na "invisible copy" ay nagpapahiwatig din ng tatanggap ng isang kopya ng mensahe, ngunit ang kanyang address ay hindi nakikita ng mga tagalabas (ito ay hindi ganap na etikal). Nagkaroon ng ilang debate tungkol sa opsyong ito patungkol sa etika ng computer, ngunit ngayon halos lahat ng e-mail program ay sumusuporta sa feature na ito.
Opsyonal na mga field ng header
Ang mga opsyonal na field ay mga patlang na tumutukoy sa mensahe nang mas detalyado sa SMTP server, ngunit, ayon sa RFC 822, ay maaaring wala sa mensahe. Gayunpaman, ang mga larangang ito ay laganap na ngayon at marami sa inyo ang kailangang harapin ang mga ito. Ang format ng ilan sa mga ito ay ang mga sumusunod:
Message-ID: message-id Resent-Message-ID: message-id In-Reply-To: message-id Mga Sanggunian: message-id Mga Keyword: text - listahan Paksa: text Mga komento: text Na-encrypt: salita
Ang pinakakapaki-pakinabang at madalas na ginagamit ng set na ito ay ang Subject: field. Karamihan sa mga email program ay nagpapahintulot sa nagpadala na magpasok ng isang linyang linya ng paksa na naglalarawan sa mga nilalaman ng mensahe sa tatanggap. Ang linya ng text na ito ay kadalasang ginagamit ng mga mail client program kapag bumubuo ng mga listahan ng mga natanggap na mensahe. Nakakatulong din ang isa pang opsyonal na field na matukoy ang mensahe ng mail. Ang field na ito ay Message-ID: (Message Identifier). Nagtatalaga ang field na ito ng natatanging numero ng pagkakakilanlan sa mensahe, na maaaring lumabas sa ibinalik na mensahe. Espesyal na field ng pag-encrypt Naka-encrypt: nagpapahiwatig kung ang mensahe ay na-encrypt para sa mga layuning pangseguridad, at sa Mga Keyword: maaaring itakda mga keyword, na maaaring gamitin kapag naghahanap ng partikular na text na makikita sa isang (mga) mensahe.
Binary data at MIME
Isinasaalang-alang ng algorithm ng pag-encode ng MIME ang uri binary file sumasailalim sa conversion, at ang karagdagang impormasyon tungkol sa file ay ipinadala sa decoder. Ang algorithm ng MIME ay nagbibigay-daan sa binary data na direktang mailagay sa isang karaniwang mensahe ng mail, gaya ng tinukoy ng RFC 822. Limang bagong header na field ang ginawa upang ilarawan ang binary data na naka-embed sa isang RFC 822 na format na mensahe. Ang mga mail program na sumusuporta sa pamantayan ng MIME ay dapat pangasiwaan nang tama ang lahat ng mga bagong uri ng header na ito.
Field ng header ng MIME-Bersyon
Ang una sa mga opsyonal na field ng header ay naglalaman ng bersyon ng MIME na ginamit ng nagpadala kapag nag-encode ng mensahe. Sa kasalukuyan ang field na ito ay palaging 1.0.
Field ng Content-Transfer-Encoding
Tinutukoy ng field ng header ng Content-Transfer-Encoding kung paano nakapaloob ang binary data sa isang text message ng ASCII. Ngayon ay may pito sa iba't ibang paraan encoding ng binary data, ngunit base64 encoding ang pinakakaraniwan. Ang paraan ng pag-encode na ito ay nagko-convert ng 6-bit na mga bloke ng binary data sa 8-bit na mga bloke na binabasa bilang ASCII text.
Field ng Content-ID
Ginagamit ang field ng header na ito upang tukuyin ang mga session ng MIME sa pamamagitan ng isang partikular na ID code kapag kumplikado ang nilalaman.
Field ng Nilalaman-Paglalarawan
Ang field ng header ng Content-Description ay ginagamit upang magbigay ng ASCII text description ng data na kasama sa mail message. Ito ay maginhawa kapag nagpapadala ng mga dokumento na ginawa gamit tagaproseso ng salita o mga graphics na hindi naiiba sa pagiging base64 na naka-encode.
Field ng header na Uri ng Nilalaman
Field ng header na Uri ng Nilalaman
Ang title field na ito ay kung saan nagaganap ang pangunahing aksyon ng aming dula. Tinutukoy ng field na ito ang data na nilalaman sa mensahe ng MIME. Kasalukuyang mayroong pitong pangunahing klase ng data na natukoy sa MIME. Ang bawat klase ay may kani-kaniyang mga subclass, na nagpapakilala nang mas detalyado sa uri ng data na nakapaloob sa mensahe.
Tinutukoy ng uri ng data ng text ang ASCII data na dapat basahin sa raw na anyo nito. Mayroon ding dalawang subclass dito - plain-text, i.e. hindi na-format na ASCII text, at enriched text, na kinabibilangan ng mga elemento ng pag-format na katulad ng enriched na text format ng teksto. Ang pinakabagong mga email program ay maaaring pangasiwaan ang Rich Text Format (RTF).
Ang uri ng data ng mensahe ay nagbibigay-daan sa isang email program na magpadala mga simpleng mensahe sa format na RFC 822, ang mga subclass ng ganitong uri ay rfc822, na nagpapahiwatig na ang attachment ay regular na mensahe, umaayon sa RFC 822; bahagyang, na nagpapahintulot sa iyo na hatiin ang mahahabang mensahe sa maraming bahagi, at panlabas na katawan, na nagbibigay-daan sa iyong maglagay ng pointer sa isang bagay na hindi bahagi ng mensahe.
Ang uri ng data ng imahe ay tumutukoy sa attachment ng binary data, na kumakatawan sa isang graphical na larawan, sa isang mensahe. Kasalukuyang mayroong dalawang subclass na tinukoy para sa ganitong uri - jpeg at gif.
Ang uri ng data ng video, nang naaayon, ay tumutukoy na ang data na naka-attach sa mensahe ay data ng video. Kasalukuyang mayroon lamang isang subclass na tinukoy para sa ganitong uri, ang mpeg na format.
Ang uri ng data ng audio ay tumutukoy sa nilalaman ng mensahe bilang data ng audio (mga sound file). Dito rin, isang pangunahing subclass lang ang natukoy sa ngayon, na tumutugma sa isang ISDN channel na may dalas ng sampling na 8 KHz.
Ang uri ng data ng application ay tumutugma sa binary data na naka-attach sa isang mensahe na isang application (halimbawa, electronic Mga talahanayan ng Microsoft Excel o mga dokumentong ginawa gamit ang text processor ng Microsoft salita). Sa ngayon, dalawang subclass ng ganitong uri ng data ang tinukoy - postscript at octet-stream. Kadalasan ang octet-stream subclass ay ginagamit kapag nag-attach ng data ng application sa isang mensahe, tulad ng mga dokumento ng Microsoft Salita o mga spreadsheet Microsoft Excel.
Tinutukoy ng multipart data type ang mga mensaheng naglalaman ng iba't ibang uri ng data. Ang format na ito ay karaniwan sa mga email program na sumusuporta sa output ng mensahe sa maraming paraan, gaya ng ASCII text. HTML na teksto o audio file. Ang isang boundary identifier ay naghihiwalay sa iba't ibang uri ng data. Kasabay nito, ang bawat uri ng data ay tinutukoy ng isang partikular na field ng header ng uri ng data. Ang multipart na uri ng data ay may apat na subclass.
Ang pinaghalong subclass ay nagpapahiwatig na ang bawat bahagi ng mensahe ay independiyente at dapat lahat ay iharap sa tatanggap sa pagkakasunud-sunod kung saan ang mga ito ay ipinasok ng nagpadala. Ang parallel subclass ay nagpapahiwatig na ang bawat bahagi ng mensahe ay independyente at lahat ng mga ito ay maaaring iharap sa tatanggap sa anumang pagkakasunud-sunod. Ang susunod na subclass, alternatibo, ay tumutukoy na ang lahat ng bahagi ng mensahe ay pareho ng data, ngunit ipinakita sa ibang anyo. Sa kasong ito, maaaring piliin ng tatanggap ang pinakamahusay na paraan upang tingnan ang natanggap na data. Ang digest subclass ay katulad sa maraming paraan sa mixed subclass, ngunit tinutukoy na ang message body ay palaging kinakatawan sa RFC822 format.
1 $ telnet localhost 25 2 Sinusubukan ang 127.0.0.1... 3 Nakakonekta sa localhost. 4 Ang escape na character ay "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Lun, 30 Ago 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hello localhost, natutuwa akong makilala ka 8 MAIL FROM:rich@localhost 9 250 rich@localhost... Sender ok 10 RCPT TO: rich 11 250 rich... Recipient ok 12 DATA 13 354 Ipasok ang mail, tapusin sa "." sa isang linya mismo 14 Mula sa:"Rich Blum"
Listahan 5.6. Halimbawa ng SMTP Session na may Maramihang MIME Attachment (html, txt) Ang halimbawang mensahe na ipinapakita sa Listahan 5.6 ay isang MIME na mensahe na may dalawang bahagi. Ipinapakita ng linya 18 ang uri ng data ng mensahe. Ang multipart/alternative type ay nagpapahiwatig na ang mensahe ay naglalaman ng iba't ibang uri ng data na pinaghihiwalay ng bounds1 delimiter. Ang unang uri ng data ay nagsisimula sa linya 21 at simpleng ASCII text na mababasa ng halos anumang email program.
Ang pangalawang uri ng data ay nagsisimula sa linya 27 at rich text gamit ang rich text format.
kasi Uri ng MIME Ang tinukoy para sa isang mensahe ay multipart/alternative, pagkatapos ay ang pagtukoy kung aling bersyon ng attachment ang ipapakita ay ganap na nakasalalay sa email program.
Pinahusay na SMTP Protocol
Mula nang ipakilala ito noong 1982, ang SMTP protocol ay nakagawa ng isang mahusay na trabaho sa pagpapadala ng mga mensahe sa pagitan ng mga computer sa Internet. Gayunpaman, sa paglipas ng panahon, ang mga limitasyon na likas sa protocol ay naging kapansin-pansin. Pagkatapos, sa halip na palitan ang karaniwang protocol, na malawakang ginagamit noong panahong iyon, napagpasyahan na pagbutihin ang ilan sa mga function ng SMTP protocol. Kasabay nito, napagpasyahan na iwanan ang lahat ng mga pagtutukoy ng SMTP sa kanilang orihinal na anyo at magdagdag lamang ng mga bagong function sa kanila.
Noong 1995 ito ay inilabas dokumento ng RFC 1869, kung saan ang isang paraan upang palawigin ang mga kakayahan ng SMTP protocol ay tinukoy, na tinatawag na "Extended SMTP Services".
Ang pinalawak na SMTP ay ipinatupad bilang mga sumusunod. Sa simula ng isang SMTP session, ang HELO command ay pinalitan ng isang invitation command - EHLO. Kapag nakatanggap ang SMTP server ng ganoong command, nangangahulugan ito na maipapadala ito ng kliyente ng extended Mga utos ng SMTP. Ang listahan 5.7 ay nagpapakita ng isang halimbawang session gamit ang EHLO pati na rin ang mga karagdagang command.
1 $ telnet localhost 25 2 Sinusubukan ang 127.0.0.1... 3 Nakakonekta sa localhost. 4 Ang escape na character ay "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Lun, 30 Ago 1999 16:36:48 -050 6 EHLO localhost 7 250-shadrach.smallorg.org Kamusta localhost, ikinalulugod na makilala ka 8 250-EXPN 9 250-PANDIWA 10 250-8BITMIME 11 250-25SIZE 13 250-ONEX 14 250-ETRN 15 250-XUSR 16 250 TULONG 17 TULONG DSN 18 214-MAIL MULA SA:
Tinukoy ng Linya 6 ang SMTP command na EHLO para kumonekta sa SMTP server. Ipinapakita ng mga linya 7–16 ang tugon ng server. Tandaan na ang server ay nagpapahiwatig na mas maraming command ang magagamit para sa paggamit, i.e. Nagaganap ang session sa "extended" mode. Ang isa sa mga bagong pangkat ng mga command ay tinatawag na Delivery Status Notification parameters. Ang mga parameter na ito ay maaaring gamitin sa MAIL at RCPT na mga utos upang ipakita ang katayuan ng paghahatid tiyak na mensahe email. Gayunpaman, para sa amin bilang mga tagapangasiwa ng sistema ng mail, ang utos ng ETRN ay higit na interesado.
Ang TURN command ay nabanggit na kanina. Ang utos na ito ay napaka-epektibo, ngunit sa kasamaang-palad ay hindi ligtas. Upang mabayaran ang pagkukulang na ito, tinukoy ng RFC 1985 bagong pagpapatupad TURN command, na nagbibigay ng mas mataas na antas ng seguridad. Ang ETRN command ay nagpapahintulot sa isang SMTP client na mag-isyu ng isang kahilingan sa isang SMTP server upang makapagsimula ng isa pang SMTP na koneksyon sa kliyente upang magpadala ng mga mensahe dito. Ang tanging pagkakaiba sa pagitan ng ETRN command at TURN command ay ang kahilingan ay hindi gumamit ng kasalukuyang koneksyon, ngunit upang magbukas ng bagong SMTP session. Sa ganitong paraan, ang SMTP server ay maaaring kumonekta sa client computer gamit ang normal na DNS name resolution algorithm. Sa kasong ito, ang pagbubukas ng isang bagong koneksyon ay batay hindi sa pangalan kung saan nakarehistro ang computer ng kliyente sa server, ngunit sa tunay na pangalan ng host ng kliyente. Sa kasong ito, kung ang isang hacker ay nagtatag ng isang hindi awtorisadong koneksyon sa SMTP at ginagamit ang ETRN command, ang SMTP server ay magtatatag lamang ng isang bagong koneksyon sa tunay na kliyente at ipasa sa kanya ang isang email. Dahil dito, walang nasawi. Ang format ng utos ng ETRN ay ang mga sumusunod:
Dito, ang tungkulin ng pangalan ay maaaring ang pangalan ng host o ang domain name (kung may kahilingang tumanggap ng mail para sa buong domain). Ang ETRN team ay isang napakagandang tulong para sa isang email administrator. Kung ang iyong Internet provider ay nag-iimbak ng mail para sa iyong mail server, gamit ang command na ito maaari mong ipaalam ito na handa na itong tumanggap ng mail na nakolekta para sa iyo. Mayroong ilang mga paraan upang ipatupad ang gayong algorithm. Isa na rito ang paggamit ng espesyal Mga programang Perl, na kasama ng sendmail program. Ang gawain nito ay tiyak na pagkatapos magtatag ng isang koneksyon sa Internet provider, naglalabas ito ng ETRN command na may pangalan ng iyong domain bilang isang argumento. Matapos matanggap ang utos na ito, ang SMTP server ng provider ay magpapasimula ng isa pang koneksyon sa SMTP sa iyong lokal na SMTP server (sa parehong koneksyon sa PPP) at ipinapadala ang lahat ng mail na inilaan para sa iyong domain na mayroon ito sa pila para sa pagpapadala.
Malamang na karamihan sa mga taong nagbabasa ng gabay na ito ay pamilyar na sa pinakakaraniwang ginagamit na teknolohiya ng komunikasyon: email. Ngunit naisip mo na ba kung paano ito gumagana? Sa artikulong ito, malalaman natin kung paano gumagana ang serbisyong ito at kung ano ang POP3, SMTP at IMAP.
POP3(protocol post office bersyon 3) ay kadalasang ginagamit upang makipag-ugnayan sa isang malayuang email server at mag-download ng mga mensahe sa isang lokal na email client at pagkatapos ay tanggalin ito sa server, halimbawa Thunderbird, Windows Mail, atbp. Gayunpaman, ang mga email client ay karaniwang nag-aalok ng isang pagpipilian kung mag-iwan o hindi ng mga kopya ng mga mensahe sa server. Kung gumagamit ka ng maramihang mga device upang magpadala ng mga mensahe, inirerekumenda na iwanang naka-enable ang feature na ito, kung hindi, sa ibang device ay hindi ka magkakaroon ng access sa mga ipinadalang mensahe na hindi na-save sa remote server. Dapat ding tandaan na ang POP3 ay isang one-way na protocol lamang, na nangangahulugang ang data ay kinuha mula sa malayong server at ipinadala sa lokal na kliyente.
Ang mga default na POP3 port ay:
Port 110 – port na walang encryption
Ang Port 995 ay isang SSL/TLS port, na kilala rin bilang POP3S
Hakbang 2 - Mga pagkakaiba sa pagitan ng POP3 at IMAP, at ano ang mga port para sa IMAP?
IMAP (application layer protocol para sa pag-access ng email), pati na rin ang POP3, ay ginagamit upang makatanggap ng mga email na mensahe sa isang lokal na kliyente, gayunpaman, ito ay may makabuluhang pagkakaiba - ang mga email header lamang ang dina-download, ang teksto ng liham mismo ay nananatili sa server. Ang protocol na ito Ang komunikasyon ay gumagana sa dalawang direksyon; kung ang mga pagbabago ay nangyari sa lokal na kliyente, sila ay ipinadala sa server. Ang IMAP ay naging mas sikat kamakailan dahil ang mga higanteng email service provider tulad ng Gmail ay nagsimulang magrekomenda nito sa halip na POP3.
Ang mga default na IMAP port ay:
- Port 143 – port na walang encryption
- Ang Port 993 ay isang SSL/TLS port, na kilala rin bilang IMAPS
Hakbang 3 - SMTP, ang protocol para sa mga papalabas na komunikasyon sa email
Simple Mail Transfer Protocol ( SMTP), ay ginagamit upang makipag-usap sa isang malayong server at pagkatapos ay magpadala ng mga mensahe mula sa lokal na kliyente patungo sa malayong server, at sa huli sa server ng tatanggap ng mensahe. Sa iyong email server, ang prosesong ito ay kinokontrol espesyal na serbisyo (MTA). Mahalagang banggitin na ang SMTP ay ginagamit lamang para sa pagpapadala ng mga mensahe.
Mga SMTP port:
- Port 25 – port na walang encryption
- Ang Port 465 ay isang SSL/TLS port, na kilala rin bilang SMTPS
Konklusyon
Umaasa kami na mayroon ka na ngayong malinaw na pag-unawa sa kung paano gumagana ang mga protocol ng email at kung anong mga port ang ginagamit nila. Sa tutorial na ito, natutunan namin kung ano ang POP3, SMTP at IMAP at kung para saan ang mga ito. Halimbawa, ang POP3 at IMAP ay ginagamit para sa parehong layunin, ngunit iba ang diskarte nila sa mga gawaing ito. Iniiwan ng IMAP ang nilalaman ng mensahe sa server, at dina-download ito ng POP3 sa iyong computer. Gayundin, nalaman namin kung ano karaniwang mga port para sa SMTP, POP3 at IMAP.
Sa loob ng ilang dekada, ang mga gumagamit ng Internet ay gumagamit ng email upang makipagpalitan ng mga mensahe at liham. Hanggang sa unang bahagi ng 90s ng huling siglo, ang mga elektronikong mensahe ay ginamit, bilang panuntunan, ng mga empleyado malalaking organisasyon. Sa malawak na computerization at pagkalat ng World Wide Web, ang mga email ay naging bahagi ng buhay ng mga ordinaryong gumagamit.
Ang pag-unlad ng mga teknolohiya sa Internet ay humantong sa paglitaw ng tinatawag na mga protocol ng mail na ginagamit para sa pagsusulatan sa network. Ginagawa nilang posible na iproseso ang malalaking titik, na nagbibigay sa mga user ng lahat ng uri ng serbisyo.
Hindi ito pinipigilan ng anumang partikular na mga subsystem ng paghahatid ng data. Ang operasyon nito ay nangangailangan lamang ng maaasahang channel para sa daloy ng kanilang paghahatid habang pinapanatili ang kaayusan.
Ang SMTP ay pangunahing ginagamit para sa pagpapadala ng mga liham at mga kahilingan ng user sa server, pagkatapos ay ipinapadala ang mail sa mga tatanggap. Upang makatanggap ng mga liham, kailangan mong gumana ang iyong mail client sa IMAP o POP3 protocol.
Ano ang gamit nito?
Ito ang karaniwang mail protocol ngayon. Ginagamit ito ng lahat mga mailers at mga server.
Virtual website hosting para sa sikat na CMS:
Ang prinsipyo ng pagpapatakbo ng protocol.
Ang SMTP ay isang text protocol, ang prinsipyo ng pagpapatakbo nito ay nangangailangan ng koneksyon kung saan ang user na nagpapadala ng email ay nakikipag-ugnayan sa tatanggap nito gamit ang isang partikular na command line. At ang data ay natanggap sa pamamagitan ng paggamit ng isang maaasahang channel ng komunikasyon. Karaniwan, ang channel ng komunikasyon na ito ay isang koneksyon sa TCP.
Ang sesyon ng pagtatrabaho ng protocol ay binubuo ng ipinadalang mail - SMTP client isang bilang ng mga utos at tugon ng server sa kanila. Sa sesyon ng pagtatrabaho ang parehong kliyente at server ay nagpapalitan ng mga kinakailangang parameter.
Kasama sa operasyon ng protocol ang kumbinasyong binubuo ng mga sumusunod na pagkakasunud-sunod ng mga utos at tugon:
- MAIL FROM command - nagpapahiwatig ng return email address;
- RCPT TO command - tinutukoy ang tatanggap ng isang partikular na sulat;
- Ang DATA ay ang command na responsable sa pagpapadala ng text ng isang email message. Ito ang katawan ng liham, na kinabibilangan ng header at katawan ng liham, na pinaghihiwalay ng walang laman na linya.
Ang paunang SMTP client ay maaaring ang email client ng tatanggap, o isang mail transfer agent sa server.
Paano gumagana ang ibang mga mail protocol.
Ang SMTP ay isang protocol lamang para sa paghahatid ng mga sulat sa network. Hindi siya maaaring, sa utos, kumuha ng isang email na mensahe mula sa isang malayong server o kahit papaano ay mamahala ng isang email box.
Mayroong iba pang mga protocol para dito, tulad ng IMAP at POP. Ang kanilang paggamit ay mas mainam kapag nakakonekta sa isang network pansamantala o kapag ang PC ay naka-on sa pana-panahon.
POP.
Ang Post Office Protocol ay isang simpleng network protocol na may kasamang tatlong lasa: POP, POP2 at POP3. Ang mga ito ay idinisenyo upang maghatid ng mga sulat sa gumagamit mula sa isang sentral na mail server, upang tanggalin ang mail mula sa server, at upang makilala ang gumagamit. Ang kumbinasyon ng login at password ay ginagamit para sa pagkakakilanlan. Ito ay nagkakahalaga ng noting na ang lahat ng tatlong mga protocol ay hindi mapagpapalit.
Kasama sa protocol ang SMTP, na ginagamit upang magpadala ng papalabas na mail.
Alinsunod sa POP3, ang mga liham na dumarating sa isang partikular na e-mail ay iniimbak sa server hanggang sa ma-download ang mga ito sa PC sa susunod na sesyon. Kapag naganap ang pag-download, nagiging posible na basahin ang mga mensahe habang dinidiskonekta mula sa network. Ang POP3 ay itinuturing na pinakamabilis na mail protocol.
IMAP.
SA gamit ang Internet Mensahe Access Protocol Nagiging posible na mag-imbak ng mga mensahe sa mga direktoryo ng file sa server at maghanap ng anumang mga string ng mensahe nang direkta doon.
Ang protocol na ito ay angkop para sa mga user na ang mga computer ay gumagamit ng tuluy-tuloy na koneksyon sa Internet. Naiiba ito sa POP dahil kapag na-scan ang mga bagong mensahe, ang mga header lang ng mga ito ang dina-download.
Ngayon ay sasabihin namin sa iyo nang detalyado ang tungkol sa pinaka ginagamit na mga protocol sa Internet - POP3, IMAP at SMTP. Ang bawat isa sa mga protocol na ito ay may partikular na layunin at pag-andar. Subukan nating malaman ito.
POP3 protocol at mga port nito
Ang Post Office Protocol 3 (POP3) ay isang karaniwang mail protocol na idinisenyo para sa pagtanggap ng mga email mula sa isang malayuang server patungo sa isang e-mail client. Ang POP3 ay nagbibigay-daan sa iyo na mag-save ng isang email na mensahe sa iyong computer at kahit na basahin ito kung ikaw ay offline. Mahalagang tandaan na kung pipiliin mong gamitin ang POP3 upang kumonekta sa iyong mail account, ang mga email na na-download na sa iyong computer ay tatanggalin mula sa mail server. Bilang halimbawa, kung gumagamit ka ng maraming computer upang kumonekta sa isang email account, maaaring hindi ang POP3 ang pinakamahusay na pagpipilian sa sitwasyong ito. Sa kabilang banda, dahil ang mail ay lokal na naka-imbak, sa isang partikular na PC ng user, pinapayagan ka nitong i-optimize ang puwang sa disk sa gilid ng mail server.
Bilang default, ginagamit ng POP3 protocol ang mga sumusunod na port:
- Ang Port 110 ay ang default na POP3 port. Hindi ligtas.
- Port 995 – Dapat gamitin ang port na ito kung gusto mong magtatag ng secure na koneksyon.
IMAP protocol at mga port
Ang Internet Message Access Protocol (IMAP) ay isang email protocol na idinisenyo para sa pag-access ng mail mula sa isang lokal na email client. Ang IMAP at POP3 ay ang pinakasikat na Internet protocol na ginagamit para sa pagtanggap ng e-mail. Pareho sa mga protocol na ito ay sinusuportahan ng lahat ng modernong mail client (MUA - Mail User Agent) at WEB server.
Habang pinapayagan ng POP3 ang pag-access sa mail mula sa isang application lamang, pinapayagan ng IMAP ang pag-access mula sa maraming kliyente. Para sa kadahilanang ito, ang IMAP ay pinaka madaling ibagay sa mga kaso kung saan kailangan ng maraming user ng access sa parehong email account.
Bilang default, ginagamit ng IMAP protocol ang mga sumusunod na port:
- Port 143– default na port. Hindi ligtas.
- Port 993– port para sa secure na koneksyon.
SMTP protocol at mga port nito
Ang Simple Mail Transfer Protocol (SMTP) ay isang karaniwang protocol para sa pagpapadala ng mga mensaheng mail sa pamamagitan ng Internet.
Ang protocol na ito ay inilarawan sa RFC 821 at RFC 822, unang inilathala noong Agosto 1982. Sa loob ng saklaw ng data ng RFC, ang format ng address ay dapat nasa format username@domainname. Ang paghahatid ng koreo ay katulad ng regular na trabaho serbisyo sa koreo: halimbawa, isang liham sa address MAIL MULA SA:, ay bibigyang-kahulugan bilang mga sumusunod: ivan_ivanov ay ang address, at merionet.ru ay postal code. Kung ang domain name ng tatanggap ay iba sa domain name ng nagpadala, ipapadala ng MSA (Mail Submission Agent) ang sulat sa pamamagitan ng Mail Transfer Agent (MTA). Ang pangunahing ideya ng MTA ay ang pag-redirect ng mga titik sa isa pa domain zone, katulad ng kung paano nagpapadala ng mga liham ang tradisyonal na mail sa ibang lungsod o rehiyon. Ang isang MTA ay tumatanggap din ng mail mula sa ibang mga MTA.
Ginagamit ng SMTP protocol ang mga sumusunod na port.
4085/2, mga protocol ng Sorokin D. S. Mail
SMTP
Ang SMTP (Simple Mail Transfer Protocol) ay isang malawakang ginagamit na network protocol na idinisenyo para sa pagpapadala ng email sa mga TCP/IP network.
Mga transaksyon sa SMTP
Ang SMTP ay isang text protocol na nakabatay sa koneksyon kung saan ang nagpadala ng isang mensahe ay nakikipag-ugnayan sa tatanggap sa pamamagitan ng pag-isyu ng mga linya ng command at pagtanggap ng kinakailangang data sa pamamagitan ng isang maaasahang channel, na karaniwang isang koneksyon sa TCP (Transmission Control Protocol). Ang SMTP session ay binubuo ng mga command na ipinadala ng SMTP client at mga kaukulang tugon mula sa SMTP server. Kapag ang isang session ay bukas, ang server at client ay nagpapalitan ng mga parameter nito. Ang isang session ay maaaring magsama ng zero o higit pang mga operasyon ng SMTP (mga transaksyon).
Mga utos ng SMTP
Ang isang SMTP na operasyon ay binubuo ng tatlong command/response sequence:
MAIL FROM - nagtatakda ng return address (i.e. Return-Path, 53121.From, mfrom). Ito ang address para sa mga ibinalik na liham.
RCPT TO - itinatakda ang tatanggap ng mensaheng ito. Ang utos na ito ay maaaring ibigay ng maraming beses, isang beses para sa bawat tatanggap. Ang mga address na ito ay bahagi din ng shell.
DATA - upang ipadala ang teksto ng mensahe. Ito ang nilalaman ng sulat mismo, taliwas sa sobre nito. Binubuo ito ng isang header ng mensahe at isang katawan ng mensahe na pinaghihiwalay ng isang blangkong linya. Ang DATA ay mahalagang isang pangkat ng mga utos, at ang server ay tumugon nang dalawang beses: una sa mismong utos ng DATA, upang ipaalam
kahandaang tanggapin ang teksto; at sa pangalawang pagkakataon pagkatapos ng pagtatapos ng sequence ng data upang tanggapin o tanggihan ang buong sulat.
Bilang karagdagan sa mga intermediate na tugon para sa DATA command, ang bawat tugon ng server ay maaaring positibo (response code 2xx) o negatibo. Ang huli, sa turn, ay maaaring maging permanente (code 5xx) o pansamantalang (code 4xx). Ang pagkabigo ng SMTP server na magpadala ng mensahe ay isang permanenteng error; sa kasong ito ang kliyente ay dapat magpadala ng isang return letter. Pagkatapos ng pag-reset - isang positibong tugon, malamang na tatanggihan ang mensahe. Ang server ay maaari ring magpahiwatig na ang karagdagang data ay inaasahan mula sa kliyente (code 3xx).
Ang unang host (SMTP client) ay maaaring maging email client ng end user (functional na tinukoy bilang ahente ng koreo- MUA), at ang message forwarding agent (MTA) sa server, i.e. gumaganap ang server bilang isang kliyente sa naaangkop na sesyon upang ihatid ang mensahe. Sinusuportahan ng mga ganap na gumaganang server ang mga pila ng mensahe upang muling magpadala ng mga mensahe kung sakaling magkaroon ng mga error.
Alam ng MUA ang SMTP server para sa papalabas na mail mula sa mga setting nito. Ang SMTP server, na kumikilos bilang isang kliyente, ibig sabihin, pagpapasa ng mga mensahe, ay tumutukoy kung aling server ang kumonekta sa pamamagitan ng pagtingin sa mapagkukunang MX (Mail eXchange) na mga tala ng DNS para sa bawat domain ng tatanggap. Kung hindi mahanap ang MX record, ang mga katugmang MTA (hindi lahat) ay babalik sa isang simpleng A record. Ang pagpapasa ng mga server ay maaari ding i-configure upang gamit ang Smart host.
Ang SMTP server, na kumikilos bilang isang kliyente, ay nagtatatag ng koneksyon sa TCP sa server na idinisenyo para sa SMTP port 25. Dapat gamitin ng MUA ang port 587 para kumonekta
Message Submission Agent (MSA). Ang pangunahing pagkakaiba sa pagitan ng MTA at MSA ay ang pagpapatunay ng SMTP ay kinakailangan lamang para sa huli.
SMTPS
Ang SMTPS ay tumutukoy sa SMTP transport layer na mga pamamaraan ng seguridad. Ito ay idinisenyo upang matiyak ang pagpapatunay ng partido, integridad ng data at pagiging kumpidensyal. Ang SMTPS ay hindi isang proprietary protocol o extension sa SMTP, ito ay isang paraan lamang upang ma-secure ang SMTP sa transport layer.
Ang kliyente at server ay gumagamit ng regular na SMTP sa antas ng aplikasyon, ngunit ang koneksyon ay sinigurado ng SSL o TLS. Nangyayari ito pagkatapos maitatag ang isang koneksyon bago maipadala ang anumang data ng mail.
Gumagamit ang SMTPS ng port 465.
Ang POP3 (Post Office Protocol Bersyon 3) ay isang karaniwang Internet application protocol na ginagamit ng mga email client upang kunin ang isang email na mensahe mula sa isang malayuang server sa pamamagitan ng isang TCP/IP na koneksyon. Ang POP at IMAP (Internet Message Access Protocol) ay ang pinakakaraniwang mga protocol sa Internet para sa pagkuha ng mail. Halos lahat ng modernong email client at server ay sumusuporta sa parehong mga pamantayan. Ang POP protocol ay binuo sa ilang mga bersyon, na ang ikatlong bersyon (POP3) ang kasalukuyang pamantayan. Karamihan sa mga email service provider (gaya ng Hotmail, Gmail at Yahoo! Mail) ay sumusuporta din sa IMAP at POP3. Mga nakaraang bersyon ang mga protocol (POP, POP2) ay hindi na ginagamit.
Sinusuportahan ng POP ang mga simpleng kinakailangan sa pag-download at pagtanggal para sa pag-access sa mga malalayong mailbox. Bagama't karamihan sa mga kliyente ng POP ay nagbibigay ng kakayahang mag-iwan ng mail sa server pagkatapos mag-download, ang mga gumagamit Mga kliyente ng POP karaniwang kumonekta, kunin ang lahat ng email, i-save ang mga ito sa computer ng user bilang mga bagong mensahe, tanggalin ang mga ito sa server, at pagkatapos ay idiskonekta.
Nakikinig ang server ng POP3 sa kilalang port 110. Hinihiling ang pag-encrypt ng komunikasyon para sa POP3 pagkatapos magsimula ang protocol, gamit ang alinman sa utos ng STLS (kung sinusuportahan) o POP3S, na kumokonekta sa server gamit ang TLS o SSL sa TCP port 995.
Mga utos ng POP3
Mga argumento | Mga paghihigpit | Mga posibleng sagot |
||
Ang kanyang suporta ay hindi | * Ang +OK maildrop ay may n mensahe |
|||
[Pangalan] | * -ERR password na ibinigay para sa |
|||
sapilitan |
||||
[pangalan] ay hindi tama |
||||
* Ang pangalan ng +OK ay isang wastong mailbox |
||||
* -ERR ay hindi kailanman narinig ng mailbox |
||||
* +OK maildrop naka-lock at |
||||
Gumagana pagkatapos ng matagumpay na paglipat | ||||
* -ERR di-wastong password |
||||
pangalan ng mailbox |
||||
* -ERR hindi ma-lock |
||||
[mensahe] | Magagamit pagkatapos ng matagumpay | * +OK ang mensaheng tinanggal |
||
pagkakakilanlan | * -ERR walang ganoong mensahe |
|||
[mensahe] | Magagamit pagkatapos ng matagumpay | * +Sumusunod ang listahan ng pag-scan ng OK |
||
pagkakakilanlan | * -ERR walang ganoong mensahe |
|||
Magagamit pagkatapos ng matagumpay | ||||
pagkakakilanlan |
||||
[mensahe] | Magagamit pagkatapos ng matagumpay | * Sumusunod ang mensaheng +OK |
||
pagkakakilanlan | * -ERR walang ganoong mensahe |
|||
Magagamit pagkatapos ng matagumpay | ||||
pagkakakilanlan |
||||
Magagamit pagkatapos ng matagumpay | ||||
pagkakakilanlan |
||||
[mensahe] | Magagamit pagkatapos ng matagumpay | |||
[dami |
||||
pagkakakilanlan | * -ERR walang ganoong mensahe |
|||
IMAP
Ang isang alternatibong protocol para sa pagkolekta ng mga mensahe mula sa isang mail server ay IMAP. Ang IMAP (Internet Message Access Protocol) ay isang application-level protocol para sa pag-access ng email.
Batay sa protocol ng transportasyon TCP at gumagamit ng port 143.
Ang POP3 ay may isang bilang ng mga disadvantages, at ang pinakaseryoso sa mga ito ay ang kakulangan ng mga kakayahan upang makontrol ang paggalaw at pag-iimbak ng mga mensahe sa server. Ang mga mensahe, bilang panuntunan, ay na-download mula sa mail server nang sabay-sabay, pagkatapos ay tinanggal ang mga ito mula sa server, iyon ay, walang kakayahang pumili ng mga mensaheng matatanggap.
Upang matugunan ang mga problemang nauugnay sa tampok na ito ng POP3, ang Unibersidad ng Washington ay bumuo ng isang bagong protocol na nagpapahintulot sa mga user na makatanggap ng e-mail mula sa parehong mailbox mula sa maraming lokasyon nang hindi ipinamamahagi ang mga mensahe sa mga punto ng pagtanggap. Ang user ay binibigyan ng pagkakataong pamahalaan ang mga mensahe sa kanyang mailbox at mga karagdagang function ng serbisyo mga mailbox sa server.
Mga pakinabang ng IMAP
Kapag gumagamit ng POP3, kumokonekta ang kliyente sa server para lamang sa panahong kinakailangan upang mag-download ng mga bagong mensahe. Kapag gumagamit ng IMAP, hindi masisira ang koneksyon hanggang sa user interface aktibo at ang mga mensahe ay dina-download lamang kapag hiniling ng kliyente. Nagbibigay-daan ito sa iyong bawasan ang oras ng pagtugon para sa mga user na ang mga mailbox ay naglalaman ng maraming malalaking mensahe.
Ang POP protocol ay nangangailangan na ang kasalukuyang kliyente ay ang tanging konektado sa mailbox. Binibigyang-daan ng IMAP ang maramihang mga kliyente na mag-access ng isang mailbox nang sabay-sabay at nagbibigay sa kliyente ng kakayahang subaybayan ang mga pagbabagong ginawa ng ibang mga kliyente na konektado nang sabay-sabay.
Salamat sa flag system na tinukoy sa IMAP4, masusubaybayan ng kliyente ang katayuan ng isang mensahe (basahin, ipinadala ang tugon, tinanggal, atbp.); ang data ng bandila ay naka-imbak sa server.
Ang mga kliyente ng IMAP4 ay maaaring gumawa, magpalit ng pangalan, at magtanggal ng mga mailbox at maglipat ng mga mensahe sa pagitan ng mga mailbox. Maaari mo ring gamitin ang IMAP4 Access Control List (ACL) Extension (RFC 4314) upang kontrolin ang mga karapatan sa pag-access sa mailbox.
Ang paghahanap ng mga mensahe ay nangyayari sa gilid ng server. Ang IMAP4 ay may tahasang mekanismo ng extension.
Mga pamamaraan ng anti-spam
Ang mga modernong spam mail ay ipinamamahagi sa daan-daang libong kopya sa loob lamang ng ilang sampu-sampung minuto. Kadalasan, dumarating ang spam sa pamamagitan ng mga nahawahan malware Ang mga computer ng gumagamit ay mga network ng zombie. Ano ang maaaring kontrahin sa pagsalakay na ito? Ang modernong industriya ng seguridad ng IT ay nag-aalok ng maraming solusyon, at ang mga anti-spammers ay may iba't ibang teknolohiya sa kanilang arsenal. Gayunpaman, wala sa mga umiiral na teknolohiya ay hindi isang magic na "silver bullet" laban sa spam. Pangkalahatang solusyon wala lang. Karamihan sa mga modernong produkto ay gumagamit ng maraming teknolohiya, kung hindi, ang pagiging epektibo ng produkto ay hindi magiging mataas.
DNSBL
DNSBL - DNS blacklist o DNS blocklist - mga listahan ng mga host na nakaimbak gamit ang DNS architecture system. Karaniwang ginagamit upang labanan ang spam. Ina-access ng mail server ang DNSBL at sinusuri ito para sa IP address ng kliyente kung saan ito nakakatanggap ng mensahe. Kung ang sagot ay positibo, ito ay itinuturing na isang pagtatangka upang makatanggap ng isang spam na mensahe. Ang nagpapadalang server ay tumatanggap ng 5xx error (fatal error) at ang mensahe ay hindi tinatanggap. Lumilikha ang mail server ng nagpadala ng "bounce receipt" sa nagpadala na nagsasaad na hindi naihatid ang mail.
Mayroong 2 paraan ng paggamit ng teknolohiyang ito.
1. Hindi malabo na pagharang - pagtanggi sa mga mensahe na nagmula sa isang IP address na matatagpuan sa DNSBL
2. Isang balanseng diskarte. Sa diskarteng ito, isang mensahe na nagmumula sa isang IP address
na matatagpuan sa DNSBL ay hindi naka-block, ngunit ang katotohanang ito ay isinasaalang-alang kapag inuuri ang "spam" ng liham.
Kapag ginagamit ang unang diskarte, ang lahat ng mga titik mula sa mga IP address na kasama sa DNSBL ay malinaw na tinatanggihan. Hindi alintana kung ang IP address ay karapat-dapat na naka-blacklist o hindi sinasadya (na nagiging mas karaniwan sa pagsasanay). Ang paggamit ng pangalawang diskarte ay perpektong inilalarawan ng opensource spam filter na spamassassin. Kapag ang isang may timbang na diskarte ay ginamit upang pag-uri-uriin ang isang mensahe, iyon ay, pagsusuri batay sa maraming pamantayan. Sa kasong ito, ang pagkakaroon ng IP address ng nagpadala sa blacklist ay hindi lamang ang nagreresultang salik na nakakaimpluwensya sa desisyon sa pag-uuri ng mensahe, na nangangahulugan naman ng pagbawas sa bilang ng mga false filter positive sa mga kaso kung saan ang IP address ng nagpadala ay blacklisted sa pamamagitan ng isang walang katotohanan na aksidente .
Kontrol ng masa
Kasama sa teknolohiya ang pagtukoy sa daloy ng mail mga mensahe ng masa, na ganap na magkapareho o bahagyang naiiba. Upang makabuo ng isang gumaganang "mass" analyzer, ang malalaking daloy ng mail ay kinakailangan, kaya ang teknolohiyang ito ay inaalok malalaking tagagawa, pagkakaroon ng malalaking volume ng mail na maaari nilang suriin.
Mga kalamangan: Kung gumana ang teknolohiya, garantisadong matutuklasan ang mga mass mailing.
Mga Kakulangan: Una, ang isang "malaking" pag-mail ay maaaring hindi spam, ngunit medyo lehitimong mail (halimbawa, Ozon.ru, Subscribe.ru ay nagpapadala ng libu-libong halos magkaparehong mga mensahe, ngunit hindi ito spam). Pangalawa, alam ng mga spammer kung paano "masira" ang naturang proteksyon gamit ang mga matatalinong teknolohiya. Gumagamit sila ng software na bumubuo ng iba't ibang nilalaman - teksto, graphics, atbp. - sa bawat spam
