Email

Az elektronikus levelezés ( angolul  email, e-mail [ i ˈ m e ɪ l ], angol  elektronikus mailből ) egy technológia és szolgáltatás elektronikus üzenetek ("levelek", "e-mailek" vagy "üzenetek") küldésére és fogadására. számítógépes hálózat (beleértve az internetet is ) felhasználói között [1] .

Az e-mail az elemek összetételét és működési elvét tekintve gyakorlatilag megismétli a hagyományos (papír) posta rendszerét , kölcsönözve mind a kifejezéseket (posta, levél, boríték, melléklet, doboz, kézbesítés és egyebek), mind a jellemző tulajdonságokat. - könnyű kezelhetőség, üzenetküldési késések, kellő megbízhatóság és ugyanakkor a kézbesítési garancia hiánya.

Az e-mail előnyei: a user_name@ domain_name formátumú címek (például [email protected]) könnyen észrevehetők és megjegyezhetők az emberek számára; egyszerű szöveg és formázott, valamint tetszőleges fájlok ( szöveges dokumentumok , médiafájlok, programok, archívumok stb. [1] ) átvitelének lehetősége; a szerverek függetlensége (általában közvetlenül szólítják meg egymást); az üzenetküldés kellően magas megbízhatósága; személy és programok általi egyszerű használat, nagy sebességű üzenetátvitel.

Az e-mail hátrányai: olyan jelenség jelenléte, mint a spam (tömeges reklámok és vírusos levelek ); lehetséges késések az üzenetek kézbesítésében (akár több napig); korlátozza az egy üzenet méretét és a postafiókban lévő üzenetek teljes méretét (személyes a felhasználók számára).

Jelenleg minden kezdő felhasználó elindíthatja saját ingyenes e-mail fiókját, csak regisztráljon valamelyik internetes portálon.

Nevek

Ha Európában, Amerikában és más régiókban csak két lehetőséget használnak az íráshoz - „e-mail” vagy „e-mail” (sőt, az ajánlások arra vonatkozóan, hogy írjunk-e kötőjelet vagy sem: például 2011 márciusa óta az egyik stilisztikai irányelvei az AP Stylebook - az "electronic mail" rövidítését javasolja "e-mail"-ként és nem "e-mail"-ként írni [2] ), akkor az orosz nyelvben jelentős eltérések tapasztalhatók. Leggyakrabban A cirill betűs szövegek az "e-mailt" is használják, azaz latinul írnak átírás nélkül (más írásmódok vizuális észlelése rosszabb ). De találhatsz más elírásokat is:

A Gramota.ru információs irodája először jelezte, hogy ajánlott e-mailt (latinul) vagy e- mailt (cirill) írni [4] , majd csak az e- mail cirill írásmódját kezdte javasolni , ahogy pl. az Orosz Tudományos Akadémia Orosz Helyesírási Szótárában [5] [6] .

A szótárak négyféle írásmódot rögzítettek: email , mail [7] e-mail , e-mail [8] .

De facto a hivatalos orosz nyelvű dokumentumokban[ mi? ] :

Történelem

Az e-mail megjelenése 1965 - re vezethető vissza , amikor a Massachusetts Institute of Technology (MIT) munkatársai, Noel Morris és Tom Van Vleck megírták a levelezőprogramot az IBM 7090/-re telepített CTSS (Compatible Time-Sharing System) operációs rendszerhez . 7094 számítógép.

Az e-mail általános fejlődése a helyi felhasználói interakció fejlesztésén keresztül zajlott a többfelhasználós rendszereken. A levelezőprogram (vagy annak megfelelője) segítségével a felhasználók ugyanazon a nagy számítógépen (nagy számítógépen) továbbíthatták egymásnak az üzeneteket . A következő lépés az volt, hogy az üzenetet továbbíthassuk egy másik gépen lévő felhasználónak a gép nevének és felhasználónevének megadásával. A cím a következőképpen írható: foo!joe(joe felhasználó számítógépen foo). Az e-mail fejlesztésének harmadik lépése a levéltovábbítás egy harmadik számítógépen keresztül történt. Az UUCP használata esetén a felhasználó címe tartalmazott egy útvonalat a felhasználóhoz több közbenső gépen keresztül (például gate1!gate2!foo!joe egy levél joe számára a gépkapu1-en keresztül, kapu2 a gép foo-ig). Ennek a címzésnek az volt a hátránya, hogy a küldőnek (vagy annak a gépnek a rendszergazdájának, amelyen a küldő fut) tudnia kellett a célgép pontos elérési útját.

A DNS elosztott globális névrendszer megjelenése után a domain neveket kezdték használni a cím - [email protected] - a felhasználó felhasználó jelzésére az example.com gépen. Ezzel párhuzamosan újragondolták a „gépen” fogalmát is: dedikált szervereket kezdtek használni a levelezéshez, amelyekhez a hétköznapi felhasználók (csak a rendszergazdák) nem fértek hozzá, és a felhasználók a gépeiken dolgoztak, míg a levelezés nem. a felhasználók munkaállomásaira érkeznek, hanem a postafiókokba.egy szerver, ahonnan a felhasználók különféle hálózati protokollok segítségével (jelenleg a leggyakoribbak a POP3 , IMAP , MAPI , webes felületek) kérték le leveleiket. A DNS megjelenésével egy időben feltalálták a levélkézbesítési útvonalak lefoglalási rendszerét, és a levelezési címben szereplő domain név megszűnt egy adott számítógép neve lenni, és a levelezési cím töredéke lett. Sok szerver lehet felelős egy tartomány fenntartásáért (esetleg fizikailag különböző kontinenseken és különböző szervezetekben található), és az azonos tartomány felhasználóinak semmi közük lehet egymáshoz (ez különösen igaz az ingyenes levelezőszerverek felhasználóira).

Emellett léteztek más levelezőrendszerek is (amelyek közül néhány még mindig létezik), mint például: Netmail a Fidonet hálózaton , X.400 az X.25 hálózatokon[ adja meg ] . Hozzáférésük az internetről és fordítva egy levelezési átjárón keresztül történik . A levelek X.25 hálózatokban történő irányításához a DNS egy speciális erőforrásrekordot biztosít a megfelelő X25 névvel (kód: 19).

Kronológia

MxA besorolás

Az e-mail terminológiájában a következő összetevőket különböztetik meg:

Dedikált szerverek használata esetén a felhasználói levelek tárolására a felhasználó és a szerver közötti minden interakció olyan protokollok használatával történhet, amelyek nem illeszkednek ebbe a sémába.

A levelezőszerverek általában MTA-ként és MDA-ként működnek. Egyes levelezőszerverek (programok) az MTA és az MDA funkcióját is ellátják, mások két független szerverre való szétválást foglalnak magukban: MTA szerverre és MDA szerverre (ebben az esetben, ha különböző protokollokat használnak a postafiók eléréséhez, pl. POP3 és IMAP , akkor Az MDA pedig megvalósítható egyetlen alkalmazásként vagy alkalmazások halmazaként, amelyek mindegyike külön protokollért felelős).

Modern Architecture (SMTP)

A világ legszélesebb körben elfogadott e-mail csereprotokollja az SMTP ( egyszerű levélátviteli protokoll )  . Egy általános megvalósításban a DNS - t használja a levéltovábbítási szabályok meghatározásához (bár az olyan magánrendszerekben, mint a Microsoft Exchange , az SMTP más forrásokból származó információk alapján is működhet).  

A különböző tartományoknak saját, független levelezőrendszerük van. Minden levelezési domainnek több felhasználója is lehet. (Valójában azonban előfordulhat, hogy egy szervezet vagy személy több olyan domaint birtokol, amelyeket (fizikailag) egy levelezőrendszer szolgál ki). A levelek átvitele a csomópontok között levéltovábbítási programokkal történik ( angol  mail transfer agent , MTA ; például: sendmail , exim 4, postfix , Microsoft Exchange Server , Lotus Domino stb.). A rendszerek viselkedése az egymással való kommunikáció során szigorúan szabványosított, ehhez az SMTP protokollt használják (és ennek a szabványnak való megfelelés, valamint az összes résztvevő által nyújtott univerzális DNS-támogatás az alapja annak a képességnek, hogy a „mindenkivel mindenkivel” kommunikáljunk anélkül, hogy előzetes megállapodások). A levelezőrendszer és a felhasználók közötti interakció általában semmilyen módon nem szabályozott, és tetszőleges lehet, bár a felhasználók és a levelezőrendszer közötti interakcióhoz nyílt és zárt (specifikus gyártóktól származó szoftverekhez kötött) protokollok is léteznek. A levelezőrendszerben futó és a felhasználókat kiszolgáló programot MDA -nak ( levélkézbesítési ügynök ) hívják .  Egyes levelezőrendszerekben az MDA és az MTA egy programba egyesíthető, más rendszerekben külön programokként különíthetők el, vagy akár különböző szervereken futhatnak. A program, amellyel a felhasználó hozzáfér, MUA -nak ( mail user agent ) hívják . Ha a webes felületet levéllel dolgozzuk fel, akkor annak funkcióját a szerveren futó webes felület alkalmazás látja el.  

Egy adott levelezőrendszeren belül (általában ugyanazon a szervezeten belül) sok olyan levelezőszerver működhet, amelyek mind a szervezeten belüli levéltovábbítást, mind az e-mailekkel kapcsolatos egyéb feladatokat látják el: spamszűrés, mellékletek víruskereső vizsgálata, automatikus válasz, bejövő/kimenő levelek archiválás, hozzáférést biztosít a felhasználók számára különféle módszerekkel ( POP3 -tól ActiveSync -ig ). Az ugyanazon levelezőrendszeren belüli kiszolgálók közötti interakcióra vagy általános szabályok vonatkozhatnak (DNS és levéltovábbítási szabályok használata SMTP protokoll használatával), vagy a vállalat saját szabályai (a használt szoftver) követhetők.

Relék

A DNS lehetővé teszi fogadó szerverként ( MX rekord ) bármely internetes gazdagép megadását, amely nem feltétlenül része a fogadó tartomány tartományzónájának . Ezzel beállíthatja a levelek továbbítását (továbbítását) harmadik szervereken keresztül. Egy harmadik féltől származó szerver (például megbízhatóbb, mint a felhasználó szerverei) fogadja a leveleket a felhasználó tartományához, és a lehető leghamarabb továbbítja a felhasználó levelezőszervereire. Korábban nem lehetett szabályozni, hogy "kinek továbbítsa" a leveleket (vagy nem tulajdonítottak megfelelő jelentőséget), és az ilyen ellenőrzés nélküli szerverek a leveleket bármely tartományba továbbították. Az ilyen szervereket nyitott reléknek nevezzük (jelenleg elsősorban konfigurációs hibák miatt jelennek meg az új nyitott relék).

Felhasználóik számára a levelezőrendszer-szerverek közvetítők (a felhasználók nem a címzett levelezőrendszer-szervereire küldik a leveleket, hanem a "saját" levelezőszerverükre, amely továbbítja a leveleket). Számos szolgáltatói hálózatban a hálózaton kívüli SMTP protokollon keresztüli levelek küldése le van zárva (a trójaiak , vírusok általi használat miatt ). Ebben az esetben a szolgáltató saját SMTP-kiszolgálót biztosít, amelyen keresztül minden levél a hálózaton kívülre kerül. Ebben az esetben nyitott közvetítőnek minősül az a relé, amely nem ellenőrzi, hogy a felhasználó „barát”-e (az ellenőrzés elvégezhető mind a felhasználó számítógépének hálózati címe, mind az felhasználó azonosítása jelszóval/tanúsítvánnyal).

Levéltovábbítás

A levelezőszerver a levelek fogadása után (helyi forrásból vagy más szerverről) ellenőrzi, hogy vannak-e speciális szabályok a levelek feldolgozására (a szabályok alapulhatnak felhasználónéven, címben lévő tartományon, levél tartalmán stb.), ha nem található konkrét szabály, akkor ellenőrzi, hogy a levelezőtartomány helyi -e a szerveren (vagyis, hogy a szerver-e az üzenet végső címzettje). Ha igen, akkor a levelet elfogadják feldolgozásra. Ha a levelezési tartomány nem helyi, akkor a levéltovábbítási eljárás (amely az interneten a különböző szerverek közötti levelek átvitelének alapja) kerül alkalmazásra.

Az útválasztás a célcímnek csak a domain részét használja (azaz a @ szimbólum utáni részt). A címzett tartományhoz a rendszer minden MX rekordot kikeres. Ezek csökkenő fontossági sorrendbe vannak rendezve. Ha a levelezőszerver címe megegyezik az MX rekordokban megadott egyik gazdagép címével, akkor az MX rekordban a gazdagép prioritásánál alacsonyabb prioritású rekordokat (valamint magának a gazdagépnek az MX rekordját) a rendszer elveti, és a kézbesítés a következő címre történik: az első válaszoló gazdagép(ek). csökkenő prioritási sorrendben próbálkoznak). Ez akkor történik, ha a feladó levelezőszervere a címzett levelezőszerverének közvetítője. Ha a tartomány MX rekordja nem található, akkor a rendszer a tartománynak megfelelő A rekord segítségével próbálja kézbesíteni a leveleket. Ha nincs rekord a tartományról, akkor a kézbesítés lehetetlenségéről szóló üzenet (visszafordulási üzenet) generálódik. Ez az üzenet az MAIL FROM:<>( RFC 5321 ) segítségével jön létre, a "Címzett" mező az eredeti üzenet feladóját, a "Feladó" mező pedig az űrlap e-mailjét adja meg MAILER-DAEMON@имя сервера. A kiszolgáló neve az értesítést létrehozó internetes gazdagép neve. MAIL FROM:<>lehetővé teszi a levelezőszerverek védelmét a hibaüzenetek szerverek közötti végtelen körforgásától - ha a szerver azt észleli, hogy nem tud kézbesíteni egy üres visszaküldési címet tartalmazó levelet, akkor megsemmisíti azt. Egy idő után üzenet is generálható a kézbesítés lehetetlenségéről. Ez akkor fordul elő, ha az észlelt probléma átmeneti, de az üzenetsor időtúllépése lejár ( RFC 5321 , 4.5.4.1. Küldési stratégia).

Ha a hálózatnak különböző DNS-kiszolgálói vannak (például külső - az interneten és helyi - saját korlátain belül), akkor lehetséges, hogy a "belső" DNS-kiszolgálók olyan szerverre mutatnak, amely nem elérhető az interneten, mint a legmagasabb. prioritásos címzett, ahol a levél átirányításra kerül az internet célállomásaként megadott közvetítőről. Ez a felosztás lehetővé teszi a levelek közös szabályok szerinti továbbítását az internethez nem férő szerverek között.

Levélfogadási protokollok

Miután a levél elérte a célszervert, ideiglenesen vagy véglegesen tárolja a fogadott leveleket. Két különböző modell létezik a levelezéssel való munkavégzésre: a levéltár ( box ) és a levelezőterminál koncepciója .

POP3

A levéltárolás koncepciójában a kiszolgálón lévő leveleket ideiglenesen, korlátozott mennyiségben tárolják (hasonlóan a papíralapú postafiókhoz ), és a felhasználó időről időre hozzáfér a postafiókhoz és „felveszi” a leveleket (vagyis a levelezőkliens letölti a levél másolatát magának, és törli az eredetit a postafiókból) . Ezen koncepció alapján működik a POP3 protokoll .

IMAP

A levelezőterminál fogalma azt jelenti, hogy a postafiókhoz kapcsolódó összes levelezést (beleértve az elküldött levelek másolatait is) a szerver tárolja, és a felhasználó hozzáfér a tárolóhoz (amelyet hagyományosan "postafióknak" is neveznek), hogy megtekintse a levelezést (mind az új, mind az elküldött levelek másolatait). archívum) és új levelek írása (beleértve a más levelekre adott válaszokat is). Az IMAP protokoll és az ingyenes e-mail szolgáltatások legtöbb webes felülete ezen az elven működik . A levelezés ilyen tárolása lényegesen nagyobb kapacitást igényel a levelezőszerverektől, ennek következtében sok esetben elkülönül a leveleket továbbító levelezőszerver és a levéltároló szerver.

Különbségek

A protokollok működése alapján két fő kritérium szerint oszthatók fel:

Bizonyos feltételek mellett a levéltároló szerver konfigurálható úgy, hogy a klienshez hasonlóan viselkedjen: egy ilyen szerver POP3 protokollon keresztül éri el a levelezőszervert, és saját magának veszi a leveleket. Az ilyen megoldásokat általában olyan kis szervezetekben alkalmazzák, amelyek nem rendelkeznek a teljes értékű levelezőszerverek telepítéséhez szükséges infrastruktúrával; ebben az esetben egy helyi szervert használnak a levelek tárolására és a szolgáltató levelezőszerverét, amely a levelek POP3-on keresztüli fogadását biztosítja (például a fetchmail használatával ). Az ilyen megoldások fő hátránya a kézbesítés késése (mivel a leveleket gyűjtő szoftver némi késéssel éri el a kiszolgálókat) - például az Exchange 2003 Server POP3-csatlakozója a Windows SBS részeként nem teszi lehetővé kisebb intervallum beállítását. mint 15 perc a konfigurációs felületen [10] , mivel az ellenőrzések túlzott gyakorisága problémákat okozhat a levelezőszerver terhelése során. Egyes levelezőszerverek olyan funkciókkal rendelkeznek, amelyek megvédik ezt a viselkedést.

A levél szerkezete

Az SMTP protokoll használatával küldött e-mail a következő részekből áll.

SMTP Envelope Data

Az SMTP-borítékadatok olyan paramétereket tartalmaznak, amelyeket az azonos nevű parancsok állítanak be:

E-mail fejlécek

Az e-mail fejléceket az RFC szabványok írják le :

A fejléceket egy üres sor választja el a levél törzsétől. A fejlécek a levél és a szolgáltatási megjegyzések áthaladásának naplózására szolgálnak (ezt néha kludges -nak nevezik ). A Microsoft Outlook programban ezeket a fejléceket "internetes fejléceknek" nevezik. A fejlécek általában a következőket jelzik: a levelezőszerverek, amelyeken keresztül a levél áthaladt (minden levelezőszerver információt ad arról, hogy kitől kapta ezt a levelet), információkat arról, hogy ez a levél spamnek tűnik-e, információkat a víruskeresőről, a levél sürgősségi szintjét ( esetleg levélkiszolgálót váltani). Szintén a fejlécbe szokták írni azt a programot, amellyel a levelet létrehozták. Mivel a fejlécek védett információk, a levelezőkliensek leggyakrabban elrejtik azokat a felhasználó elől az üzenetek normál olvasása során, de lehetőséget biztosítanak ezeknek a fejléceknek a megtekintésére is, ha az üzenet részletesebb elemzésére van szükség. Ha egy SMTP formátumú e-mailt egy másik formátumba konvertál (például az e-maileket a Microsoft Exchange 2007 MAPI formátumba konvertálja), akkor a fejléceket a rendszer külön menti a diagnosztika engedélyezéséhez.

A címsorokat általában alulról felfelé adják hozzá (vagyis minden alkalommal, amikor egy címsort hozzá kell adni egy üzenethez, az az első sorba kerül, az összes előző elé).

Az e-mail fejlécek a szolgáltatási információkon kívül a felhasználó számára megjelenített információkat is tárolják, ez általában a levél feladója, címzettje, tárgya és a küldés dátuma.

Az üzenetfejlécek csak 7 bites karaktereket tartalmazhatnak [13] . Ha egyes mezőkben nemzeti karaktereket kell használni, akkor kódolást kell használni. Általában ez a Base64 vagy Quoted-Printable .

Gyakori fejlécek
  • Return-Path:( RFC 821 , RFC 1123 ) - a visszaküldési cím meghiúsulás esetén, amikor lehetetlen a levél kézbesítése a célcímre. Eltérhet a MAIL FROMés fejléctől From:, Sender:vagy Reply-To:, de általában egyezik MAIL FROM.
  • Received:( RFC 822 , RFC 1123 ) - egy levél minden egyes levelezőszerveren (MTA) keresztül történő áthaladására vonatkozó adatok. Több levelezőszerveren való áthaladáskor (szokásos helyzet) új fejlécek kerülnek a korábbiak fölé, végül az átviteli napló fordított sorrendben (a címzetthez legközelebbi csomóponttól a legtávolabbiig) kerül megírásra.
  • MIME-Version:( RFC 1521 ) – A MIME - verzió , amellyel ez az üzenet létrejött. Gyakran ez a cím az összes többi előtt jön létre, így általában ez a legelső (vagyis az utolsó a listában).
  • From:( RFC 822 , RFC 1123 , RFC 1036 ) - a feladó neve és címe (ebben a fejlécben jelenik meg a feladó nevét tartalmazó szövegmező). Előfordulhat, hogy nem egyezik return-path, vagy akár nem is egyezik az SMTP-fejléccel MAIL FROM:.
  • Sender:( RFC 822 , RFC 1123 ) - a levél feladója. Hozzáadva annak jelzésére, hogy valaki (ahonnan) nevében egy levelet egy másik személy küldött (például egy titkár a főnök nevében). Egyes levelezőprogramok az üzenetet a feladó és a feladó jelenlétében „üzenetként a „feladótól” a „feladó” nevében” jelenítik meg. A feladó egy információs fejléc (és eltérhet az SMTP-fejléctől is MAIL FROM).
  • To:( RFC 822 , RFC 1123 ) – A címzett neve és címe. Többször is tartalmazható (ha a levél több címzettnek szól). E mező alapján alakul ki az SMTP mező tartalma RCPT TO.
  • Cc:( RFC 822 , RFC 1123 ) - (az angol  másodpéldányból ) tartalmazza a levél másodlagos címzettjeinek nevét és címét, amelyre a másolatot küldik. Részt vesz az SMTP mező RCPT TO, valamint a "Címzett" mező kialakításában.
  • Bcc:( RFC 822 , RFC 1123 ) - (az angol  vakmásolatból ) tartalmazza a levél címzettjeinek nevét és címét, akiknek a címét ne mutassuk meg más címzetteknek. Részt vesz az SMTP mező kialakításában RCPT TO, mint például a "Címzett" és a "Másolat" mező, de nincs jelen az elküldött üzenetben.
  • Reply-To:( RFC 822 , RFC 1036 ) az a név és cím, amelyre a levélre válaszolni kell. Ha például egy levelet robot küld, akkor annak Reply-Toa postafióknak a címe jelenik meg címként, amely készen áll a levélre válasz fogadására.
  • Message-ID:( RFC 822 , RFC 1036 ) – egyedi üzenetazonosító . A küldő gazdagép címéből és egy számból áll (a gazdagépen belül egyedi). Az egyedi számgenerálási algoritmus a szervertől/klienstől függ. Így néz ki: [email protected]. Más azonosítókkal együtt egy adott üzenet áthaladásának megkeresésére szolgál a levelezőrendszer naplóiban (a levelezőrendszerek a levél áthaladását rögzítik Message-ID), és más levelekből származó levélre mutat (az üzenetek csoportosítására és felépítésére szolgál). láncok). Általában a levelezőkliens (MUA) hozza létre a levél írásakor.
  • In-Reply-To:( RFC 822 ) - pontok, Message-IDamelyekre ez a levél válasz (ennek segítségével a levelezőkliensek könnyen felépíthetnek levelezési láncot - minden új válasz tartalmazza az előző üzenet Üzenetazonosítóját).
  • Subject:( RFC 822 , RFC 1036 ) – az e-mail tárgya.
  • Date:( RFC 822 , RFC 1123 , RFC 1036 ) – az e-mail elküldésének dátuma.
  • Content-Type:( RFC 1049 , RFC 1123 , RFC 1521 , RFC 1766 ) – az üzenettartalom típusa ( HTML , RTF, egyszerű szöveg) és az üzenet létrehozásának kódolása (lásd alább a kódolásokról).
  • Return-Receipt-To:( RFC 2076 ) – Az az e-mail, ahová a címzett levelezőszervere elküldi a kézbesítési értesítést. Az RFC 2076 a „Nem Internet szabvány” részben szerepel, ezért előfordulhat, hogy a szerverek nem támogatják.
  • Disposition-Notification-To:( RFC 3798 ) - e-mail, ahol a címzett levelezőprogramjának kézbesítési értesítést kell küldenie, ha a felhasználó engedélyezi (beállításokon, stb.).

A szabványosak mellett a levelezőkliensek, szerverek és levélfeldolgozók saját fejlécet is felvehetnek "X-"-vel kezdődően (például: X-Mailer, X-MyServer-Note-OKvagy X-Spamassasin-Level).

A levél törzse

A levél törzsét egy üres sor választja el a fejléctől. A nem smtp szabványokban a levél formátuma a rendszerszabványtól függ (például MAPI ), de mielőtt a levél "elhagyná" a MAPI-kompatibilis rendszert (például mielőtt elküldené az interneten), általában SMTP-kompatibilis formára konvertálva (egyébként az üzenetek továbbítása lehetetlen lenne, mert az internetes levélküldés szabványa az SMTP).

Csak nyomtatható karakterek megengedettek az üzenettörzsben. Ezért a bináris információk (képek, futtatható fájlok stb.) átviteléhez olyan kódolásokat használnak, amelyek az adatokat egy 7 bites formátumba - Base64 vagy UUE - juttatják el . Ráadásul az e-mail létezésének legelején a korlátozás szigorúbb volt - egyes levelezőrendszerek csak 7 bites üzeneteket támogattak. Az ilyen rendszerekkel való munkavégzés érdekében az egyszerű szöveg nemzeti karakterek jelenlétében 7 bites formában is kódolható. Ehhez a Base64 vagy a Quoted-Printable használatos . A csak 7 bites üzeneteket kezelni képes levelezőrendszerek azonban már alig léteznek.

Láncolt betűk

A levélben található egyedi azonosító miatt, valamint az a tény, hogy a levelezőkliensek túlnyomó többsége a levél megválaszolása során bemásolja annak azonosítóját a mezőbe In-Reply-To(„válaszként”), lehetővé válik a megbízható csoportosítsa az üzeneteket egy lánc mentén ( eng.  thread ). Ez a különböző e-mail kliensekben eltérő módon valósul meg. Például a Microsoft Outlook lehetővé teszi, hogy megtalálja az összes kapcsolódó e-mailt, és a Gmail webes felülete a száladatok alapján egyetlen objektumba csoportosítja az üzeneteket. Egyes e-mail kliensek (például a mutt ) lehetővé teszik a láncok (általában a levelezőlistákban, amikor sok feliratkozó van egy beszélgetésben) felépítését egy fa formájában (a kérdés több választ generált, amelyek mindegyikét kommentálták – ez több a fa ágai). Ezenkívül az ilyen ügyfelek általában tudják, hogyan kell erőszakkal elvágni a szálakat, amikor az üzenet tárgya megváltozik (feltételezve, hogy az üzenet tárgyának változása új vitát jelent, bár talán egy korábbi beszélgetés okozta).

E-mail titkosítás

Jelenleg két szabványt használnak széles körben a levelek titkosítására: az S/MIME -t (nyilvános kulcsú infrastruktúra használata) és az OpenPGP -t (a felhasználó köré csoportosuló bizalmi sémával rendelkező tanúsítványok használata).

Korábban voltak MOSS és PEM szabványok is , de az egymással való összeférhetetlenség és a használat kényelmetlensége miatt nem honosodtak meg.

Az S/MIME és az OpenPGP szabványok háromféle védelmet biztosítanak: változtathatóság, visszavonhatatlan aláírás és titkosság (titkosítás). Ezenkívül az S/MIME 3-as verziója lehetővé teszi a biztonságos visszaigazolás használatát (amelyben a levél átvételéről szóló visszaigazolás csak akkor generálható sikeresen, ha a levél sértetlenül megérkezett a címzetthez).

Mindkét szabvány szimmetrikus kriptográfiai algoritmusokat használ az üzenettörzs titkosításához, a szimmetrikus kulcsot pedig a címzett nyilvános kulcsa titkosítja. Ha a levelet emberek csoportjának címezték, akkor a szimmetrikus kulcsot felváltva titkosítják az egyes címzettek nyilvános kulcsai (és néha a kényelem kedvéért a feladó nyilvános kulcsa, hogy el tudja olvasni az általa küldött levelet). .

Kereskedelmi felhasználás

Jelenleg a levelezőrendszerek kereskedelmi felhasználásának következő modelljei vannak:

  • Otthoni és vállalati levelezőrendszerek - a levelezőrendszer tulajdonosának saját vagy bérelt berendezésén működnek (általában ő a tulajdonosa annak a tartománynak is, amelyben a levelezőszerver működik).
  • Az e-mailek fogadásának/küldésének szolgáltatását harmadik fél biztosítja. A szervezet (személy) birtokolja a domaint, és önállóan tárolja a levelezési archívumot.
  • A levelek fogadására/küldésére és tárolására vonatkozó szolgáltatásokat harmadik fél szervezet saját létesítményeiben végzi. A megrendelő hozzáférést kap a vállalkozó levélküldési és levéltári rendszeréhez. A levelezési domain az ügyfél tulajdona.
  • A levelek fogadását, küldését, tárolását a végrehajtó végzi, a levelező domain a végrehajtóé. Ezeknek a szolgáltatásoknak a többsége ingyenes, és hirdetések megjelenítésével működik a felhasználó számára, vagy ingyenes kiegészítésként szolgál az előadó egyéb szolgáltatásaihoz (további részletekért lásd: Ingyenes levelezési szolgáltatások ).

Levelezőlisták

A levelezőrendszer lehetővé teszi összetett rendszerek szervezését, amelyek egytől több előfizető felé továbbítják a leveleket, ezek a következők:

  • Levelezőlisták - azonos (vagy a sablon szerint változó) tartalmú, azonos címről érkező levél, amelyet a levelezőlista feliratkozóinak küldenek . Technikailag úgy szervezhető, hogy több e-mailt küld (sablon e-mailekhez használjuk), vagy több címzettet küld (a TO, CC, BCC mezőkben). A nagy levelezőlisták (több mint 10-50 előfizető) kezelésére speciális programokat használnak (például mailman ). Megfelelően szervezett levelezőlista szabályozza a levelek (a levél kézbesítésének lehetetlenségéről szóló üzenetek) visszaküldését, kizárva a nem elérhető címzetteket a levelezőlistáról, lehetővé tegye az előfizetők számára a levelezőlistákról való leiratkozást. A nem kívánt leveleket spamnek nevezik , és jelentősen megnehezítik a levelezőrendszerek működését.
  • A levelezési csoportok egy speciális típusú levelezőlista, amelyben a csoport címére (egy speciális program által feldolgozott szokásos postai címre) küldött levelet a csoport minden tagja megkapja. A sajtókonferenciák, visszhangkonferenciák analógja. A megfelelően konfigurált levelezőlistának ellenőriznie kell a ciklusokat (két egymásra feliratkozott levelezőrobot képes végtelen levélküldési hurkot létrehozni), korlátoznia kell a levelezőlistán résztvevők listáját, akik jogosultak üzenetet küldeni, és teljesítenie kell a levelezőlista egyéb követelményeit. .

A levelezési listakezelők a levelezőlisták kezelésére szolgálnak . A címlista vezetése és az adott üzenet elküldése mellett biztosítják a levelek szűrését, a levelek levelezőlistára helyezés előtti előzetes moderálásának lehetőségét, archívumok kezelését, előfizetés/leiratkozás kezelését, kivonatok postázását (rövid tartalom) a teljes levelezési kötet helyett.

Példák levelezőprogramokra:

Spam

A spam egyfajta (gyakran kéretlen) termék vagy szolgáltatás reklámozását célzó levélküldés, a papíralapú reklám analógja, amelyet ingyenesen terjesztenek a lakóépületek postaládáiban.

Ahogy az e-mail egyre népszerűbb lett, azt (a usenet hírcsoportokkal együtt ) kezdték használni kéretlen promóciós üzenetek küldésére, hasonlóan ahhoz, ahogy a brosúrákat a hagyományos postafiókokba dobják. A papíralapú levelezőlista jelentős költségétől eltérően azonban jelentős mennyiségű (millió és milliárd) üzenet elküldése gyakorlatilag semmibe sem kerül a feladónak. Ez a reklámküldemények számának és méretének aránytalan növekedéséhez vezetett (egyes adatok szerint [14] jelenleg az összes levél 70-90%-át a spam teszi ki, vagyis 2-10-szeresével haladja meg a levél terhelhetőségét). .

A kéretlen levelek küldésére jelenleg minden lehetséges technikai trükköt alkalmaznak: nyílt továbbítók , továbbküldők , proxyszerverek, ingyenes e-mail szerverek (lehetővé teszik a levélküldés automatizálását), botnetek , hamis üzenetek a kézbesítés lehetetlenségéről.

A reklámtilalom szigorításával az üzeneteket legitim (amelyekre a felhasználó általában előfizet, és bármikor visszautasíthatja) és illegitim (valójában spamnek nevezett) levelekre osztották. A kéretlen levelek leküzdésére különféle mechanizmusokat fejlesztettek ki ( fekete listák a feladókról, szürke listák , amelyekhez újra el kell küldeni a levelezőszervert, környezetszűrők). A levélszemét-elhárító eszközök bevezetésének egyik következménye az volt, hogy a levélszeméttel kapcsolatban „ hamis pozitív ” döntés született, vagyis a nem spam levelek egy részét elkezdték spamként megjelölni. Agresszív levélszemét-ellenes politika (a spamnek tűnő üzenetek automatikus megsemmisítése a feladó/címzett értesítése nélkül) ez nehezen észlelhető levélforgalmi problémákhoz vezet.

Jogalkotási szabályozás Oroszországban

152-FZ szövetségi törvény "A személyes adatokról" .

A legnépszerűbb e-mail szolgáltatások

A legnépszerűbb e-mail szolgáltatásokat informatikai cégek biztosítják más webes termékek mellett: keresőmotorok, felhőtárhely stb. Az orosz nyelvű e-mail szolgáltatásokat a Google ( Gmail ), a Yandex ( Yandex.Mail ), a Mail.ru ( Mail.ru ), a Microsoft ( Hotmail és Outlook ) fejleszti.

Lásd még

Jegyzetek

  1. ↑ 1 2 E-mail - Szótár - SeoPult.Ru .
  2. ↑ Az e-mail elveszett kötőjel
  3. ↑ ComputerPress magazin 6'2001 - Internetes levelezés
  4. ↑ 1 2 Kérdés: 220471 Gramota.ru
  5. ↑ Válasz keresése . new.gramota.ru. Hozzáférés időpontja: 2019. március 14.
  6. ↑ Kérdés: 275417 Gramota.ru
  7. ↑ Szó keresése: "*m?ile" minta keresése
  8. ↑ Szótár keresés - Szóellenőrzés: * mail Gramota.ru
  9. ↑ MuttWiki: MailConcept (downlink) . Letöltve: 2009. szeptember 5. Az eredetiből archiválva : 2008. december 16.. 
  10. ↑ POP3 Connector for Exchange 2003 (SBS2003) az Exchange Admin alkalmazásban  (lefelé irányuló kapcsolat)
  11. ↑ RFC 5321: 4.5.5. Üzenetek nulla fordított útvonallal
  12. ↑ Visszahívás ellenőrzése
  13. ↑ Jelenleg egy sor szabványt fejlesztettek ki a nemzeti karakterek e-mailben történő támogatására ( RFC 6531 , RFC 6532 , RFC 6533 ), de nem minden szoftver támogatja ezt.
  14. ↑ Securelist – Spam 2009 májusában A Kaspersky Lab szerint 2009 májusában a spam a teljes levélváltás 70-90%-át tette ki.

Linkek

  • RFC 822  – Szabvány az ARPA internetes szöveges üzenetekhez
  • RFC 2142  – Postafióknevek a közös szolgáltatásokhoz, szerepkörökhöz és funkciókhoz
  • RFC 2368  – A mailto URL-séma
  • RFC 5322  – Internetes üzenetformátum
  • RFC 2045  – Internetes üzenettestek formátuma
  Ugrás a Wikidata elemre  Szótárak és enciklopédiák
 Számítógépes kommunikáció
Aszinkron konferencia
Szinkron konferencia
Publikációk