E-post

Elektronisk post ( engelsk  e-post, e-post [ i ˈm e ɪl ] , från engelska  elektronisk post ) är en teknik och tjänst för att skicka och ta emot elektroniska meddelanden (kallade "brev", "e-postmeddelanden" eller "meddelanden") mellan användare av ett datornätverk (inklusive Internet ) [1] .

E-post, när det gäller sammansättningen av element och funktionsprincipen, upprepar praktiskt taget systemet med vanlig (pappers) post och lånar både termer (post, brev, kuvert, bilaga, box, leverans och andra) och karakteristiska egenskaper - användarvänlighet, förseningar i meddelandeöverföring, tillräcklig tillförlitlighet och samtidigt ingen garanti för leverans.

Fördelarna med e-post är: adresser med formen användarnamn@ domännamn (till exempel nå[email protected]) är lätt att uppfatta och komma ihåg av en person; förmågan att överföra både vanlig text och formaterade, såväl som godtyckliga filer ( textdokument , mediefiler, program, arkiv , etc. [1] ); oberoende av servrar (i det allmänna fallet adresserar de varandra direkt); tillräckligt hög tillförlitlighet för meddelandeleverans; användarvänlighet för en person och program, hög hastighet för meddelandeöverföring.

Nackdelar med e-post: förekomsten av ett sådant fenomen som spam (massreklam och virala utskick ); möjliga förseningar i meddelandeleverans (upp till flera dagar); gränser för storleken på ett meddelande och för den totala storleken på meddelanden i brevlådan (personligt för användare).

För närvarande kan alla nybörjare starta sin egen gratis e-postlåda, bara registrera sig på en av internetportalerna.

Namn

Om i Europa, Amerika och andra regioner endast två alternativ används när du skriver - "e-post" eller "e-post" (desutom varierar rekommendationerna om huruvida man ska skriva ett bindestreck eller inte: till exempel sedan mars 2011, en av de stilistiska riktlinjer är AP Stylebook - rekommenderar att skriva förkortningen för "elektronisk post" som "e-post" och inte "e-post" [2] ), då finns det betydande variationer på ryska. Oftast Kyrilliska texter använder också "e-post", det vill säga att skriva på latin utan translitteration (visuell uppfattning om andra former av skrift är sämre ). Men du kan hitta andra stavningar:

Informationsbyrån för Gramota.ru indikerade först att det rekommenderades att skriva e-post (latin) eller e- post (kyrillisk) [4] , och sedan började den endast rekommendera den kyrilliska stavningen av e- post , som registrerats, till exempel, i Ryska vetenskapsakademiens ryska stavningsordbok [5] [6] .

Ordböckerna registrerade fyra varianter av stavningar: e- post , post [7] e-post , e-post [8] .

De facto i officiella ryskspråkiga dokument[ vad? ] :

Historik

Framväxten av e-post kan spåras tillbaka till 1965 , när Massachusetts Institute of Technology (MIT) anställda Noel Morris och Tom Van Vleck skrev e- postprogrammet för operativsystemet CTSS (Compatible Time-Sharing System) installerat på en IBM 7090/ 7094 dator.

Den allmänna utvecklingen av e-post har skett genom utvecklingen av lokal användarinteraktion på fleranvändarsystem. Användare kunde, med hjälp av e-postprogrammet (eller motsvarande), vidarebefordra meddelanden till varandra inom samma stordator (stor dator). Nästa steg var att kunna vidarebefordra meddelandet till en användare på en annan maskin genom att ange maskinnamn och användarnamn på maskinen. Adressen kan skrivas som foo!joe(användare joe på datorfoo). Det tredje steget i utvecklingen av e-post inträffade med tillkomsten av överföringen av brev genom en tredje dator. Vid användning av UUCP inkluderade användarens adress en rutt till användaren genom flera mellanliggande maskiner (till exempel gate1!gate2!foo!joe ett brev för joe genom maskinporten1, gate2 till maskinen foo). Nackdelen med denna adressering var att avsändaren (eller administratören av maskinen som avsändaren körde på) behövde veta den exakta sökvägen till destinationsmaskinen.

Efter tillkomsten av det distribuerade globala namnsystemet DNS började domännamn användas för att indikera adressen - [email protected] - användaren på example.com-maskinen. Samtidigt tänkte man om konceptet "på en maskin": dedikerade servrar började användas för e-post, som vanliga användare (endast administratörer) inte hade tillgång till, och användare arbetade på sina maskiner, medan e-post inte hade tillgång till komma till användarnas arbetsstationer, men till brevlådor, en server varifrån användarna hämtade sin post med hjälp av olika nätverksprotokoll (bland de vanligaste för tillfället är POP3 , IMAP , MAPI , webbgränssnitt). Samtidigt med tillkomsten av DNS uppfanns ett system för att reservera postleveransrutter, och domännamnet i postadressen upphörde att vara namnet på en specifik dator och blev bara ett fragment av postadressen. Många servrar kan vara ansvariga för att underhålla en domän (kanske fysiskt placerad på olika kontinenter och i olika organisationer), och användare från samma domän kanske inte har något gemensamt med varandra (detta gäller särskilt för användare av gratis e-postservrar).

Dessutom fanns det andra e-postsystem (varav några fortfarande finns), såsom: Netmail på Fidonet -nätverket , X.400 på X.25 -nätverk[ specificera ] . Tillgång till dem från Internet och vice versa sker via en e-postgateway . För att dirigera e-post i X.25-nätverk tillhandahåller DNS en speciell resurspost med det lämpliga namnet X25 (kod 19).

Kronologi

MxA-klassificering

Följande komponenter särskiljs i terminologin för e-post:

Vid användning av dedikerade servrar för lagring av användarpost kan all interaktion mellan användaren och servern ske med protokoll som inte passar in i detta schema.

Mailservrar fungerar vanligtvis som MTA och MDA. Vissa e-postservrar (program) utför funktionen av både MTA och MDA, vissa involverar uppdelning i två oberoende servrar: MTA-server och MDA-server (i det här fallet, om olika protokoll används för att komma åt brevlådan, till exempel POP3 och IMAP , då MDA kan i sin tur implementeras antingen som en enda applikation eller som en uppsättning applikationer, som var och en ansvarar för ett separat protokoll).

Modern arkitektur (SMTP)

Världens mest accepterade protokoll för e- postutbyte är SMTP ( simple mail transfer protocol  ). I en vanlig implementering använder den DNS för att fastställa regler för vidarebefordran av e-post (även om i privata system som Microsoft Exchange kan SMTP agera baserat på information från andra källor).  

Olika domäner har sina egna oberoende e-postsystem. Varje e-postdomän kan ha flera användare. (Men i själva verket kan det vara så att en organisation eller person äger många domäner som betjänas (fysiskt) av ett e-postsystem). E-post överförs mellan noder med hjälp av e-postöverföringsprogram ( engelsk  e-postöverföringsagent , MTA ; som till exempel: sendmail , exim 4, postfix , Microsoft Exchange Server , Lotus Domino , etc.). Systemens beteende när de kommunicerar med varandra är strikt standardiserat, för detta används SMTP-protokollet (och överensstämmelse med denna standard, tillsammans med universellt DNS-stöd av alla deltagare, är grunden för möjligheten att kommunicera "alla till alla" utan tidigare avtal). Interaktionen mellan e-postsystemet och användarna är generellt sett inte reglerad på något sätt och kan vara godtycklig, även om det finns både öppna och slutna (kopplade till mjukvara från specifika tillverkare) protokoll för interaktion mellan användare och e-postsystemet. Programmet som körs i mailsystemet och betjänar användare kallas MDA ( mail delivery agent ) .  I vissa e-postsystem kan MDA och MTA kombineras till ett program, i andra system kan de separeras som separata program, eller till och med köras på olika servrar. Programmet som användaren använder kallas MUA ( mail user agent ) . Om webbgränssnittet används för att arbeta med e-post, utförs dess funktion av webbgränssnittsapplikationen som körs på servern.  

Inom ett givet e-postsystem (vanligtvis inom samma organisation) kan det finnas många e-postservrar som utför både vidarebefordran av e-post inom organisationen och andra e-postrelaterade uppgifter: skräppostfiltrering, antivirusskanning av bilagor, autosvar, inkommande/utgående e-post arkivering, ger åtkomst till användare med olika metoder (från POP3 till ActiveSync ). Interaktion mellan servrar inom samma e-postsystem kan antingen vara föremål för allmänna regler (användning av DNS och regler för e-postdirigering med SMTP-protokoll), eller följa företagets egna regler (den programvara som används).

Reläer

Med DNS kan du som mottagande server ( MX-post ) ange vilken Internetvärd som helst, inte nödvändigtvis en del av mottagardomänens domänzon . Detta kan användas för att ställa in vidarebefordran (vidarebefordran) av e-post via tredje servrar. En tredje parts server (till exempel mer pålitlig än användarens servrar) accepterar e-post för användarens domän och vidarebefordrar den till användarens e-postservrar så snart som möjligt. Historiskt sett fanns det ingen kontroll över "till vem man skulle vidarebefordra" e-post (eller så gavs det inte vederbörlig vikt), och servrar utan sådan kontroll vidarebefordrade e-post till några domäner. Sådana servrar kallas öppna reläer (för närvarande dyker nya öppna reläer upp främst på grund av konfigurationsfel).

För sina användare är e-postsystemservrar reläer (användare skickar inte e-post till mottagarens e-postsystemservrar, utan till "sin" e-postserver, som vidarebefordrar brev vidare). I många leverantörsnätverk är möjligheten att skicka brev via SMTP -protokoll utanför nätverket stängd (på grund av användningen av denna funktion av trojaner , virus ). I det här fallet tillhandahåller leverantören sin egen SMTP-server, genom vilken all e-post skickas utanför nätverket. I det här fallet anses ett öppet relä vara ett sådant relä som inte kontrollerar om användaren är "vänner" (kontrollen kan utföras både på basis av nätverksadressen till användarens dator, och på basis av användaridentifiering med lösenord/certifikat).

Mail routing

E-postservern, efter att ha tagit emot e-post (från en lokal källa eller från en annan server), kontrollerar om det finns specifika regler för behandling av e-post (regler kan baseras på ett användarnamn, på en domän i en adress, på innehållet i ett brev , etc.), om det inte finns några specifika regler, kontrollerar den om e-postdomänen är lokal för servern (det vill säga om servern är den slutliga mottagaren av meddelandet). Om så är fallet, accepteras brevet för behandling. Om e-postdomänen inte är lokal tillämpas e-postdirigeringsproceduren (som är grunden för överföring av brev mellan olika servrar på Internet).

Routing använder endast domändelen av destinationsadressen (det vill säga delen efter @-symbolen). För mottagardomänen letas alla MX-poster upp. De är sorterade i fallande prioritetsordning. Om e-postserveradressen matchar en av de värdar som anges i MX-posterna kasseras alla poster med lägre prioritet än värdens prioritet i MX-posten (liksom MX-posten för själva värden) och leverans sker till de första svarande värdena prövas i fallande prioritetsordning). Detta görs om avsändarens e-postserver är ett relä till mottagarens e-postserver. Om MX-posten för domänen inte hittas, görs ett försök att leverera e-post med A-posten som motsvarar domänen. Om det inte finns någon post om domänen genereras ett meddelande om omöjligheten av leverans (avvisningsmeddelande). Detta meddelande genereras med MAIL FROM:<>( RFC 5321 ), fältet "Till" anger avsändaren av det ursprungliga meddelandet och fältet "Från" anger ett e-postmeddelande i formuläret MAILER-DAEMON@имя сервера. Servernamnet är namnet på internetvärden som genererade meddelandet. MAIL FROM:<>låter dig skydda e-postservrar från ändlös cirkulation av felmeddelanden mellan servrar - om servern upptäcker att den inte kan leverera ett brev med en tom returadress, förstör den det. Ett meddelande om omöjligheten av leverans kan också genereras efter ett tag. Detta inträffar om det upptäckta problemet bedöms vara övergående, men meddelandeköns timeout löper ut ( RFC 5321 , avsnitt 4.5.4.1. Sändningsstrategi).

Om nätverket har olika DNS-servrar (till exempel externa - på Internet och lokalt - inom sina egna gränser), så är det möjligt att de "interna" DNS-servrarna pekar på en server som inte är tillgänglig på Internet som den högsta prioritetsmottagare, där e-post omdirigeras från relä som anges som destinationsvärd för Internet. Denna uppdelning gör att post kan dirigeras enligt vanliga regler mellan servrar som inte har tillgång till Internet.

E-postmottagningsprotokoll

När e-posten når målservern lagras den mottagna e-posten tillfälligt eller permanent. Det finns två olika modeller för att arbeta med post: konceptet med en postbutik ( box ) och en postterminal .

POP3

I konceptet e- postlagring lagras e-post på servern tillfälligt, i en begränsad volym (liknande en brevlåda för papperspost), och användaren kommer med jämna mellanrum åt brevlådan och "hämtar" brev (det vill säga att e-postklienten laddar ner en kopia av brevet till sig själv och raderar originalet från brevlådan) . Baserat på detta koncept fungerar POP3- protokollet .

IMAP

Konceptet med en e-postterminal innebär att all korrespondens som är associerad med en brevlåda (inklusive kopior av skickade brev) lagras på servern, och användaren kommer åt arkivet (ibland traditionellt även kallat "brevlåda") för att se korrespondens (både ny och arkiv) och skriva nya brev (inklusive svar på andra brev). IMAP-protokollet och de flesta webbgränssnitt för gratis e-posttjänster fungerar enligt denna princip . Sådan lagring av e-postkorrespondens kräver betydligt mer kapacitet från e-postservrar, vilket gör att det i många fall finns en separation mellan e-postservrar som vidarebefordrar e-post- och e-postlagringsservrar.

Skillnader

Baserat på hur protokollen fungerar kan de delas in efter två huvudkriterier:

Under vissa förhållanden kan e-postlagringsservern konfigureras för att bete sig på samma sätt som klienten: en sådan server kommer åt e-postservern med POP3-protokollet och tar emot e-post för sig själv. Sådana lösningar används vanligtvis i små organisationer som inte har infrastrukturen för att distribuera fullfjädrade e-postservrar; i detta fall används en lokal server för att lagra e-post och leverantörens e-postserver som tillhandahåller tjänsten att ta emot e-post via POP3 (till exempel genom att använda fetchmail ). Den största nackdelen med en sådan lösning är förseningen i leveransen (eftersom programvaran som samlar in e-post kommer åt servrarna med viss fördröjning) - till exempel tillåter POP3-anslutningen från Exchange 2003 Server som en del av Windows SBS inte att ställa in ett intervall på mindre än 15 minuter genom konfigurationsgränssnittet [10] eftersom överdriven frekvens av kontroller kan orsaka problem med belastningen på e-postservern. Vissa e-postservrar har funktioner som skyddar mot detta beteende.

Bokstavens struktur

Vid överföring med SMTP-protokollet består ett e-postmeddelande av följande delar.

SMTP Envelope Data

SMTP-kuvertdata innehåller parametrar som ställs in av kommandon med samma namn:

E-postrubriker

E-postrubriker beskrivs av RFC- standarder :

Rubriker separeras från brevets brödtext med en tom rad. Rubriker används för att logga passagen av ett brev och serviceanteckningar (kallas ibland kludges ). I Microsoft Outlook kallas dessa rubriker "Internet Headers". Rubrikerna indikerar vanligtvis: e-postservrarna genom vilka brevet passerade (varje e-postserver lägger till information om vem den tog emot detta brev från), information om huruvida det här brevet ser ut som skräppost, information om antivirusskanning, graden av brådska för brevet ( kanske byta e-postservrar). Även i rubriken skrivs vanligtvis programmet med vilket brevet skapades. Eftersom rubrikerna är proprietär information döljer e-postklienter dem oftast för användaren vid normal läsning av meddelanden, men ger även möjlighet att se dessa rubriker om det finns behov av en mer detaljerad analys av meddelandet. Om ett e-postmeddelande från SMTP-format konverteras till ett annat format (till exempel e-postmeddelanden konverteras till MAPI i Microsoft Exchange 2007), sparas rubrikerna separat för att möjliggöra diagnostik.

Rubriker läggs vanligtvis till nedifrån och upp (det vill säga varje gång en rubrik behöver läggas till ett meddelande läggs den till på första raden, före alla föregående).

Förutom tjänstinformation lagrar e-postrubriker även information som visas för användaren, detta är vanligtvis avsändaren av brevet, mottagaren, ämne och datum för sändningen.

Meddelandehuvuden kan bara innehålla 7-bitars tecken [13] . Om det är nödvändigt att använda nationella tecken i vissa fält, krävs användning av kodningar. Vanligtvis är detta Base64 eller Quoted-Printable .

Vanliga rubriker
  • Return-Path:( RFC 821 , RFC 1123 ) - returadressen i händelse av misslyckande, när det är omöjligt att leverera brevet till destinationsadressen. Kan skilja sig från MAIL FROMoch rubriker From:, Sender:eller Reply-To:, men matchar vanligtvis MAIL FROM.
  • Received:( RFC 822 , RFC 1123 ) - data om passage av ett brev genom varje specifik e-postserver (MTA). När man passerar flera e-postservrar (den vanliga situationen) läggs nya rubriker till ovanpå de tidigare, så småningom kommer överföringsloggen att skrivas i omvänd ordning (från noden närmast mottagaren till längst bort).
  • MIME-Version:( RFC 1521 ) - MIME- versionen med vilken detta meddelande skapades. Ofta skapas denna titel före alla andra, så det är vanligtvis den allra första (det vill säga den sista i listan).
  • From:( RFC 822 , RFC 1123 , RFC 1036 ) - avsändarens namn och adress (det är i denna rubrik som textfältet med avsändarens namn visas). Kanske inte matchar return-patheller ens matchar SMTP-huvudet MAIL FROM:.
  • Sender:( RFC 822 , RFC 1123 ) - avsändaren av brevet. Tillagt för att kunna ange att ett brev för någons (från) räkning har skickats av en annan person (exempelvis en sekreterare för chefens räkning). Vissa e-postklienter visar meddelandet i närvaro av avsändaren och från som "meddelande från 'avsändare' på uppdrag av 'från'". Avsändaren är ett informationshuvud (och kan också skilja sig från SMTP-huvudet MAIL FROM).
  • To:( RFC 822 , RFC 1123 ) - Mottagarens namn och adress. Det kan innehållas flera gånger (om brevet är adresserat till flera mottagare). Baserat på detta fält bildas innehållet i SMTP-fältet RCPT TO.
  • Cc:( RFC 822 , RFC 1123 ) - (från den engelska  karbonkopian ) innehåller namn och adresser till de sekundära mottagarna av brevet som kopian skickas till. Deltar i bildandet av SMTP-fältet RCPT TOsamt "Till"-fältet.
  • Bcc:( RFC 822 , RFC 1123 ) - (från den engelska  blinda karbonkopian ) innehåller namn och adresser till mottagarna av brevet, vars adresser inte ska visas för andra mottagare. Deltar i bildandet av SMTP-fältet RCPT TO, som "Till"- och "Cc"-fälten, men finns inte i det skickade meddelandet.
  • Reply-To:( RFC 822 , RFC 1036 ) är namnet och adressen till vilket svar på detta brev ska adresseras. Om till exempel ett brev skickas av en robot, kommer Reply-Toadressen till brevlådan som är redo att ta emot ett svar på brevet att anges som adress.
  • Message-ID:( RFC 822 , RFC 1036 ) - en unik meddelandeidentifierare . Består av adressen till den sändande värden och ett nummer (unik inom värden). Algoritmen för unik nummergenerering beror på servern/klienten. Ser ut så här: [email protected]. Tillsammans med andra identifierare används den för att söka efter passagen av ett specifikt meddelande genom e-postsystemloggarna (postsystem registrerar passagen av ett brev med dess Message-ID) och för att peka på ett brev från andra bokstäver (används för att gruppera och bygga meddelanden kedjor). Vanligtvis skapas av e-postklienten (MUA) vid tidpunkten för skrivelsen.
  • In-Reply-To:( RFC 822 ) - pekar på Message-IDvilka detta brev är ett svar (med hjälp av detta kan e-postklienter enkelt bygga en korrespondenskedja - varje nytt svar innehåller meddelande-ID för det föregående meddelandet).
  • Subject:( RFC 822 , RFC 1036 ) — ämnet för e-postmeddelandet.
  • Date:( RFC 822 , RFC 1123 , RFC 1036 ) — datumet då e-postmeddelandet skickades.
  • Content-Type:( RFC 1049 , RFC 1123 , RFC 1521 , RFC 1766 ) — meddelandeinnehållstyp ( HTML , RTF , oformaterad text) och kodning i vilken meddelandet skapades (se nedan om kodningar).
  • Return-Receipt-To:( RFC 2076 ) - E-postmeddelandet dit mottagarens e-postserver ska skicka leveransaviseringen. RFC 2076 nämns i avsnittet "Inte Internetstandard" och stöds därför kanske inte av servrar.
  • Disposition-Notification-To:( RFC 3798 ) - e-post där mottagarens mailklient ska skicka ett leveransmeddelande om användaren tillåter det (genom inställningar etc.).

Utöver de vanliga kan e-postklienter, servrar och e-postprocessorer lägga till sina egna rubriker som börjar med "X-" (till exempel: X-Mailer, X-MyServer-Note-OKeller X-Spamassasin-Level).

Brödtexten

Bokstavens brödtext är separerad från rubriken med en tom rad. I icke-smtp-standarder beror formatet på brevet på systemstandarden (till exempel MAPI ), men innan brevet "lämnar" det MAPI-kompatibla systemet (till exempel innan det skickas över Internet) är det vanligtvis konverteras till SMTP-kompatibel form (annars skulle meddelandedirigeringen vara omöjlig eftersom standarden för att skicka e-post på Internet är SMTP).

Endast utskrivbara tecken är tillåtna i meddelandetexten. Därför, i syfte att överföra binär information (bilder, körbara filer, etc.), används kodningar som för data till en 7-bitars form - Base64 eller UUE . Dessutom, i början av e-postens existens, var begränsningen mer allvarlig - vissa e-postsystem stödde endast 7-bitars meddelanden. För att fungera med sådana system kan vanlig text, i närvaro av nationella tecken, också kodas i 7-bitars form. Base64 eller Quoted-Printable används för detta . Men e-postsystem som bara kan hantera 7-bitars meddelanden finns knappast nu.

Kedjebokstäver

På grund av förekomsten av en unik identifierare i brevet, samt det faktum att de allra flesta e-postklienter, när de svarar på ett brev, kopierar dess identifierare i fältet In-Reply-To("som svar på"), blir det möjligt att tillförlitligt gruppmeddelanden längs en kedja ( eng.  tråd ). Detta implementeras olika i olika e-postklienter. Till exempel låter Microsoft Outlook dig hitta alla relaterade e-postmeddelanden, och Gmails webbgränssnitt grupperar meddelanden baserat på tråddata i ett enda objekt. Vissa e-postklienter (som mutt ) låter dig strukturera kedjor (som vanligtvis bildas i e-postlistor när det finns många prenumeranter i en konversation) i form av ett träd (frågan genererade flera svar, som var och en kommenterades - detta bildade flera grenar av trädet). Sådana klienter vet också vanligtvis hur man tvångsklipper trådarna när ämnet för meddelandet ändras (förutsatt att ändringen i ämnet för meddelandet innebär en ny diskussion, även om det kanske orsakas av en tidigare konversation).

E-postkryptering

Två standarder används för närvarande i stor utsträckning för e-postkryptering: S/MIME (med en offentlig nyckelinfrastruktur) och OpenPGP (med certifikat med ett förtroendeschema som grupperar sig runt användaren).

Tidigare fanns det också MOSS- och PEM- standarder , men på grund av inkompatibilitet med varandra och besvär med användning slog de inte rot.

S/MIME- och OpenPGP-standarderna tillhandahåller tre typer av skydd: mutabilitet, oåterkallelig signatur och konfidentialitet (kryptering). Dessutom tillåter S/MIME version 3 användning av säker bekräftelse (där en bekräftelse på mottagande av ett brev endast kan genereras framgångsrikt om brevet har nått mottagaren intakt).

Båda standarderna använder symmetriska kryptografiska algoritmer för att kryptera meddelandekroppen, och den symmetriska nyckeln krypteras med mottagarens publika nyckel. Om brevet är adresserat till en grupp människor, krypteras den symmetriska nyckeln i sin tur av var och en av mottagarnas publika nycklar (och ibland, för enkelhetens skull, av avsändarens offentliga nyckel så att han kan läsa brevet som skickats av honom). .

Kommersiell användning

För närvarande finns det följande modeller för kommersiell användning av postsystem:

  • Hem- och företagspostsystem - fungerar på ägarens egen eller hyrda utrustning av postsystemet (vanligtvis är han också ägare till domänen där e-postservern är verksam).
  • Tjänsten att ta emot/skicka e-post tillhandahålls av en tredje part. Organisationen (personen) äger domänen och lagrar självständigt korrespondensarkivet.
  • Tjänster för att ta emot/sända och lagra post utförs av en tredjepartsorganisation vid dess egna anläggningar. Beställaren får tillgång till entreprenörens system för att skicka brev och för att komma åt brevarkivet. E-postdomänen ägs av kunden.
  • Mottagning, sändning, lagring av brev utförs av exekutor, postdomänen tillhör exekutor. De flesta av dessa tjänster är gratis och fungerar genom att visa annonser för användaren eller är ett kostnadsfritt tillägg till andra tjänster från utföraren (för mer information, se: Gratis e-posttjänster ).

E-postlistor

E-postsystemet låter dig organisera komplexa system baserat på vidarebefordran av e-post från en till många abonnenter, dessa är:

  • E-postlistor - ett brev från samma adress med samma (eller ändras enligt mallen) innehåll, skickat till e-postlistaprenumeranter . Tekniskt sett kan det organiseras som att skicka flera e-postmeddelanden (används för e-postmall) eller att skicka e-postmeddelanden med flera mottagare (i TILL, CC, BCC-fält). För att hantera stora e-postlistor (mer än 10-50 prenumeranter) används specialiserade program (till exempel postman ). En korrekt organiserad e-postlista bör kontrollera returen av brev (meddelanden om omöjligheten att leverera ett brev) med uteslutande av otillgängliga mottagare från e-postlistan, tillåta prenumeranter att avregistrera sig från e-postlistor. Oönskade utskick kallas skräppost och komplicerar avsevärt funktionen hos postsystem.
  • Korrespondensgrupper är en specialiserad typ av e-postlista där ett brev till gruppadressen (en vanlig postadress som behandlas av ett specialiserat program) skickas till alla medlemmar i gruppen. Det är en analog av nyhetskonferenser, ekokonferenser. En korrekt konfigurerad e-postlista bör kontrollera cykler (två sändningsrobotar som prenumererar på varandra kan skapa en oändlig loop av att skicka brev), begränsa listan över e-postlistdeltagare som har rätt att skicka ett meddelande och uppfylla andra krav på e-postlistor .

E-postlisthanterare används för att hantera e-postlistor . Förutom att upprätthålla en lista med adresser och skicka ett givet meddelande, tillhandahåller de filtrering av brev, möjlighet till förmoderering av brev innan de placeras i e-postlistan, underhåll av arkiv, hantera prenumeration / avanmälan, utskick av sammanfattningar (kort innehåll) istället för hela utskickningsvolymen.

Exempel på program för e-posthantering:

Spam

Spam är ett slags utskick i syfte att marknadsföra (ofta oönskat) en viss produkt eller tjänst, en analog av pappersreklam som distribueras gratis i brevlådorna i bostadshus.

När e-post växte i popularitet började den (tillsammans med usenet-nyhetsgrupper ) användas för att skicka ut oönskade reklammeddelanden, liknande hur broschyrer släpps i vanliga brevlådor. Men till skillnad från den betydande kostnaden för en pappersutskick, kostar det praktiskt taget ingenting för avsändaren att skicka en betydande mängd (miljoner och miljarder) meddelanden. Detta ledde till en oproportionerlig ökning av antalet och storleken på reklamutskick (enligt vissa uppgifter [14] står skräppost för närvarande för 70–90 % av alla e-postmeddelanden, det vill säga det översteg postens nyttolast med 2–10 gånger) .

För att skicka spam används för närvarande alla möjliga tekniska knep: öppna reläer , remailers , proxyservrar, gratis e-postservrar (som tillåter automatisering av att skicka e-post), botnät , falska meddelanden om omöjligheten av leverans.

Med skärpningen av förbudet mot reklam delades meddelandena upp i legitima utskick (som användaren vanligtvis prenumererar på och som han kan vägra när som helst) och illegitima (kallas faktiskt spam). För att bekämpa spam har olika mekanismer utvecklats ( svarta listor över avsändare, grå listor som kräver att e-postservern skickas igen, sammanhangsfilter). En av konsekvenserna av införandet av anti-spam-verktyg var möjligheten till ett " falskt positivt " beslut angående spam, det vill säga en del av brev som inte är spam började markeras som spam. I fallet med en aggressiv anti-spam policy (förstörelse av meddelanden som ser ut att vara spam automatiskt utan att meddela avsändaren/mottagaren), leder detta till svårupptäckta e-postflödesproblem.

Lagstiftning i Ryssland

Federal lag nr 152-FZ "Om personuppgifter" .

De mest populära e-posttjänsterna

De mest populära e-posttjänsterna tillhandahålls av IT-företag tillsammans med andra webbprodukter: sökmotorer, molnlagring, etc. Ryskspråkiga e-posttjänster utvecklas av Google ( Gmail ), Yandex ( Yandex.Mail ), Mail.ru ( Mail.ru ), Microsoft ( Hotmail och Outlook ).

Se även

Anteckningar

  1. ↑ 1 2 E-post - Ordbok - SeoPult.Ru .
  2. ↑ E-post förlorat bindestreck
  3. ↑ ComputerPress magazine 6'2001 - Internetpost
  4. ↑ 1 2 Fråga nr 220471 Gramota.ru
  5. ↑ Sök efter ett svar . new.gramota.ru. Tillträdesdatum: 14 mars 2019.
  6. ↑ Fråga nr 275417 Gramota.ru
  7. ↑ Sök efter ett ord: sök efter mönstret "*m?ile"
  8. ↑ Ordbokssökning - Ordkontroll: * maila Gramota.ru
  9. ↑ MuttWiki: MailConcept (nedlänk) . Hämtad 5 september 2009. Arkiverad från originalet 16 december 2008. 
  10. ↑ POP3 Connector för Exchange 2003 (SBS2003) i Exchange Admin  (nedlänk)
  11. ↑ RFC 5321: 4.5.5. Meddelanden med en noll omvänd sökväg
  12. ↑ Återuppringningsverifiering
  13. ↑ För närvarande har en uppsättning standarder utvecklats för att stödja nationella tecken i e-post ( RFC 6531 , RFC 6532 , RFC 6533 ), men inte all programvara stöder detta.
  14. ↑ Säkerhetslista - Skräppost i maj 2009 , enligt Kaspersky Lab, uppgick skräpposten i maj 2009 till 70-90 % av den totala e-postkorrespondensen.

Länkar

  • RFC 822  - Standard för ARPA Internet-textmeddelanden
  • RFC 2142  - Mailbox Names for Common Services, Rolls and Functions
  • RFC 2368  - Mailto URL-schemat
  • RFC 5322  - Internetmeddelandeformat
  • RFC 2045  - Format för Internet Message Bodies
  Gå till Wikidata-objektet  Ordböcker och uppslagsverk
 Datorförmedlad kommunikation
Asynkron konferens
Synkron konferens
Publikationer