Электрондық поштаны жіберу протоколы: SMTP негіздері

Кіріспе

Электрондық поштаны жіберу үшін қолданылатын Интернет протоколы. Simple Mail Transfer Protocol (SMTP) – электрондық поштаны тарату бойынша Интернет стандартты коммуникациялық протоколы. Пошта серверлері және басқа да хабар алмасу агенттері SMTP-ді хабарламаларды жіберу және қабылдау үшін пайдаланады. Пайдаланушы деңгейіндегі электрондық пошта клиенттері көбінесе SMTP-ді тек хабарламаларды пошта серверіне жіберу үшін қолданады және шығатын электрондық поштаны әдетте 587 немесе 465 порт арқылы пошта серверіне жібереді. Хабарларды алу үшін IMAP (ескі POP3-тің орнын бастан кешірген) стандартты болып табылады, бірақ жеке серверлер де көбінесе жеке протоколдарды іске асырады, мысалы, Exchange ActiveSync. SMTP 1980 жылы пайда болды, бұл 1971 жылдан бері ARPANET-те іске асырылған идеяларға негізделген. Ол көп рет жаңартылып, өзгертіліп, кеңейтілді. Қазіргі кезде қолданылып жүрген протокол нұсқасы аутентификация, шифрлау, бинарлық деректерді жіберу және халықаралық электрондық пошта мекенжайлары үшін түрлі кеңейтулермен кеңейтілген құрылымға ие. SMTP серверлері көбінесе 25 портта (жай мәтін үшін) және 587 портта (шифрланған байланыс үшін) Трансмиссиялық басқару протоколын қолданады.

SMTP-нің алдыңғылары

1960 жылдары бір-бірден электрондық хабар алмасудың әртүрлі нысандары қолданылды. Пайдаланушылар арнайы үлкен компьютерлер үшін жасалған жүйелер арқылы байланыс жасады. Көптеген компьютерлер өзара байланысқан сайын, әсіресе АҚШ үкіметінің ARPANET желісінде, түрлі операциялық жүйелер арасында хабар алмасуға мүмкіндік беретін стандарттар әзірленді. ARPANET-тегі электрондық поштаның тамыры 1971 жылға дейін жетеді: Mail Box протоколы іске асырылмағанмен талқыланды; ал BBN компаниясының Рей Томлинсон сол жылы ARPANET желісіндегі екі компьютерге хабар жіберу үшін SNDMSG бағдарламасын бейімдеді. Пошта протоколына қатысты тағы бір ұсыныс 1973 жылдың маусым айында RFC 524 құжатында жасалды, бірақ ол да іске асырылмады. 1973 жылдың наурыз айында RFC 469 құжатында ARPANET желісінде "желілік пошта" үшін Файлдарды жіберу протоколын (FTP) пайдалану ұсынылды. RFC 561, RFC 680, RFC 724 және, соңында, 1977 жылдың қараша айында RFC 733 арқылы FTP пошта серверлерін қолдана отырып, "электрондық пошта" үшін бірыңғай стандартталған жүйе құрылды. SMTP осы 1970 жылдардағы стандарттардың негізінде дамыды.

SMTP-нің түпнұсқасы

1980 жылы Джон Постель мен Сюзанн Слюйзер пошта үшін FTP пайдаланудың орнына поштаны беру протоколын ұсынды. 1981 жылдың мамыр айындағы нұсқау FTP-ге қатысты барлық сілтемелерді жойды және TCP және UDP үшін 57 портты бөлді, бірақ бұл бөлу кейіннен IANA тарапынан алынып тасталды. 1981 жылдың қарашасында Постель "Қарапайым поштаны беру протоколы" деген мақала жариялады. SMTP стандарты шамамен Usenet тұсында, бірнеше ұқсастықтары бар, көпке таралатын коммуникациялық желі ретінде әзірленді. SMTP 1980-жылдардың басында кеңінен қолданысқа енді. Сол кезде ол Unix-тен Unix-ке көшіру бағдарламасына (UUCP) толықтыру болды, ол үзілістермен байланысатын машиналар арасында электрондық поштаны басқаруға арналған. Ал SMTP жіберуші және қабылдаушы машиналар желіге үздіксіз қосылғанда тиімді жұмыс істейді. Екеуі де сақтау және жіберу механизмін қолданды және түрткілеу технологиясының мысалдары болып табылады. Usenet жаңалық топтары серверлер арасында UUCP арқылы таралғанымен, UUCP пошта тасымалы ретінде және хабарды бағыттау үшін қолданылған "банг жолдарымен" бірге дерлік жоғалып кетті. 1983 жылы 4.1cBSD нұсқасымен бірге шығарылған Sendmail, SMTP-ді іске асырған алғашқы пошта тасымалдау агенттерінің бірі болды. BSD Unix Интернеттегі ең танымал операциялық жүйеге айналған сайын, Sendmail ең көп таралған MTA (пошта тасымалдау агенті) болды. Бастапқы SMTP протоколы тек аутентификацияланбаған, шифрланбаған 7 биттік ASCII мәтіндік байланысты қолдады, ол ортадағы адамның шабуылына, жалған ақпарат таратуға және спамға осал болды, сондай-ақ кез келген екілік деректерді жібермес бұрын оқылмалы мәтінге түрлендіруді қажет етті. Тиісті аутентификация механизмі болмағандықтан, әр SMTP сервері бастапқыда ашық пошта релесі болып құрылған. Интернет пошта консорциумы (IMC) 1998 жылы пошта серверлерінің 55% ашық релелер екенін, ал 2002 жылы 1% -дан аспайтынын хабарлады. Спамдық алаңдауларға байланысты көптеген электрондық пошта провайдерлері ашық релелерді блоктайды, бұл бастапқы SMTP-ді Интернетте жалпы пайдалану үшін тиімсіз етеді.

Қазіргі заманғы SMTP

1995 жылдың қараша айында кеңейтілген қарапайым пошта беру протоколы (ESMTP) анықталды, ол барлық қолданыстағы және болашақ кеңейтулер үшін жалпы құрылымды қалыптастырды, оның мақсаты бастапқы SMTP-де болмаған мүмкіндіктерді қосу еді. ESMTP клиенттер мен серверлерді анықтаудың және серверлер қолдайтын кеңейтулерді көрсетудің біркелкі және басқарылатын тәсілдерін анықтайды. Хабарлама жіберу және SMTP AUTH 1998 және 1999 жылдары енгізілді, екеуі де электрондық поштаны жеткізудегі жаңа бағыттарды сипаттайды. Алғашқыда SMTP серверлері әдетте ұйымның ішкі бөлігінде орналасқан, ұйымға сырттан пошта қабылдап, ұйымнан сыртқа хабарламалар жіберген. Бірақ уақыт өте келе SMTP серверлері (пошта беру агенттері) өз рөлдерін кеңейтіп, пошта пайдаланушыларының агенттеріне хабарлама жіберу агенттеріне айналды, олардың кейбіреулері енді ұйымның сыртынан поштаны қайта жіберді (мысалы, компания басшысы сапарда корпоративтік SMTP серверін пайдаланып электрондық пошта жібергісі келеді). Бұл мәселе, World Wide Web-тің жылдам өсуі мен танымалдылығының салдарынан, SMTP-ге поштаны қайта жіберу және пайдаланушыларды аутентификациялау үшін арнайы ережелер мен әдістерді енгізуді қажет етті, бұл қажетсіз электрондық поштаны (спам) қайта жіберу сияқты теріс пайдалануды болдырмау үшін қажет болды. Хабарлама жіберу жұмысы бастапқыда басталды, себебі танымал пошта серверлері жиі хабарламаларды түзету мақсатында қайта жазатын, мысалы, жарамсыз мекенжайға домендік атау қосатын. Бұл әрекет хабарлама бастапқыда жіберілген кезде пайдалы болса, бірақ хабарлама басқа жерден келгенде және қайта жіберілгенде қауіпті және зиянды болар еді. Поштаны жіберу және қайта жіберуді бөліп қарастыру, қайта жіберуді қайта жазуға тыйым салғанда жіберуді қайта жазуға рұқсат беру және ынталандыру мақсатында қарастырылды. Спам кеңіне тараған сайын, бұл ұйымнан жіберілетін поштаға рұқсат берудің және оны іздеудің де бір жолы ретінде қарастырылды. Осы қайта жіберу мен жіберудің ажыратылуы заманауи электрондық пошта қауіпсіздігі практикасының негізіне айналды. Бұл протокол бастапқыда тек ASCII мәтініне негізделгендіктен, екілік файлдармен немесе көптеген емес-ағылшын тілдеріндегі таңбалармен жақсы жұмыс істемеді. SMTP арқылы беру үшін екілік файлдарды кодтау үшін көп мақсатты Интернет пошта кеңейтімдері (MIME) сияқты стандарттар әзірленді. Sendmail-ден кейін жасалған пошта беру агенттері (MTA) көбінесе 8 биттік таза күйде іске асырылды, сондықтан кез келген 8 биттік ASCII сияқты таңба кодтауындағы мәтіндік деректерді SMTP арқылы жіберу үшін «сегізін ғана жібер» деген баламалы стратегияны қолдануға болады. Сатушылар арасындағы әртүрлі таңба жиынтығы сәйкестендірілуіне байланысты Mojibake мәселесі әлі де болды, бірақ электрондық пошта мекенжайларының өзі ASCII-ге ғана рұқсат берді. Бүгінгі таңда 8 биттік таза MTA көбінесе 8BITMIME кеңейтімдерін қолдайды, бұл кейбір екілік файлдарды жай мәтіндей оңай жіберуге мүмкіндік береді (жол ұзындығы мен рұқсат етілген октеттердегі мәндерге шектеулер әлі де қолданылады, сондықтан көптеген мәтін емес деректер мен кейбір мәтіндік форматтар үшін MIME кодтамасы қажет). 2012 жылы UTF 8 мәтінін қолдау үшін SMTPUTF8 кеңейтімі құрылды, бұл халықаралық мазмұнға және латын емес жазу жүйелеріндегі (мысалы, кириллица немесе қытай) мекенжайларға мүмкіндік берді. SMTP негізгі ерекшеліктеріне көптеген адамдар үлес қосты, олардың ішінде Джон Постель, Эрик Оллман, Дейв Крокер, Нед Фрид, Рэндалл Гелленс, Джон Кленсин және Кит Мур болды.

In November 1995, defined Extended Simple Mail Transfer Protocol (ESMTP), which established a general structure for all existing and future extensions which aimed to add in the features missing from the original SMTP. ESMTP defines consistent and manageable means by which ESMTP clients and servers can be identified and servers can indicate supported extensions. Message submission and SMTP AUTH were introduced in 1998 and 1999, both describing new trends in email delivery. Originally, SMTP servers were typically internal to an organization, receiving mail for the organization from the outside, and relaying messages from the organization to the outside. But as time went on, SMTP servers (mail transfer agents), in practice, were expanding their roles to become message submission agents for mail user agents, some of which were now relaying mail from the outside of an organization. (e. g. a company executive wishes to send email while on a trip using the corporate SMTP server.) This issue, a consequence of the rapid expansion and popularity of the World Wide Web, meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email (spam). Work on message submission was originally started because popular mail servers would often rewrite mail in an attempt to fix problems in it, for example, adding a domain name to an unqualified address. This behavior is helpful when the message being fixed is an initial submission, but dangerous and harmful when the message originated elsewhere and is being relayed. Cleanly separating mail into submission and relay was seen as a way to permit and encourage rewriting submissions while prohibiting rewriting relay. As spam became more prevalent, it was also seen as a way to provide authorization for mail being sent out from an organization, as well as traceability. This separation of relay and submission quickly became a foundation for modern email security practices. As this protocol started out purely ASCII text based, it did not deal well with binary files, or characters in many non English languages. Standards such as Multipurpose Internet Mail Extensions (MIME) were developed to encode binary files for transfer through SMTP. Mail transfer agents (MTAs) developed after Sendmail also tended to be implemented 8 bit clean, so that the alternate "just send eight" strategy could be used to transmit arbitrary text data (in any 8 bit ASCII like character encoding) via SMTP. Mojibake was still a problem due to differing character set mappings between vendors, although the email addresses themselves still allowed only ASCII. 8 bit clean MTAs today tend to support the 8BITMIME extension, permitting some binary files to be transmitted almost as easily as plain text (limits on line length and permitted octet values still apply, so that MIME encoding is needed for most non text data and some text formats). In 2012, the SMTPUTF8 extension was created to support UTF 8 text, allowing international content and addresses in non Latin scripts like Cyrillic or Chinese. Many people contributed to the core SMTP specifications, among them Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.

Поштаны өңдеу моделі

Электрондық поштаны пошта клиенті (пошта пайдаланушы агенті, MUA) пошта серверіне (пошта жіберу агенті, MSA) SMTP арқылы TCP 587 портында жібереді. Көптеген пошта жәшіктерінің провайдерлері әлі де дәстүрлі 25-ші порт арқылы жіберуге рұқсат береді. MSA поштаны өзінің пошта тасымалдау агентіне (MTA) жеткізеді. Көбінесе бұл екі агент бір машинада әртүрлі параметрлермен іске қосылған бір бағдарламалық жасақтаманың нұсқалары болып табылады. Жергілікті өңдеу бір машинада немесе бірнеше машиналар арасында бөлінеді; бір машинадағы пошта агенті процестері файлдарды бөлісе алады, бірақ егер өңдеу бірнеше машиналарда болса, олар SMTP арқылы бір-біріне хабарламалар жібереді, онда әрбір машина келесі машинаны «ақылды хост» ретінде пайдалану үшін конфигурацияланған. Әрбір процесс – бұл MTA (SMTP сервері) өздігінен. Шекаралық MTA DNS-ті алушының доменінің MX (пошта алмастырушы) жазбасын (электрондық пошта мекенжайының @ таңбасынан кейінгі бөлігі) іздеу үшін пайдаланады. MX жазбасында мақсатты MTA-ның атауы болады. Мақсатты хост пен басқа факторларға байланысты жіберуші MTA алушы серверді таңдайды және пошта алмасуды аяқтау үшін оған қосылады. Хабарды беру екі MTA арасындағы бір қосылым арқылы немесе аралық жүйелер арқылы бірнеше рет өтуі мүмкін. Қабылдаушы SMTP сервері соңғы пункт болуы мүмкін, аралық «релей» (яғни ол хабарламаны сақтайды және жібереді) немесе «гейтвей» (яғни ол хабарламаны SMTP-ден басқа протокол арқылы жіберуі мүмкін). 2.1-тарау бойынша, әрбір кезең – бұл хабарлама үшін жауапкершілікті ресми түрде беру, онда қабылдаушы сервер хабарламаны жеткізуі тиіс немесе жеткізе алмағаны туралы дұрыс хабарлауы керек. Соңғы кезең кіретін хабарламаны қабылдағаннан кейін оны жергілікті жеткізу үшін пошта жеткізу агентіне (MDA) жібереді. MDA хабарламаларды тиісті пошта жәшігі форматында сақтайды. Жіберу сияқты, бұл қабылдау бір немесе бірнеше компьютерлерді пайдалана отырып жасалуы мүмкін, бірақ жоғарыдағы схемада MDA пошта алмастырушы қораптың жанындағы бір қорап ретінде көрсетілген. MDA хабарламаларды тікелей сақтау орнына жеткізе алады немесе оларды SMTP немесе басқа протокол арқылы жібере алады, мысалы, жергілікті поштаны беру протоколы (LMTP), бұл мақсат үшін жасалған SMTP-нің туындысы. Жергілікті пошта серверіне жеткізілгеннен кейін пошта аутентификацияланған пошта клиенттері (MUA) арқылы жинақтап алу үшін сақталады. Поштаны соңғы пайдаланушы қолданбалары, электрондық пошта клиенттері деп аталады, олар Интернеттік хабарламаларды алу протоколы (IMAP) арқылы поштаға қол жеткізуді жеңілдетеді және сақталған поштаны басқарады, немесе дәстүрлі mbox пошта файл форматын немесе Microsoft Exchange/Outlook немесе Lotus Notes/Domino сияқты меншік жүйелерді пайдаланатын Пошта протоколы (POP) арқылы қол жеткізеді. Веб-пошта клиенттері кез келген әдісті пайдалана алады, бірақ алу протоколы көбінесе ресми стандарт емес. SMTP хабарламаның мазмұнын емес, хабарламаны тасымалдауды анықтайды. Осылайша, ол пошта конверті мен оның параметрлерін, мысалы, конверттің жіберушісін анықтайды, бірақ хабарламаның өзін немесе іздеу ақпаратын анықтамайды. STD 10 және SMTP (конверт) анықтайды, ал STD 11 және хабарламаны (бас және дене) анықтайды, бұл ресми түрде Интернеттік хабарлама форматы деп аталады.

Email is submitted by a mail client (mail user agent, MUA) to a mail server (mail submission agent, MSA) using SMTP on TCP port 587. Most mailbox providers still allow submission on traditional port 25. The MSA delivers the mail to its mail transfer agent (MTA). Often, these two agents are instances of the same software launched with different options on the same machine. Local processing can be done either on a single machine, or split among multiple machines; mail agent processes on one machine can share files, but if processing is on multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a smart host. Each process is an MTA (an SMTP server) in its own right. The boundary MTA uses DNS to look up the MX (mail exchanger) record for the recipient's domain (the part of the email address on the right of @). The MX record contains the name of the target MTA. Based on the target host and other factors, the sending MTA selects a recipient server and connects to it to complete the mail exchange. Message transfer can occur in a single connection between two MTAs, or in a series of hops through intermediary systems. A receiving SMTP server may be the ultimate destination, an intermediate "relay" (that is, it stores and forwards the message) or a "gateway" (that is, it may forward the message using some protocol other than SMTP). Per section 2.1, each hop is a formal handoff of responsibility for the message, whereby the receiving server must either deliver the message or properly report the failure to do so. Once the final hop accepts the incoming message, it hands it to a mail delivery agent (MDA) for local delivery. An MDA saves messages in the relevant mailbox format. As with sending, this reception can be done using one or multiple computers, but in the diagram above the MDA is depicted as one box near the mail exchanger box. An MDA may deliver messages directly to storage, or forward them over a network using SMTP or other protocol such as Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed for this purpose. Once delivered to the local mail server, the mail is stored for batch retrieval by authenticated mail clients (MUAs). Mail is retrieved by end user applications, called email clients, using Internet Message Access Protocol (IMAP), a protocol that both facilitates access to mail and manages stored mail, or the Post Office Protocol (POP) which typically uses the traditional mbox mail file format or a proprietary system such as Microsoft Exchange/Outlook or Lotus Notes/Domino. Webmail clients may use either method, but the retrieval protocol is often not a formal standard. SMTP defines message transport, not the message content. Thus, it defines the mail envelope and its parameters, such as the envelope sender, but not the header (except trace information) nor the body of the message itself. STD 10 and define SMTP (the envelope), while STD 11 and define the message (header and body), formally referred to as the Internet Message Format.

Хаттаманың жалпы көрінісі

SMTP – байланыс бағытындағы, мәтіндік негізделген протокол, онда электрондық пошта жөнелтуші электрондық пошта алушымен командалар тізбегін орындау арқылы, сенімді реттелген деректер ағыны арнасы арқылы қажетті деректерді жібереді, әдетте, Трансмиссиялық бақылау протоколы (TCP) қосылымы арқылы. SMTP сессиясы SMTP клиенті (бастамалаушы агент, жөнелтуші немесе таратушы) шығарған командалардан және SMTP серверінен (тыңдаушы агент немесе қабылдаушы) тиісті жауаптардан тұрады, осылайша сессия ашылады және сессия параметрлері алмастырылады. Сессияда нөл немесе одан көп SMTP транзакциялары болуы мүмкін. SMTP транзакциясы үш команда/жауап тізбегінен тұрады: MAIL командасы – қайтару мекенжайын орнату үшін, сондай-ақ қайтару жолы, кері жол, қайтару адресі, mfrom немесе конверт жөнелтушісі деп аталады. Хабардың алушысын белгілеу үшін RCPT командасы. Бұл команда әр алушыға бірнеше рет берілуі мүмкін, әр алушы үшін бір рет. Бұл мекенжайлар да конверттің бір бөлігі болып табылады. DATA – хабарлама мәтінінің басталуын білдіреді; хабарламаның мазмұны, конвертіне қарағанда. Ол бос жолмен бөлінген хабарлама тақырыбы мен хабарлама денесінен тұрады. DATA – бұл командалар жиынтығы, ал сервер екі рет жауап береді: бір рет DATA командасына, мәтінді қабылдауға дайын екенін растау үшін, екінші рет деректер тізбегі аяқталғаннан кейін, хабарламаны қабылдау немесе қабылдамау үшін. DATA үшін аралық жауаптан басқа, әр сервердің жауабы оң (2xx жауап кодтары) немесе теріс болуы мүмкін. Теріс жауаптар тұрақты (5xx кодтары) немесе уақытша (4xx кодтары) болуы мүмкін. Қабылдамау – бұл тұрақты сәтсіздік және клиент оны алған серверге қайтару хабарламасын жіберуі керек. Тастау – бұл хабарламаны жеткізудің орнына жою арқылы берілетін оң жауап. Бастамалаушы хост, SMTP клиенті, тиісті сессияда электрондық поштаны тарату үшін SMTP клиенті ретінде әрекет ететін, электрондық пошта пайдаланушысының агенті (MUA) ретінде функционалдық тұрғыдан анықталған, немесе ретрансляциялық сервердің электрондық поштаны беру агенті (MTA) ретінде SMTP сервері болуы мүмкін. Толық мүмкіндікке ие SMTP серверлері уақытша сәтсіздіктерге әкелген хабарламаларды қайта жіберу үшін хабарламалар тізімін сақтайды. MUA шығыс электрондық пошта SMTP серверін оның конфигурациясынан біледі. Ретрансляциялық сервер әдетте әр алушының домендік атауы үшін MX (Mail eXchange) DNS ресурс жазбасын қарап, қай серверге қосылу керектігін анықтайды. Егер MX жазба табылмаса, сәйкес ретрансляциялық сервер (барлығы емес) оның орнына A жазбасын қарастырады. Ретрансляциялық серверлерді «жақсы танылған портта» SMTP үшін: 25-портта немесе MSA-ға қосылу үшін 587-портта серверге TCP қосылымын бастау үшін конфигурациялауға болады. MTA мен MSA арасындағы басты айырмашылық – MSA-ға қосылу үшін SMTP аутентификациясы қажет.

SMTP is a connection oriented, text based protocol in which a mail sender communicates with a mail receiver by issuing command strings and supplying necessary data over a reliable ordered data stream channel, typically a Transmission Control Protocol (TCP) connection. An SMTP session consists of commands originated by an SMTP client (the initiating agent, sender, or transmitter) and corresponding responses from the SMTP server (the listening agent, or receiver) so that the session is opened, and session parameters are exchanged. A session may include zero or more SMTP transactions. An SMTP transaction consists of three command/reply sequences:

MAIL command, to establish the return address, also called return path, reverse path, bounce address, mfrom, or envelope sender. RCPT command, to establish a recipient of the message. This command can be issued multiple times, one for each recipient. These addresses are also part of the envelope. DATA to signal the beginning of the message text; the content of the message, as opposed to its envelope. It consists of a message header and a message body separated by an empty line. DATA is actually a group of commands, and the server replies twice: once to the DATA command itself, to acknowledge that it is ready to receive the text, and the second time after the end of data sequence, to either accept or reject the entire message. Besides the intermediate reply for DATA, each server's reply can be either positive (2xx reply codes) or negative. Negative replies can be permanent (5xx codes) or transient (4xx codes). A reject is a permanent failure and the client should send a bounce message to the server it received it from. A drop is a positive response followed by message discard rather than delivery. The initiating host, the SMTP client, can be either an end user's email client, functionally identified as a mail user agent (MUA), or a relay server's mail transfer agent (MTA), that is an SMTP server acting as an SMTP client, in the relevant session, in order to relay mail. Fully capable SMTP servers maintain queues of messages for retrying message transmissions that resulted in transient failures. A MUA knows the outgoing mail SMTP server from its configuration. A relay server typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name. If no MX record is found, a conformant relaying server (not all are) instead looks up the A record. Relay servers can also be configured to use a smart host. A relay server initiates a TCP connection to the server on the "well known port" for SMTP: port 25, or for connecting to an MSA, port 587. The main difference between an MTA and an MSA is that connecting to an MSA requires SMTP Authentication.

SMTP және поштаны қайтару

SMTP – тек жеткізу протоколы. Әдетте, пошта келген кезде мақсатты пошта серверіне (немесе келесі хоп пошта серверіне) "жіберіледі". Пошта адресаттың жеке пайдаланушысына емес, мақсатты серверге сәйкес маршрутталды. Пошта протоколы (POP) және Интернеттік хабарламаға қол жеткізу протоколы (IMAP) сияқты басқа протоколдар жеке пайдаланушылар хабарламаларды алу және пошта жәшіктерін басқару үшін арнайы жасалған. Үзілісті қосылған пошта сервері қашық серверден қажет болғанда хабарламаларды алуы үшін SMTP қашық серверде пошта кезегін өңдеуді бастау мүмкіндігіне ие (төменде Қашық хабарлама кезегін бастау бөлімін қараңыз). POP және IMAP үзілісті қосылған машиналар арқылы поштаны жіберуге жарамсыз протоколдар болып табылады; олар пошта релесінің дұрыс жұмыс істеуі үшін маңызды ақпарат ("пошта конверті") алынып тасталғаннан кейін, соңғы жеткізілімнен кейін жұмыс істеуге арналған.

Қашықтан хабарлар кезегінің басталуы

Қашықтан хабарлар тізімін іске қосу, қашық хостқа сервердегі хабарлар тізімін өңдеуді бастауға мүмкіндік береді, осылайша ол өзіне жолталған хабарларды тиісті команданы жіберу арқылы ала алады. Алғашқы TURN командасы қауіпсіз емес деп танылды және домендік атаулар жүйесі ақпаратына негізделген аутентификация әдісін пайдаланатын, одан да қауіпсіз ETRN командасымен толықтырылды.

Шығыс пошта SMTP сервері

Электрондық пошта клиенті бастапқы SMTP серверінің IP-мекенжайын білуі керек, және бұл ақпарат конфигурациясының бір бөлігі ретінде берілуі тиіс (көбінесе DNS атауы түрінде). Бұл сервер пайдаланушы үшін шығыс хабарламаларды жібереді.

Шығыс пошта серверіне кіруді шектеу

Сервер әкімшілері серверді пайдаланатын клиенттерге белгілі бір бақылау қоюы керек. Бұл оларға, мысалы, спам сияқты зиянды әрекеттермен күресуге мүмкіндік береді. Екі шешім жиі қолданылады:

Бұрын көптеген жүйелер клиенттің орналасқан жеріне байланысты пайдалану шектеулерін енгізді, тек сервер әкімшілері басқаратын IP-адреске ие клиенттерге ғана пайдалануға рұқсат берді. Басқа клиенттердің IP-адрестерінен пайдалануға тыйым салынды. Қазіргі заманғы SMTP серверлері әдетте клиенттерге қолжетімділік беру алдында куәліктер арқылы өтеуді талап ететін балама жүйені ұсынады.

Орналасуы бойынша кіруді шектеу

Бұл жүйе бойынша, провайдердің (ISP) SMTP сервері провайдер желісінен тыс пайдаланушыларға кіруге рұқсат бермейді. Нақтырақ айтқанда, сервер тек провайдер берген IP-адресі бар пайдаланушыларға ғана кіруге рұқсат етеді, бұл олардың сол провайдер арқылы интернетке қосылуын талап етумен бірдей. Мобильді пайдаланушы көбінесе әдеттегі провайдерінен басқа желіде болуы мүмкін, содан кейін электрондық пошта жіберу мүмкін болмайды, себебі орнатылған SMTP серверінің таңдауы енді қолжетімді емес. Бұл жүйенің бірнеше түрі бар. Мысалы, ұйымның SMTP сервері тек сол желідегі пайдаланушыларға ғана қызмет көрсетеді, бұл кең интернеттен кіруді бұғаттау үшін брандмауэрді пайдалану арқылы қамтамасыз етіледі. Сервер клиенттің IP-адресінің диапазонын тексеруді де жүзеге асыруы мүмкін. Мұндай әдістерді әдетте корпорациялар мен университеттер сияқты мекемелер қолданды, олар ұйым ішінде ғана қолдануға арналған SMTP серверін шығыс пошта үшін ұсынды. Дегенмен, қазіргі кезде осы мекемелердің көпшілігі клиентті аутентификациялау әдістерін қолданады. Пайдаланушы мобильді болғанда және интернетке қосылу үшін әртүрлі провайдерлерді пайдаланатын болса, мұндай шектеулер қиындық тудырады, ал орнатылған шығыс электрондық пошта SMTP серверінің мекенжайын өзгерту ыңғайсыз. Электрондық пошта клиентінің конфигурациялық ақпаратының өзгеруін қажет етпейтін мүмкіндікке ие болу өте қажет.

Клиенттің аутентификациясы

Қазіргі заманғы SMTP серверлері, әдетте, бұрын сипатталғандай, орналасуы бойынша шектеу қоймай, кіруге рұқсат беру үшін клиенттерді сенімхаттар арқылы аутентификациялауды талап етеді. Бұл икемді жүйе мобильді пайдаланушыларға қолайлы келеді және оларға орнатылған шығыс SMTP серверін таңдау мүмкіндігін береді. SMTP аутентификациясы, көбінесе SMTP AUTH деп қысқартылады, – аутентификация механизмін қолданып кіру үшін SMTP-ның кеңейтілген нұсқасы.

Бинарлық деректер беру

Түпнұсқа SMTP тек бір ASCII мәтіндік бөлікті ғана қолдайды, сондықтан кез келген екілік деректерді жіберу алдында хабарламаның осы бөлігінде мәтін ретінде кодтау қажет, ал алушы оны кодтан шығарады. uuencode және BinHex сияқты екілікті мәтінге айналдыру әдістері әдетте қолданылды. Осы мәселені шешу үшін 8BITMIME командасы жасалды. Ол 1994 жылы стандартталды және жеті биттік ASCII таңбалар жиынтығынан тыс октеттерді қамтитын электрондық пошта хабарламаларын MIME мазмұны бөліктері ретінде, әдетте Base64 арқылы кодтау арқылы ашық алмасуды жеңілдетеді.

Талап бойынша пошта тарату

Сұраныс бойынша пошта релейі (ODMR) – бұл SMTP сервері үзілісті түрде қосылған кезде, оған кезекте сақталған электрондық поштаны қабылдауға мүмкіндік беретін, стандартталған SMTP кеңейтуі.

Халықаралықласуды кеңейту

SMTP тек ASCII таңбаларынан тұратын электрондық пошта мекенжайларын қолдайды, бұл латын әліпбиіне негізделмеген немесе ASCII таңбалар жиынтығында жоқ диакритикалық белгілерді пайдаланатын қолданушылар үшін қолайсыздық тудырады. Бұл шектеу адрестік атауларда UTF-8 қолдауын қамтамасыз ететін кеңейтулер арқылы азайтылды. Эксперименттік нұсқасы енгізілді. Қазіргі қолдау шектеулі, бірақ Қытай сияқты, латын (ASCII) шетелдік жазу жүйесі болып табылатын және үлкен қолданушылар базасына ие елдерде осы RFC және оған байланысты RFC-терді кеңінен қабылдауға зор қызығушылық бар.

SMTP-AUTH

SMTP AUTH кеңейтуі кіруді бақылау механизмін ұсынады. Ол клиенттің электрондық пошта жіберу процесінде электрондық пошта серверіне сәтті кіруін қамтамасыз ететін аутентификация қадамынан тұрады. SMTP AUTH қолдауын көрсететін серверлерді әдетте клиенттерден осы кеңейтуді пайдалануды талап ету үшін конфигурациялауға болады, бұл жіберушінің нақты кім екенін анықтауға мүмкіндік береді. SMTP AUTH кеңейтуі тікелей SMTP AUTH құжатында сипатталған. Оны заңды пайдаланушыларға электрондық поштаны ретрансляциялауға рұқсат беру үшін, ал спамдер сияқты рұқсатсыз пайдаланушыларға ретрансляциялау қызметін жою үшін пайдалануға болады. Бұл электрондық пошта конвертінің жіберушісінің немесе "From:" тақырыбының дұрыстығына кепілдік бермейді. Мысалы, бір жіберушінің өзін басқа біреу ретінде көрсетуі, егер сервер SMTP AUTH арқылы аутентификацияланған пайдаланушыға рұқсат етілген мекенжайларға ғана хабарлама жіберуге мүмкіндік бермей конфигурацияланбаса, әлі де мүмкін. SMTP AUTH кеңейтуі сонымен қатар бір электрондық пошта серверіне басқа серверге электрондық поштаны ретрансляциялау кезінде жіберушінің аутентификацияланғанын көрсетуге мүмкіндік береді. Әдетте, бұл қабылдаушы сервердің жіберуші серверге сенуін қажет етеді, сондықтан SMTP AUTH-тің осы аспектісі Интернетте көбінесе қолданылмайды.

Қауіпсіздік кеңейтулері

Пошта жеткізу қарапайым мәтін арқылы да, шифрланған байланыс арқылы да жүзеге асуы мүмкін, бірақ қарым-қатынас жасайтын тараптар екінші тараптың қауіпсіз каналды қолдану мүмкіндігін алдын ала білмейді.

STARTTLS немесе "Оппортунистикалық TLS"

STARTTLS кеңейтулері SMTP серверлеріне қосылатын клиенттерге TLS шифрланған байланысты қолдайтынын хабарлауға және клиенттерге STARTTLS командасын жіберіп, қосылысын жаңарту мүмкіндігін беруге мүмкіндік береді. Кеңейтуді қолдайтын серверлер оны іске асырудың өзінен ешқандай қауіпсіздік пайдасын алмайды, себебі TLS шифрланған сессияға жаңарту қосылатын клиенттің осы мүмкіндікті пайдалануына байланысты, сондықтан бұл «мүмкіндік тілеулі TLS» деп аталады. STARTTLS тек пассивті бақылау шабуылдарына қарсы тиімді, себебі STARTTLS келіссөздері қарапайым мәтінде жүзеге асады және белсенді шабуылшы STARTTLS командаларын оңай алып тастай алады. Ортадағы адамның осы түрі кейде STRIPTLS деп аталады, онда шифрлау келіссөздерінің ақпараты бір жақтан екінші жаққа жетпейді. Мұндай жағдайда екі тарап та жарамсыз немесе күтпеген жауаптарды екінші тарап STARTTLS-ты дұрыс қолдамайтынының белгісі ретінде қарастырады, нәтижесінде дәстүрлі қарапайым мәтіндік электрондық пошта қолданылады. STARTTLS IMAP және POP3 үшін басқа RFC-лерде де анықталғанын ескеріңіз, бірақ бұл протоколдар басқа мақсаттарға қызмет етеді: SMTP хабар алмасу агенттері арасындағы байланыс үшін қолданылады, ал IMAP және POP3 – соңғы клиенттер мен хабар алмасу агенттері үшін. 2014 жылы Electronic Frontier Foundation «STARTTLS Everywhere» жобасын бастады, ол «HTTPS Everywhere» тізіміне ұқсас, сенімді тараптарға алдын ала байланыссыз қауіпсіз байланысты қолдайтын басқаларын табуға мүмкіндік берді. Жоба 2021 жылдың 29 сәуірінде жаңа ұсыныстарды қабылдауды тоқтатты және EFF әріптестердің TLS қолдауын анықтау үшін DANE және MTA STS-ке көшуді ұсынды. қарапайым мәтінді ескірген деп жариялады және электрондық хатты жіберу және алу үшін әрқашан TLS қолдануды, сондай-ақ имплицитті TLS порттарын қосуды ұсынады.

SMTP үшін DANE

пошта серверінің шифрлау қабілеттерін жариялауға мүмкіндік берілді. DNSSEC пайдаланып, пошта сервері операторлары өздерінің TLS сертификатының хэшін жариялай алады, соның арқасында шифрланбаған байланыс мүмкіндігі төмендетіледі. Microsoft 2024 жылдың соңына дейін Exchange Online клиенттері үшін толық SMTP DANE қолдауын іске қосады деп күтеді.

SMTP MTA қатаң тасымалдау қауіпсіздігі

"SMTP MTA Strict Transport Security (MTA STS)" деп аталатын 2018 жылғы жаңа стандарт, белсенді шабуылдамашылар мәселесін шешуге бағытталған. Ол пошта серверлеріне сервердегі белгілі бір файлдарда және DNS TXT жазбаларында қауіпсіз байланыс арналарын қолдауға дайын екенін жариялауға мүмкіндік беретін протоколды анықтайды. Сенетін тарап мұндай жазбаның бар екенін үнемі тексеретін болады, оны жазбада көрсетілген мерзімге сақтайды және жазбаның мерзімі біткенше қауіпсіз емес арналар арқылы байланыс жасамайды.

SMTP TLS-ті есепке алу

Хабарларды қауіпсіз жеткізуге арналған протоколдар, қате конфигурациялар немесе қасақана белсенді араласу салдарынан сәтсіздікке ұшырауы мүмкін, нәтижесінде хабарламалар жеткізілмей қалуы немесе шифрланбаған немесе расталмаған арналар арқылы жіберілуі мүмкін. "SMTP TLS Reporting" қабылдаушы домендермен статистикалық мәліметтерді және ықтимал сәтсіздіктер туралы нақты ақпаратты бөлісуге арналған есеп беру механизмі мен форматын сипаттайды. Қабылдаушы домендер осы ақпаратты әлеуетті шабуылдарды анықтау және кездейсоқ қате конфигурацияларды диагностикалау үшін пайдалана алады. 2019 жылдың сәуірінде Google Mail SMTP TLS Reporting қолдауын жариялады. DomainKeys Identified Mail, Sender Policy Framework және DMARC, DNSBL және күдікті электрондық поштаны қабылдаудан бас тарту немесе карантинге алу үшін сұр тізімдеу.