Электрондық пошта жіберу агенттері: MTA және MSA функцияларының айырмашылықтары
Message submission agent
Почтовый агент передачи (MSA) қабылдайды электрондық хабарламаларды, ESMTP арқылы жіберуге көмектеседі. 587 порт нөмірімен жұмыс істейді, MTA-дан өзгеше.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Хабарды жіберу агенті (MSA) немесе поштаны жіберу агенті – электрондық пошта хабарламаларын пошта пайдаланушы агентінен (MUA) қабылдайтын және поштаны жеткізу үшін поштаны беру агентімен (MTA) өзара іс-қимыл жасайтын компьютерлік бағдарлама немесе бағдарламалық агент. Ол RFC 6409 стандартында сипатталған Simple Mail Transfer Protocol (SMTP) нұсқасы – ESMTP-ді пайдаланады. Дәстүрлі түрде, Интернеттегі поштада MTA және MSA функциялары 25-ші портты пайдаланған, бірақ MSA үшін ресми порт – 587-ші порт. MTA пайдаланушының келіп түсетін поштасын қабылдаса, MSA пайдаланушының жіберілетін поштасын қабылдайды.
A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409. Historically, in Internet mail, both MTA and MSA functions use port number 25, but the official port for MSAs is 587. The MTA accepts a user's incoming mail, while the MSA accepts a user's outgoing mail.
Артықшылықтары
MTA және MSA функцияларын бөлу бірнеше артықшылықтар береді. Бір артықшылығы – MSA автордың MUA-мен тікелей өзара әрекеттесетіндіктен, хабарлама форматындағы ұсақ қателерді (мысалы, күнінің жоқтығы, хабарлама ID, «To» өрісі немесе домен атауы жоқ мекенжай) түзете алады және/немесе қате туралы авторға дереу хабарлай алады, осылайша ол кез келген алушыға жіберілмес бұрын түзетіледі. Басқа сайттан хабарды қабылдайтын MTA мұндай түзетулерді сенімді түрде жасай алмайды, ал мұндай MTA жасаған кез келген қате туралы хабарламалар авторға (болған жағдайда) хабар жіберілгеннен кейін ғана жетеді. Тағы бір артықшылығы – арнайы порт нөмірі, 587, пайдаланушыларға жаңа пошта жіберу үшін өз домендеріне қосылуға мүмкіндік береді. Спаммен күресу үшін (бот-желінің құрбаны жіберген спамды қоса алғанда) көптеген интернет-провайдерлер мен ұйымдық желілер 25-ші порттағы қашықтағы MTA-ға қосылу мүмкіндігін шектейді. 587-ші порттағы MSA-ның қолжетімділігі көшпелі пайдаланушыларға (мысалы, ноутбукта жұмыс істейтіндерге) басқалардың желілерінен де өздерінің таңдаған тапсыру серверлері арқылы пошта жіберуді жалғастыруға мүмкіндік береді. Жіберуші саясатын немесе қол қою тәжірибесін қолдану кезінде нақты тапсыру серверін пайдалану қажет. Тағы бір артықшылығы – MTA және MSA функцияларын бөлу MTA-ға ретрансляцияны қабылдамауды жеңілдетеді, яғни жергілікті қызмет көрсететін домендегі алушыға жіберілмеген кез келген поштаны қабылдамау. Бұл – вирус жұқтырған клиенттік компьютерлерден спам жіберуді болдырмау үшін интернет-провайдерлер қолданатын стратегия. Керісінше, MSA әдетте Интернеттегі кез келген алушыға арналған поштаны қабылдауы керек, бірақ ол тек осындай MSA-ны пайдалануға рұқсат етілген және аутентификация арқылы MSA-ға өздерінің жеке басын растаған авторлардан ғана осындай поштаны қабылдайды. Поштаны жіберу және кіріс поштаны қабылдау әдетте бір протокол мен бір серверді қолдана отырып жүзеге асырылған кезде, аутентификациясыз кез келген бағытқа пошта жіберу мүмкіндігі спамдерге MTA-ны спамды тарату құралы ретінде пайдалануға мүмкіндік берді (бір хабарлама транзакциясы MTA-ның хабарламаны көптеген алушыларға таратуын талап ете алады), сонымен қатар хабарламаның бастапқы көзіне ілесуді қиындатты. Сонымен қатар, MSA және MTA спамды сүзгілеу бойынша әртүрлі саясатты қолдана алады. Көптеген MSA автордың пайдаланушы аты мен паролі түрінде аутентификациясын талап етеді. Осындай MSA-ға келіп түскен кез келген хабарламалар МСА-мен тікелей байланысы бар авторға дейін анықталады және ол өз әрекеттері үшін жауапкершілік тартады. Бұл MSA-ға спам-фильтрлеуді тоқтатуға немесе басқа домендерден келетін электрондық поштаны қабылдау үшін арналған MTA-ға қарағанда спам-фильтрлеуді көбірек рұқсат етуге мүмкіндік береді. Кез келген домендер арасында жіберілетін поштаға сенім білдіруді орнату қиын, өйткені бұл домендер арасында сенімділік немесе тіпті сәйкестік орнатуға болатын тікелей байланыс жоқ. Мұндай сенім болмаған жағдайда, MTA әдетте спамды заңды трафиктен ажырату үшін эвристикаға және үшінші тараптың беделін бағалау қызметтеріне сүйенуі керек, ал бұл екі механизмнің де қателіктерге бейім болуының тарихы бар. Сондықтан MSA мен MTA-ны бөлу поштаны жіберу кезінде спамды танудың сенімсіз механизмдерін қолданудан аулақтайды және заңды поштаның сәтті жеткізілу ықтималдығын арттырады.
Separation of the MTA and MSA functions produces several benefits. One benefit is that an MSA, since it is interacting directly with the author's MUA, can correct minor errors in a message format (such as a missing Date, Message ID, To fields, or an address with a missing domain name) and/or immediately report an error to the author so that it can be corrected before it is sent to any of the recipients. An MTA accepting a message from another site cannot reliably make those kinds of corrections, and any error reports generated by such an MTA will reach the author (if at all) only after the message has already been sent. One more benefit is that with a dedicated port number, 587, it is always possible for users to connect to their domain to submit new mail. To combat spam (including spam being sent unwittingly by a victim of a botnet) many ISPs and institutional networks restrict the ability to connect to remote MTAs on port 25. The accessibility of an MSA on port 587 enables nomadic users (for example, those working on a laptop) to continue to send mail via their preferred submission servers even from within others' networks. Using a specific submission server is a requirement when sender policies or signing practices are enforced. Another benefit is that separating the MTA and MSA functions makes it easier for an MTA to deny relaying, that is to refuse any mail that is not addressed to a recipient at a domain that is served locally. This is a strategy used by ISPs to prevent the sending of spam from virus infected client computers. By contrast, an MSA must generally accept mail for any recipient on the Internet, though it only accepts such mail from authors who are authorized to use that MSA and who have established their identity to the MSA via authentication. In times when both mail submission and acceptance of incoming mail were usually accomplished using the same protocol and the same server, the ability to send mail to arbitrary destinations without authentication allowed spammers to use MTAs as a means of distributing spam (since a single message transaction can request that an MTA relay a message to a large number of recipients), and also made it more difficult to trace a message to its origin. Moreover, MSAs and MTAs can have different policies for filtering of spam. Most MSAs require authentication in the form of a username and password provided by the author. Any messages received by such an MSA are therefore traceable to an author who has a direct relationship with the MSA, and who can be held accountable for his actions. This allows the MSA to have either no spam filtering, or more permissive spam filtering than an MTA that exists for the purpose of accepting incoming email from other domains. It is difficult to establish trust in mail sent between arbitrary domains, because there is generally no direct relationship between those domains via which trust, or even identity, can be established. In the absence of such trust, an MTA must generally rely on heuristics and third party reputation services to distinguish spam from legitimate traffic, and both of these mechanisms have a history of being error prone. The separation of MSA and MTA therefore avoids the use of unreliable spam recognition mechanisms during mail submission, and increases the probability for legitimate mail to be delivered successfully.
Конфигурациясы
Жақындағы электрондық пошта клиенттері әдетте 587 портты пайдаланады, бірақ ескілері әлі де 25 портты ұсынады. Мұндай жағдайда пайдаланушылар порт нөмірін қолмен өзгертуі керек. Сонымен қатар, электрондық пошта клиенты (MUA) белгілі бір домен үшін MSA қызметін қамтамасыз ететін серверді автоматты түрде анықтай алады, осы доменге арналған SRV жазбаларын іздеу арқылы. Мысалы, example.com домені өзінің жазбасын былай жариялай алады:
While recent email clients use port 587 by default, older ones still propose port 25. Users have to change the port number manually in the latter case. It is also possible that the MUA may automatically discover which server provides the MSA for a given domain, looking up the SRV records for that domain. Domain example. com can publish its record like so:
RFC 6409 клиенттердің пошта жіберу қызметін пайдалану үшін авторизацияланып, аутентификациялануын талап етеді, мысалы, SMTP AUTH (ESMTPA) сияқты, немесе RADIUS, ашық кілт сертификаттары, немесе (көбінесе ескірген) SMTP-ден бұрын POP сияқты басқа жолдармен.
RFC 6409 requires that clients are authorized and authenticated to use the mail submission service, e. g., as described in SMTP AUTH (ESMTPA), or by other means such as RADIUS, public key certificates, or (the mostly obsolete) POP before SMTP.
Саясатты қолдану
MSA жіберілген хаттың синтаксистік тұрғыдан дұрыс екенін және тиісті сайт саясатына сәйкес келетінін тексеруі керек. RFC 6409 кейбір қосымша мүмкіндіктерді қамтиды:
The MSA must check that the submitted mail is syntactically valid and conforms to the relevant site policies. RFC 6409 contains some optional features:
Жіберу құқықтарын күшейту конверттегі жіберушінің мекенжайының жарамды және қолданылған аутентификация арқылы бекітілгенін қамтамасыз етеді. Бұл, негізінен, RFC 7208-де сипатталған SPF моделімен сәйкес келеді. Конверттегі жіберушінің мекенжайы "Автордан" (From) тақырыптық өрісіндегі автордың мекенжайымен сәйкес келмесе, жіберушіге "Жіберуші" (Sender) мекенжайы тақырыптық өрісін қосуға рұқсат беруі мүмкін. Бұл RFC 4406-да сипатталған Жіберуші ID моделімен шамамен сәйкес келеді, бірақ RFC 6409-да қарастырылмаған "Қайта жіберілгеннен" (Resent From) тақырыптық өрісінің қиын жағдайларын ескермейді.
Enforce submission rights guarantees that the envelope sender address is valid and authorized with the used authentication. This in essence complies with the SPF model specified in RFC 7208. May add sender permits to add a Sender address header field if the envelope sender address does not match any author address in the "From" header field. This roughly complies with the Sender ID model specified in RFC 4406 – ignoring the tricky case of Resent From header fields not covered in RFC 6409.