E-mailem

Elektronická pošta ( anglicky  email, e-mail [ i ˈ m e ɪ l ], z angličtiny  electronic mail ) je technologie a služba pro odesílání a přijímání elektronických zpráv (tzv. „letters“, „e-mails“ nebo „messages“). mezi uživateli počítačové sítě (včetně Internetu ) [1] .

E-mail z hlediska skladby prvků a principu fungování prakticky opakuje systém běžné (papírové) pošty , půjčování jak pojmů (pošta, dopis, obálka, příloha, krabice, zásilka a další), tak i charakteristických znaků - jednoduchost použití, zpoždění přenosu zpráv, dostatečná spolehlivost a zároveň žádná záruka doručení.

Výhody e-mailu jsou: adresy ve tvaru uživatelské_jméno@ název_domény (například ně[email protected]) jsou pro člověka snadno rozpoznatelné a zapamatovatelné; schopnost přenášet jak prostý text a formátované, tak i libovolné soubory ( textové dokumenty , mediální soubory, programy, archivy atd. [1] ); nezávislost serverů (obecně se vzájemně oslovují přímo); dostatečně vysoká spolehlivost doručování zpráv; snadnost použití osobou a programy, vysoká rychlost přenosu zpráv.

Nevýhody e-mailu: přítomnost takového fenoménu, jako je spam (hromadná reklama a virální korespondence ); možné zpoždění doručení zprávy (až několik dní); omezení velikosti jedné zprávy a celkové velikosti zpráv ve schránce (osobní pro uživatele).

V současné době si může každý začínající uživatel založit vlastní bezplatnou e-mailovou schránku, stačí se zaregistrovat na některém z internetových portálů.

Jména

Pokud se v Evropě, Americe a dalších regionech používají při psaní pouze dvě možnosti - „e-mail“ nebo „e-mail“ (navíc doporučení, zda psát pomlčku nebo ne, se liší: například od března 2011 jedna ze stylistických guidelines je AP Stylebook - doporučuje psát zkratku pro "elektronickou poštu" jako "email" a ne "e-mail" [2] ), v ruštině je pak značná variabilita. Nejčastěji V azbuce se také používá „e-mail“, tedy psaní latinkou bez transliterace (vizuální vnímání jiných forem psaní je horší ). Но можно встретить a другие написания:

Informační kancelář Gramota.ru nejprve uváděla, že se doporučuje psát e-mail (latinsky) nebo e- mail (azbuka) [4] , a poté začala doporučovat pouze pravopis emailu v azbuce , jak je zaznamenáno např. v Ruském pravopisném slovníku Ruské akademie věd [5] [6 ] .

Slovníky zaznamenaly čtyři varianty pravopisu: email , mail [7] e-mail , e-mail [8] .

Де-факто в официальных русскоязычных документах[ co? ] :

Historie

Vznik e-mailu lze vysledovat až do roku 1965 , kdy zaměstnanci Massachusetts Institute of Technology (MIT) Noel Morris a Tom Van Vleck napsali poštovní program pro operační systém CTSS (Compatible Time-Sharing System) nainstalovaný na IBM 7090/ počítač 7094.

Obecný vývoj e-mailu prošel vývojem interakce místních uživatelů na systémech s více uživateli. Uživatelé si mohli pomocí poštovního programu (nebo jeho ekvivalentu) předávat zprávy mezi sebou v rámci stejného sálového počítače (velkého počítače). Dalším krokem byla možnost předat zprávu uživateli na jiném počítači zadáním názvu počítače a uživatelského jména na počítači. Adresa může být zapsána jako foo!joe(uživatel joe na počítači foo). Třetí krok ve vývoji elektronické pošty nastal s příchodem přenosu dopisů prostřednictvím třetího počítače. V případě použití protokolu UUCP zahrnovala adresa uživatele cestu k uživateli přes několik zprostředkujících strojů (například gate1!gate2!foo!joe dopis pro joe přes bránu stroje1, bránu2 ke stroji foo). Nevýhodou tohoto adresování bylo, že odesílatel (nebo administrátor stroje, na kterém odesílatel běžel) potřeboval znát přesnou cestu k cílovému stroji.

Po nástupu distribuovaného globálního názvového systému DNS se názvy domén začaly používat k označení adresy – [email protected] uživatele uživatele na počítači example.com. Zároveň se přehodnocoval koncept „na stroji“: pro poštu se začaly používat dedikované servery, ke kterým běžní uživatelé (pouze správci) neměli přístup a uživatelé na svých strojích pracovali, zatímco pošta nikoli přicházet na pracovní stanice uživatelů, ale do poštovních schránek server, odkud uživatelé stahovali poštu pomocí různých síťových protokolů (mezi nejrozšířenější v současnosti patří POP3 , IMAP , MAPI , webová rozhraní). Současně s nástupem DNS byl vynalezen systém pro rezervaci tras doručování pošty a název domény v poštovní adrese přestal být názvem konkrétního počítače a stal se jen fragmentem poštovní adresy. Mnoho serverů může být odpovědných za údržbu domény (možná fyzicky umístěné na různých kontinentech a v různých organizacích) a uživatelé ze stejné domény spolu nemusí mít nic společného (to platí zejména pro uživatele bezplatných e-mailových serverů).

Kromě toho existovaly další e-mailové systémy (některé z nich stále existují), například: Netmail v síti Fidonet , X.400 v sítích X.25[ specifikovat ] . Pro směrování pošty v sítích X.25 poskytuje DNS speciální záznam o prostředku s příslušným názvem X25 (kód 19).

Chronologie

Klasifikace MxA

V terminologii e-mailu se rozlišují následující součásti:

V případě použití dedikovaných serverů pro ukládání uživatelské pošty může veškerá interakce mezi uživatelem a serverem probíhat pomocí protokolů, které do tohoto schématu nezapadají.

Poštovní servery obvykle fungují jako MTA a MDA. Některé poštovní servery (programy) plní funkci MTA i MDA, některé zahrnují oddělení na dva nezávislé servery: MTA server a MDA server (v tomto případě, pokud jsou pro přístup k poštovní schránce použity různé protokoly, například POP3 a IMAP , pak MDA lze implementovat buď jako jednu aplikaci, nebo jako sadu aplikací, z nichž každá je zodpovědná za samostatný protokol).

Moderní architektura (SMTP)

Světově nejrozšířenějším protokolem pro výměnu e-mailů je SMTP ( jednoduchý protokol pro přenos pošty  ). V běžné implementaci používá DNS k určení pravidel pro předávání pošty (ačkoli v soukromých systémech, jako je Microsoft Exchange , může SMTP jednat na základě informací z jiných zdrojů).  

Různé domény mají své vlastní nezávislé poštovní systémy. Každá poštovní doména může mít několik uživatelů. (Ve skutečnosti se však může stát, že jedna organizace nebo osoba vlastní mnoho domén, které (fyzicky) obsluhuje jeden poštovní systém). Pošta se mezi uzly přenáší pomocí programů pro přenos pošty ( anglicky  mail transfer agent , MTA ; jako například: sendmail , exim 4, postfix , Microsoft Exchange Server , Lotus Domino atd.). Chování systémů při vzájemné komunikaci je přísně standardizováno, k tomu slouží protokol SMTP (a dodržování tohoto standardu spolu s univerzální podporou DNS všemi zúčastněnými je základem pro schopnost komunikovat „všichni všem“ bez předchozí dohody). Interakce mezi poštovním systémem a uživateli obecně není nijak regulována a může být libovolná, ačkoli pro interakci mezi uživateli a poštovním systémem existují otevřené i uzavřené (svázané se softwarem konkrétních výrobců) protokoly. Program, který běží v poštovním systému a slouží uživatelům, se nazývá MDA ( mail delivery agent ) .  V některých poštovních systémech mohou být MDA a MTA kombinovány do jednoho programu, v jiných systémech mohou být odděleny jako samostatné programy nebo mohou dokonce běžet na různých serverech. Program, se kterým uživatel přistupuje, se nazývá MUA ( mail user agent ) . Pokud je webové rozhraní využíváno pro práci s poštou, plní jeho funkci aplikace webového rozhraní běžící na serveru.  

V rámci daného poštovního systému (obvykle ve stejné organizaci) může existovat mnoho poštovních serverů, které provádějí jak přeposílání pošty v rámci organizace, tak další úkoly související s e-mailem: filtrování spamu, antivirová kontrola příloh, automatická odpověď, příchozí/odchozí pošta archivace, poskytující přístup uživatelům různými metodami (od POP3 po ActiveSync ). Interakce mezi servery v rámci stejného poštovního systému může podléhat buď obecným pravidlům (pomocí DNS a pravidel směrování pošty pomocí protokolu SMTP), nebo se řídit pravidly vlastními (použitý software).

Relé

DNS vám umožňuje určit jako přijímající server ( záznam MX ) libovolného internetového hostitele, který nemusí být nutně součástí domény domény příjemce . To lze použít k nastavení předávání (přeposílání) pošty přes třetí servery. Server třetí strany (například spolehlivější než servery uživatele) přijímá poštu pro doménu uživatele a přeposílá ji na poštovní servery uživatele co nejdříve. Historicky neexistovala žádná kontrola nad tím, „komu přeposílat“ poštu (nebo tomu nebyla přikládána patřičná důležitost) a servery bez takové kontroly předávaly poštu libovolným doménám. Takové servery se nazývají otevřená relé (v současnosti se nová otevřená relé objevují hlavně kvůli chybám v konfiguraci).

Pro své uživatele jsou servery poštovního systému přenosové (uživatelé neposílají poštu na servery poštovního systému příjemce, ale na „svůj“ poštovní server, který přeposílá dopisy dále). V mnoha sítích poskytovatelů je možnost posílat dopisy přes protokol SMTP mimo síť uzavřena (kvůli používání této funkce trojskými koňmi , viry ). V tomto případě poskytovatel poskytuje vlastní SMTP server, přes který je veškerá pošta odesílána mimo síť. Za otevřené relé se v tomto případě považuje takové relé, které nekontroluje, zda je uživatel „přáteli“ (kontrolu lze provést jak na základě síťové adresy počítače uživatele, tak na základě identifikace uživatele heslem / certifikátem).

Směrování pošty

Poštovní server po přijetí pošty (z místního zdroje nebo z jiného serveru) zkontroluje, zda existují specifická pravidla pro zpracování pošty (pravidla mohou být založena na uživatelském jménu, na doméně v adrese, na obsahu dopisu , atd.), pokud nejsou nalezena žádná specifická pravidla, zkontroluje, zda je poštovní doména na serveru lokální (tj. zda je server konečným příjemcem zprávy). Pokud ano, je dopis přijat ke zpracování. Pokud poštovní doména není lokální, použije se procedura směrování pošty (která je základem pro přenos dopisů mezi různými servery na Internetu).

Směrování používá pouze doménovou část cílové adresy (tj. část za symbolem @). Pro doménu příjemce jsou vyhledány všechny záznamy MX. Jsou seřazeny v sestupném pořadí priority. Pokud adresa poštovního serveru odpovídá jednomu z hostitelů uvedených v záznamech MX, všechny záznamy s prioritou nižší, než je priorita hostitele v záznamu MX (stejně jako záznam MX samotného hostitele), budou vyřazeny a budou doručeny první odpovídající hostitel (hostitelé) jsou vyzkoušeni v sestupném pořadí priority). To se provádí v případě, že poštovní server odesílatele je relé poštovního serveru příjemce. Pokud není MX záznam pro doménu nalezen, pokusí se doručit poštu pomocí A záznamu odpovídajícího doméně. Pokud o doméně neexistuje žádný záznam, vygeneruje se zpráva o nemožnosti doručení (bounce message). Tato zpráva je generována pomocí MAIL FROM:<>( RFC 5321 ), pole "Komu" určuje odesílatele původní zprávy a pole "Od" určuje e-mail formuláře MAILER-DAEMON@имя сервера. Název serveru je název internetového hostitele, který vygeneroval oznámení. MAIL FROM:<>umožňuje chránit poštovní servery před nekonečnou cirkulací chybových zpráv mezi servery - pokud server zjistí, že nemůže doručit dopis s prázdnou zpáteční adresou, zničí jej. Po chvíli se také může vygenerovat zpráva o nemožnosti doručení. K tomu dochází, pokud je zjištěný problém určen jako přechodný, ale vyprší časový limit fronty zpráv ( RFC 5321 , oddíl 4.5.4.1. Strategie odesílání).

Pokud má síť různé servery DNS (například externí – na internetu a místní – v rámci svých vlastních limitů), je možné, že „interní“ servery DNS odkazují na server, který není na internetu dostupný jako nejvyšší prioritní příjemce, kde je pošta přesměrována z předávání zadaného jako cílový hostitel pro Internet. Toto rozdělení umožňuje směrování pošty podle společných pravidel mezi servery, které nemají přístup k Internetu.

Protokoly pro příjem pošty

Poté, co pošta dorazí na cílový server, dočasně nebo trvale uloží přijatou poštu. Pro práci s poštou existují dva různé modely: koncept poštovního úložiště ( boxu ) a poštovní terminál .

POP3

V konceptu úložiště pošty je pošta na serveru uložena dočasně, v omezeném objemu (podobně jako poštovní schránka pro papírovou poštu) a uživatel pravidelně přistupuje ke schránce a „vyzvedává“ dopisy (tj. poštovní klient stahuje kopii dopisu sobě a vymaže originál ze schránky) . Na základě této koncepce funguje protokol POP3 .

IMAP

Koncept poštovního terminálu znamená, že veškerá korespondence spojená s poštovní schránkou (včetně kopií odeslaných dopisů) je uložena na serveru a uživatel přistupuje k úložišti (někdy také tradičně nazývané „poštovní schránka“), aby si prohlédl korespondenci (novou i archiv) a psaní nových dopisů (včetně odpovědí na jiné dopisy). Na tomto principu funguje protokol IMAP a většina webových rozhraní bezplatných emailových služeb . Takové ukládání poštovní korespondence vyžaduje podstatně větší kapacitu poštovních serverů, v důsledku čehož v mnoha případech existuje oddělení mezi poštovními servery, které předávají poštu, a servery pro ukládání pošty.

Rozdíly

Na základě toho, jak protokoly fungují, je lze rozdělit podle dvou hlavních kritérií:

Za určitých podmínek lze server úložiště pošty nakonfigurovat tak, aby se choval podobně jako klient: takový server přistupuje k poštovnímu serveru pomocí protokolu POP3 a přebírá poštu pro sebe. Taková řešení se obvykle používají v malých organizacích, které nemají infrastrukturu pro nasazení plnohodnotných poštovních serverů; v tomto případě se pro ukládání pošty používá lokální server a poštovní server poskytovatele, který poskytuje službu příjmu pošty přes POP3 (např. pomocí fetchmail ). Hlavní nevýhodou takového řešení je zpoždění v doručení (protože software, který shromažďuje poštu, přistupuje na servery s určitým zpožděním) - například POP3 konektor z Exchange 2003 Server jako součást Windows SBS neumožňuje nastavit interval na kratší dobu. než 15 minut přes konfigurační rozhraní [10] , protože přílišná frekvence kontrol může způsobit problémy se zatížením poštovního serveru. Některé poštovní servery mají funkce na ochranu proti tomuto chování.

Struktura dopisu

Při přenosu pomocí protokolu SMTP se e-mail skládá z následujících částí.

Data obálky SMTP

Data obálky SMTP obsahují parametry, které se nastavují stejnojmennými příkazy:

Záhlaví e-mailů

E-mailové hlavičky jsou popsány standardy RFC :

Záhlaví jsou oddělena od těla dopisu prázdným řádkem. Záhlaví se používají k zaznamenávání průchodu dopisu a servisních poznámek (někdy nazývaných kludges ). V aplikaci Microsoft Outlook se tato záhlaví nazývají „Internetové záhlaví“. V hlavičkách je obvykle uvedeno: poštovní servery, přes které dopis prošel (každý poštovní server přidá informaci o tom, od koho tento dopis obdržel), informace o tom, zda tento dopis vypadá jako spam, informace o antivirové kontrole, úroveň naléhavosti dopisu ( možná změnit poštovní servery). Také v záhlaví je obvykle napsán program, kterým byl dopis vytvořen. Vzhledem k tomu, že hlavičky jsou proprietární informace, poštovní klienti je nejčastěji skrývají před uživatelem při běžném čtení zpráv, ale také poskytují možnost tyto hlavičky vidět, pokud je potřeba podrobnější analýzu zprávy. Pokud je e-mail z formátu SMTP převeden do jiného formátu (například e-maily jsou převedeny na MAPI v Microsoft Exchange 2007), záhlaví se uloží samostatně, aby bylo možné provést diagnostiku.

Nadpisy se obvykle přidávají zdola nahoru (to znamená, že pokaždé, když je třeba do zprávy přidat nadpis, přidá se na první řádek, před všechny předchozí).

V hlavičce e-mailu jsou kromě informací o službě uloženy také informace zobrazované uživateli, obvykle se jedná o odesílatele dopisu, příjemce, předmět a datum odeslání.

Hlavičky zpráv mohou obsahovat pouze 7bitové znaky [13] . Pokud je nutné v některých polích použít národní znaky, je vyžadováno použití kódování. Obvykle je to Base64 nebo Quoted-Printable .

Společné nadpisy
  • Return-Path:( RFC 821 , RFC 1123 ) - zpáteční adresa v případě poruchy, kdy není možné doručit dopis na cílovou adresu. Může se lišit od MAIL FROMzáhlaví a From:, Sender:nebo Reply-To:, ale obvykle odpovídá MAIL FROM.
  • Received:( RFC 822 , RFC 1123 ) - údaje o průchodu dopisu přes každý konkrétní poštovní server (MTA). Při průchodu více poštovními servery (obvyklá situace) se k předchozím přidávají nové hlavičky, případně se protokol přenosu zapíše v opačném pořadí (od uzlu nejblíže příjemci po nejvzdálenější).
  • MIME-Version:( RFC 1521 ) – Verze MIME , pomocí které byla tato zpráva vytvořena. Často je tento titul vytvořen dříve než všechny ostatní, takže je většinou úplně první (tedy poslední v seznamu).
  • From:( RFC 822 , RFC 1123 , RFC 1036 ) - jméno a adresa odesílatele (právě v této hlavičce se objevuje textové pole se jménem odesílatele). Nemusí odpovídat return-pathnebo dokonce odpovídat hlavičce SMTP MAIL FROM:.
  • Sender:( RFC 822 , RFC 1123 ) - odesílatel dopisu. Přidáno, aby bylo možné označit, že dopis jménem někoho (od) odeslala jiná osoba (například sekretářka jménem šéfa). Někteří poštovní klienti zobrazují zprávu v přítomnosti odesílatele a od odesílatele jako „zprávu od „odesílatele“ jménem „od“. Odesílatel je informační hlavička (a může se také lišit od hlavičky SMTP MAIL FROM).
  • To:( RFC 822 , RFC 1123 ) – Jméno a adresa příjemce. Může být obsažen vícekrát (pokud je dopis určen více příjemcům). Na základě tohoto pole se vytvoří obsah pole SMTP RCPT TO.
  • Cc:( RFC 822 , RFC 1123 ) - (z anglického  carbon copy ) obsahuje jména a adresy sekundárních příjemců dopisu, kterému je kopie zaslána. Podílí se na vytváření pole SMTP RCPT TO, stejně jako pole "Komu".
  • Bcc:( RFC 822 , RFC 1123 ) - (z anglického  blind carbon copy ) obsahuje jména a adresy příjemců dopisu, jejichž adresy by neměly být ostatním příjemcům ukazovány. Podílí se na vytváření pole SMTP RCPT TO, jako jsou pole „Komu“ a „Kopie“, ale není přítomen v odesílané zprávě.
  • Reply-To:( RFC 822 , RFC 1036 ) je jméno a adresa, na kterou by měly být adresovány odpovědi na tento dopis. Pokud je například dopis odeslán robotem, Reply-Tobude jako adresa uvedena adresa poštovní schránky, která je připravena přijmout odpověď na dopis.
  • Message-ID:( RFC 822 , RFC 1036 ) – jedinečný identifikátor zprávy . Skládá se z adresy odesílajícího hostitele a čísla (unikátní v rámci hostitele). Algoritmus generování jedinečných čísel závisí na serveru/klientovi. Vypadá takto: [email protected]. Spolu s dalšími identifikátory se používá k vyhledání průchodu konkrétní zprávy přes protokoly poštovního systému (poštovní systémy zaznamenají průchod dopisu jeho Message-ID) a k ukázání na dopis z jiných dopisů (slouží k seskupení a sestavení zprávy řetězy). Obvykle vytvořený poštovním klientem (MUA) v době psaní dopisu.
  • In-Reply-To:( RFC 822 ) - body, Message-IDpro které je tento dopis odpovědí (pomocí toho mohou poštovní klienti snadno vytvořit řetězec korespondence - každá nová odpověď obsahuje Message-ID pro předchozí zprávu).
  • Subject:( RFC 822 , RFC 1036 ) — předmět e-mailu.
  • Date:( RFC 822 , RFC 1123 , RFC 1036 ) — datum odeslání e-mailu.
  • Content-Type:( RFC 1049 , RFC 1123 , RFC 1521 , RFC 1766 ) — typ obsahu zprávy ( HTML , RTF , prostý text) a kódování, ve kterém byla zpráva vytvořena (o kódování viz níže).
  • Return-Receipt-To:( RFC 2076 ) – E-mail, kam má poštovní server příjemce odeslat oznámení o doručení. RFC 2076 je zmíněn v části "Není internetový standard", a proto nemusí být podporován servery.
  • Disposition-Notification-To:( RFC 3798 ) - e-mail, kam by měl poštovní klient příjemce odeslat oznámení o doručení, pokud to uživatel povolí (prostřednictvím nastavení atd.).

Kromě standardních mohou poštovní klienti, servery a zpracovatelé pošty přidávat vlastní hlavičky začínající „X-“ (například: X-Mailer, X-MyServer-Note-OKnebo X-Spamassasin-Level).

Tělo dopisu

Tělo dopisu je od hlavičky odděleno prázdným řádkem. V non-smtp standardech závisí formát dopisu na systémovém standardu (například MAPI ), ale než písmeno „opustí“ systém kompatibilní s MAPI (například před odesláním přes internet), je obvykle převeden do podoby kompatibilní se SMTP (jinak by nebylo možné směrování zpráv, protože standardem pro odesílání pošty na internetu je SMTP).

V těle zprávy jsou povoleny pouze tisknutelné znaky. Proto se pro účely přenosu binárních informací (obrázků, spustitelných souborů atd.) používají kódování, která přivádějí data do 7bitové podoby - Base64 nebo UUE . Na samém počátku existence e-mailu bylo navíc omezení přísnější – některé poštovní systémy podporovaly pouze 7bitové zprávy. Aby bylo možné s takovými systémy pracovat, může být prostý text s přítomností národních znaků také kódován v 7bitové podobě. K tomu slouží Base64 nebo Quoted-Printable . Poštovní systémy, které dokážou zpracovat pouze 7bitové zprávy, však nyní téměř neexistují.

Řetězovaná písmena

Vzhledem k přítomnosti jedinečného identifikátoru v dopise, jakož i skutečnosti, že velká většina poštovních klientů při odpovídání na dopis zkopíruje jeho identifikátor do pole In-Reply-To(„odpověď na“), je možné spolehlivě seskupovat zprávy podél řetězce ( angl.  thread ). To je implementováno odlišně v různých e-mailových klientech. Například Microsoft Outlook umožňuje najít všechny související e-maily a webové rozhraní GMail seskupuje zprávy na základě dat vláken do jednoho objektu. Někteří e-mailoví klienti (jako je mutt ) umožňují strukturovat řetězce (obvykle vytvořené v e-mailových seznamech, když je v konverzaci mnoho účastníků) ve formě stromu (otázka vygenerovala několik odpovědí, z nichž každá byla okomentována - to vytvořilo několik větve stromu). Takoví klienti také obvykle vědí, jak násilně přerušit vlákna, když se změní předmět zprávy (za předpokladu, že změna předmětu zprávy znamená novou diskusi, i když možná způsobenou předchozí konverzací).

Šifrování e-mailů

V současné době se pro šifrování pošty široce používají dva standardy: S/MIME (využívá infrastrukturu veřejného klíče) a OpenPGP (používá certifikáty se schématem důvěry, které se seskupují kolem uživatele).

Dříve existovaly také standardy MOSS a PEM , ale kvůli vzájemné nekompatibilitě a nepohodlnosti použití se neujaly.

Standardy S/MIME a OpenPGP poskytují tři typy ochrany: proměnlivost, neodvolatelný podpis a důvěrnost (šifrování). S/MIME verze 3 navíc umožňuje použití zabezpečeného potvrzení (ve kterém lze potvrzení o přijetí dopisu úspěšně vygenerovat pouze v případě, že dopis dorazil k příjemci neporušený).

Oba standardy používají k šifrování těla zprávy symetrické kryptografické algoritmy a symetrický klíč je zašifrován pomocí veřejného klíče příjemce. Pokud je dopis adresován skupině lidí, pak je symetrický klíč zašifrován postupně veřejnými klíči každého příjemce (a někdy pro pohodlí veřejným klíčem odesílatele, aby si mohl přečíst jím zaslaný dopis) .

Komerční využití

V současné době existují následující modely komerčního využití poštovních systémů:

  • Domácí a firemní poštovní systémy - fungují na vlastním nebo pronajatém zařízení poštovního systému (většinou je také vlastníkem domény, ve které poštovní server funguje).
  • Službu přijímání/odesílání e-mailů zajišťuje třetí strana. Organizace (osoba) vlastní doménu a samostatně uchovává archiv korespondence.
  • Služby pro příjem/odesílání a ukládání pošty provádí organizace třetí strany ve vlastních zařízeních. Zákazník získá přístup do systému dodavatele pro zasílání dopisů a pro přístup do archivu dopisů. Poštovní doménu vlastní zákazník.
  • Příjem, odesílání, ukládání dopisů provádí exekutor, poštovní doména patří exekutorovi. Většina těchto služeb je bezplatná a funguje tak, že uživateli zobrazuje reklamy nebo je bezplatný doplněk k dalším službám interpreta (podrobněji viz: Bezplatné poštovní služby ).

Seznamy adresátů

Poštovní systém vám umožňuje organizovat složité systémy založené na přeposílání pošty od jednoho k mnoha odběratelům, jsou to:

  • Mailing listy - dopis ze stejné adresy se stejným (nebo měnícím se podle šablony) obsahem, zasílaný odběratelům mailing listu . Technicky to může být organizováno jako odesílání více e-mailů (používá se pro šablony e-mailů) nebo odesílání e-mailů s více příjemci (v polích TO, CC, BCC). Pro správu velkých e-mailových konferencí (více než 10-50 odběratelů) se používají specializované programy (např. mailman ). Správně uspořádaný mailing list by měl kontrolovat vracení dopisů (zprávy o nemožnosti doručit dopis) s vyloučením nedostupných příjemců z mailing listu, umožnit předplatitelům odhlásit se z mailing listů. Nevyžádané mailingy se nazývají spam a výrazně komplikují fungování poštovních systémů.
  • Korespondenční skupiny jsou specializovaný typ mailing listu, ve kterém je všem členům skupiny zaslán dopis na adresu skupiny (běžná poštovní adresa zpracovaná specializovaným programem). Je to obdoba tiskových konferencí, echo konferencí. Správně nakonfigurovaný mailing list by měl řídit cykly (dva mailingové roboty přihlášené k sobě jsou schopny vytvořit nekonečnou smyčku posílání dopisů), omezit seznam účastníků mailing listu, kteří mají právo poslat zprávu, a splnit další požadavky mailing listu. .

Správci e-mailových konferencí se používají ke správě e-mailových konferencí . Kromě vedení seznamu adres a odeslání dané zprávy poskytují filtrování dopisů, možnost předmoderování dopisů před jejich umístěním do mailing listu, správu archivů, správu přihlášení/odhlášení, rozesílání přehledů (krátký obsah) místo celého objemu pošty.

Příklady programů pro správu pošty:

Spam

Spam je druh mailingu za účelem reklamy (často nevyžádané) konkrétního produktu nebo služby, obdoba papírové reklamy distribuované zdarma do poštovních schránek obytných domů.

Jak rostla popularita e-mailu, začal se (spolu s diskusními skupinami usenet ) používat k rozesílání nevyžádaných propagačních zpráv, podobně jako se do běžných poštovních schránek vhazují brožury. Na rozdíl od značných nákladů na papírový seznam adresátů však odeslání značného množství (milionů a miliard) zpráv nestojí odesílatele prakticky nic. To vedlo k neúměrnému nárůstu počtu a velikosti reklamních e-mailů (podle některých údajů [14] tvoří spam v současnosti 70–90 % všech e-mailových zpráv, to znamená, že 2–10krát překračuje nosnost pošty) .

K rozesílání spamu se v současnosti aktivně využívají všechny možné technické triky: open relay , remailery , proxy servery, bezplatné e-mailové servery (umožňující automatizaci odesílání pošty), botnety , falešné zprávy o nemožnosti doručení.

Se zpřísněním zákazu inzerce byly zprávy rozděleny na legitimní mailingy (ke kterým se uživatel obvykle přihlašuje a které může kdykoliv odmítnout) a nelegitimní (ve skutečnosti zvané spam). Pro boj proti spamu byly vyvinuty různé mechanismy ( černé listiny odesílatelů, šedé listiny , které vyžadují opětovné odeslání poštovního serveru, kontextové filtry). Jedním z důsledků zavedení antispamových nástrojů byla možnost „ falešně pozitivního “ rozhodnutí ohledně spamu, to znamená, že část dopisů, které spamem nejsou, začala být označena jako spam. V případě agresivní antispamové politiky (zničení zpráv, které se jeví jako spam automaticky bez upozornění odesílatele/příjemce), to vede k těžko odhalitelným problémům s tokem pošty.

Legislativní regulace v Rusku

Federální zákon č. 152-FZ „O osobních údajích“ .

Nejoblíbenější e-mailové služby

Nejoblíbenější e-mailové služby poskytují IT společnosti spolu s dalšími webovými produkty: vyhledávače, cloudová úložiště atd. Ruské e-mailové služby jsou vyvinuty společnostmi Google ( Gmail ), Yandex ( Yandex.Mail ), Mail.ru ( Mail.ru ), Microsoft ( Hotmail a Outlook ).

Viz také

Poznámky

  1. ↑ 1 2 E-mail – Slovník – SeoPult.Ru .
  2. ↑ Email ztratil spojovník
  3. ↑ Časopis ComputerPress 6'2001 - Internetová pošta
  4. ↑ 1 2 Otázka č. 220471 Gramota.ru
  5. ↑ Hledejte odpověď . new.gramota.ru. Datum přístupu: 14. března 2019.
  6. ↑ Otázka č. 275417 Gramota.ru
  7. ↑ Hledejte slovo: hledejte vzor "*m?ile"
  8. ↑ Hledání ve slovníku - Kontrola slov: * mail Gramota.ru
  9. ↑ MuttWiki: MailConcept (downlink) . Získáno 5. září 2009. Archivováno z originálu 16. prosince 2008. 
  10. ↑ POP3 Connector for Exchange 2003 (SBS2003) v Exchange Admin  (downlink)
  11. ↑ RFC 5321: 4.5.5. Zprávy s nulovou reverzní cestou
  12. ↑ Ověření zpětného volání
  13. ↑ V současné době byla vyvinuta sada standardů pro podporu národních znaků v e-mailu ( RFC 6531 , RFC 6532 , RFC 6533 ), ale ne každý software to podporuje.
  14. ↑ Securelist – Spam v květnu 2009 , podle společnosti Kaspersky Lab, v květnu 2009 spam představoval 70–90 % celkové poštovní korespondence.

Odkazy

  • RFC 822  – standard pro internetové textové zprávy ARPA
  • RFC 2142  - Názvy poštovních schránek pro běžné služby, role a funkce
  • RFC 2368  – schéma mailto URL
  • RFC 5322  - Internet Message Format
  • RFC 2045  - Formát těl internetových zpráv
  Přejděte na položku Wikidata  Slovníky a encyklopedie
 Počítačově zprostředkovaná komunikace
Asynchronní konference
Synchronní konference
Publikace