Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Өзгермелі конвертті қайтару жолы (VERP) – кейбір электрондық пошта тізімдері бағдарламалық жасақтамалары қолданатын, жеткізілмейтін электрондық пошта мекенжайларын автоматты түрде анықтап жоюға мүмкіндік беретін техника. Ол әрбір хабарлама алушысы үшін әртүрлі қайтару жолын (немесе "конверт жіберуші" деп те аталады) пайдалану арқылы жұмыс істейді.
Variable envelope return path (VERP) is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e mail addresses. It works by using a different return path (also called "envelope sender") for each recipient of a message.
Мотивация
Кез келген ұзақ уақытқа созылған пошта тізіміне, сөзсіз, қол жеткізе алмайтын мекенжайлар кіреді. Бұрын жарамды болған мекенжайлар, хатты алатын адам басқа провайдерге ауысқандықтан пайдасыз болуы мүмкін. Тағы бір жағдайда, мекенжай әлі де болуы мүмкін, бірақ тасталып кеткен болуы мүмкін, оқылмаған хаттар жинақталып, жаңа хаттарды қабылдауға орын жетпейді. Пошта тізіміне хабар жіберілген кезде, пошта тізімі бағдарламалық жасақтамасы оны тізімдегі барлық мекенжайларға қайта жібереді. Тізімдегі жарамсыз мекенжайлардың болуы тізім иесіне қайтару хабарламаларын (bounce messages) жіберуге себеп болады. Егер пошта тізімі кішкентай болса, иесі қайтару хабарламаларын оқып, жарамсыз мекенжайларды тізімнен қолмен жоюға болады. Бірақ үлкен пошта тізімімен жұмыс істеу шаршатарлық, жағымсыз жұмыс, сондықтан процесті автоматтандыру қажет. Дегенмен, көптеген қайтару хабарламалары тарихи тұрғыдан адамдар оқуы үшін жасалған, бағдарламалық жасақтамамен автоматты түрде өңделуге арналмаған. Олардың барлығы бірдей негізгі идеяны білдіреді ("X-тен Y-ге жіберілген хабар Z себебінен жеткізілмеді"), бірақ олардың көптеген нұсқалары бар, сондықтан әрбір қайтару хабарламасының мағынасын сенімді түрде түсіндіретін бағдарлама жасау іс жүзінде мүмкін емес. RFC 1894 (RFC 3464-пен ескірген) осы мәселені шешу үшін стандартты форматты анықтайды, бірақ осы стандартты қолдау кеңінен таралмаған. Алайда, бірнеше кең таралған форматтар бар (мысалы, RFC 3464, qmail-дің qsbmf және Microsoft-тың Exchange үшін DSN форматы), олар қайтару хабарламаларының көп бөлігін қамтиды. Microsoft Exchange кейде бастапқы хабарлама жіберілген мекенжайды көрсетпей хабарды қайтара алады. Exchange мақсатталған алушының мекенжайын білгенімен, оған электрондық поштаны қабылдауға дайын болмаса, алушының мекенжайын көрсетпейді. Мысалы, егер joe@example.com мекенжайына хат жіберілсе және сервер бұл "Joe User" екенін білсе, ол "Joe User" дегенге хабарламаны жеткізу мүмкін емес деп хабарды қайтарады, joe@example.com мекенжайын толығымен қалдырады. VERP – мұндай қайтару хабарламаларын дұрыс өңдеудің жалғыз тиімді жолы.
Any long lived mailing list eventually contains addresses that can't be reached. Addresses that were once valid can become unusable because the person receiving the mail switched to a different provider. In another scenario, the address may still exist but be abandoned, with unread mail accumulating until there is not enough room left to accept any more. When a message is sent to a mailing list, the mailing list software re sends it to all of the addresses on the list. The presence of invalid addresses in the list results in bounce messages being sent to the owner of the list. If the mailing list is small, the owner can read the bounce messages and manually remove the invalid addresses from the list. With a larger mailing list, this is a tedious, unpleasant job, so it is desirable to automate the process. However, most bounce messages have historically been designed to be read by human users, not automatically handled by software. They all convey the same basic idea ("the message from X to Y could not be delivered because of reason Z") but with so many variations that it would be nearly impossible to write a program to reliably interpret the meaning of every bounce message. RFC 1894 (obsoleted by RFC 3464) defines a standard format to fix this problem, but support for the standard is far from universal. However, there are several common formats (e. g., RFC 3464, qmail's qsbmf, and Microsoft's DSN format for Exchange) that cover large proportion of bounces. Microsoft Exchange can sometimes bounce a message without providing any indication of the address to which the original message was sent. When Exchange knows the intended recipient, but is not willing to accept email for them, it omits their address. If a message is sent to joe@example. com and the server knows that this is "Joe User", it will bounce the message saying that the message to "Joe User" could not be delivered, leaving out the joe@example. com address altogether. VERP is the only viable way to handle such bounces correctly.
VERP қайтуды басқару проблемасын қалай шешеді
Қайтаруды басқарудың қиын тұсы – қайтару хабарламасын қайтаруға себеп болған жеткізілмейтін мекенжаймен шайқастыру болып табылады. Егер пошта тізімі бағдарламалық жасақтамасы , мекенжайға хабарлама жіберу әрекетінен кейін қайтарылғанын анықтаса, онда ол қайтарудағы қалған ақпаратты түсінуі қажет емес. Ол жай ғана қанша хабарлама соңғы уақытта , мекенжайына жіберілгенін және қаншасы қайтарылғанын санауы жеткілікті; егер қайтарылған хабарламалардың үлесі тым жоғары болса, мекенжай тізімнен алынып тасталады. Қайтару хабарламаларының форматтары әдетте әртүрлі болғанымен, қайтару хабарламасының бір тұрақты аспектісі бар: оған жіберілетін мекенжай. VERP осы мүмкіндікті толыққанды пайдаланады. VERP қолданатын пошта тізімінде әр алушы үшін әртүрлі жіберуші мекенжайы қолданылады. Пошта тізіміне жауапты адам X-тен Y-ге хабарлама жібергенін біледі, сондықтан егер X мекенжайына қайтару хабарламасы келсе, бұл тек Y мекенжайы жеткізілмейтіндіктен болуы мүмкін, себебі X-тен басқа мекенжайға ештеңе жіберілмеген. Осылайша, маңызды ақпарат қайтару хабарламасынан оның мазмұнын түсінудің қажеті болмай алынады, яғни тізімге жауапты адам оны қолмен өңдеуге қатысудың қажеті жоқ.
The hard part of bounce handling is matching up a bounce message with the undeliverable address that caused the bounce. If the mailing list software can see that a bounce resulted from an attempt to send a message to , then it doesn't need to understand the rest of the information in the bounce. It can simply count how many messages were recently sent to , and how many bounces resulted; and if the proportion of bounced messages is too high, the address is removed from the list. While bounce message formats in general vary wildly, there is one aspect of a bounce message that is highly predictable: the address to which it will be sent. VERP takes full advantage of this. In a mailing list that uses VERP, a different sender address is used for each recipient. The mailing list manager knows that it sent a message from X to Y, so if a bounce message is received at address X, it can only be because address Y was undeliverable, because nothing was sent from X to any other address. Thus the important information has been extracted from the bounce message, without any need to understand its contents, which means the person in charge of the list does not need to deal with it manually.
Шығу тегі
Бұл шешімнің алғашқы тұжырымдамасын жасаған және оны сипаттау үшін VERP терминін енгізген – Дэниел Бернштейн. Ол бұл идеяны алғаш рет qmail MTA және ezmlm пошта тізімдерін басқарушысында іске қосты.
The first serious advocate of this solution, and the originator of the term VERP to describe it, was Daniel J. Bernstein, who first put the idea into practice in his qmail MTA and ezmlm mailing list manager.
Мысал
wikipedians@example.net деп аталатын пошта тізімі бар делік. bob@example.org деген жеке тұлға оған жазылған, бірақ кейін Боб example.org ұйымын тастап кеткен, сондықтан оның электрондық пошта мекенжайы енді қолданылмайды. Біреу тізімге хабар жібергенде не болатынын қарастырайық.
Assume there is a mailing list called wikipedians@example. net and that an individual, bob@example. org has subscribed to it, but later on, Bob has left example. org, so his address is no longer valid. Consider what happens when someone sends a message to the list.
Кемшіліктер
VERP-ті пайдалану әрбір хабарламаны әрбір алушыға бір рет жіберуді қажет етеді, әрбір SMTP серверіне бір рет емес. Бұл SMTP-нің шектеуіне байланысты, ол бір транзакцияда бірнеше алушы мекенжайларын, бірақ тек бір жіберуші мекенжайын көрсетуге мүмкіндік береді. Бір доменде көптеген жазылушылар болған кезде, VERP қолданбайтын пошта тізімі бірнеше жеткізілімді бір транзакцияға біріктіре алады. Ол доменге тиісті серверге қосылады, бір ғана жіберуші мекенжайын, алушылардың мекенжайларын береді, содан кейін хабарлама мазмұнын бір рет жібереді. VERP-ті қолданатын пошта тізімі, керісінше, хабардың толық мәтінін қайталап жіберуі керек, бұл жолақты пайдаланудың жалпы көлемін арттырады. Бұл тиімсіздік көбінесе үлкен проблема болып саналмайды, әсіресе qmail пайдаланушылары үшін, себебі qmail VERP қолданылмаған жағдайда да әр алушыға бір рет хабар жібереді. Кейбір бағдарламалар VERP-тің әсерін оны таңдаулы түрде қолдану арқылы азайтады, мысалы, пошта тізімін басқарушы VERP-ті 10 хабардың 1-інде ғана қолдануы мүмкін. Осылайша сіз VERP-тің қатаң қайтаруды бақылау мүмкіндігінен және дәл кері байланыс алудан көп пайда көре аласыз, әрқашан өңдеу және желілік жүктемелерге ұшырамастан. VERP-тің (және кез келген автоматты қайтаруды өңдеу схемасының) тағы бір мәселесі – Интернетте SMTP-нің негізгі стандарттарын сақтамайтын MTA-лардың болуы. VERP алушылардың MTA-лары конверт жіберушісіне қайтарулар жіберіледі деген қағиданы сақтауына тәуелді. Бұл талап 1982 жылдан бері SMTP-нің стандарты болып табылады (RFC 821 қараңыз), бірақ әлі де оны дұрыс түсінбейтін MTA-лар бар, көбінесе From: тақырыбындағы мекенжайға қайтару арқылы. Конверт жіберушісі жоғарыда аталған форматты сақтаса, grey listing жүйелері VERP-пен жақсы жұмыс істейді. Дегенмен, кейбір VERP жүйелері хабарлама нөмірін немесе кездейсоқ кілтті VERP-тің бір бөлігі ретінде пайдаланады, бұл пошта тізіміне жіберілген әрбір хабарламаның кешіктірілуіне әкелуі мүмкін, егер grey listing жүйесі «ұқсас» жіберуші мекенжайларын эквивалентті деп санамаса.
The use of VERP requires each message to be sent once for every recipient, instead of once to each receiving SMTP server. This is because of a limitation of SMTP, which allows multiple recipient addresses to be specified in a single transaction, but only one sender address. When there are many subscribers in the same domain, a mailing list that is not using VERP can combine multiple deliveries into a single transaction. It connects to the appropriate server for the domain, gives the single sender address, the recipient addresses, and then sends the message contents only once. A mailing list using VERP, on the other hand, must send the entire message body repeatedly, which leads to an overall increase in bandwidth usage. This inefficiency is usually not considered a big problem, especially by qmail users, since qmail always sends messages once per recipient, even when VERP is not being used. Some packages mitigate the impact of VERP by applying it selectively, for example a mailing list manager might only use VERP on 1 in 10 mailings. This way you can gain much of VERP's tight bounce control and accurate feedback without incurring the processing and network overhead every time. Another problem with VERP (and with any automatic bounce handling scheme) is that there are MTAs on the Internet that fail to follow basic SMTP standards. VERP depends on the recipients' MTAs following the rule that bounces are sent to the envelope sender. This has been a standard requirement since the dawn of SMTP in 1982 (see RFC 821), but still there are MTAs that get it wrong, usually by bouncing to the address in the From: header. Systems that implement greylisting work fine with VERP if the envelope sender follows the above mentioned format. However, some VERP implementations use message number or random key as part of VERP, which causes each post to the mailing list to be delayed unless the greylisting system treats "similar" sender addresses as being equivalent.