E-mail

Elektronisk post ( engelsk  e-mail, e-mail [ i ˈm e ɪl ] , fra engelsk  elektronisk post ) er en teknologi og tjeneste til at sende og modtage elektroniske beskeder (kaldet "breve", "e-mails" eller "beskeder") mellem brugere af et computernetværk (inklusive internettet ) [1] .

E-mail, med hensyn til sammensætningen af ​​elementer og princippet om drift, gentager praktisk talt systemet med almindelig (papir) post , låner både vilkår (post, brev, kuvert, vedhæftet fil, boks, levering og andre) og karakteristiske træk - brugervenlighed, forsinkelser i meddelelsestransmission, tilstrækkelig pålidelighed og på samme tid ingen garanti for levering.

Fordelene ved e-mail er: adresser i formen bruger_navn@ domænenavn (for eksempel [email protected]) er let opfattede og huskede af en person; evnen til at overføre både almindelig tekst og formaterede, såvel som vilkårlige filer ( tekstdokumenter , mediefiler, programmer, arkiver osv. [1] ); uafhængighed af servere (i det almindelige tilfælde henvender de sig direkte til hinanden); tilstrækkelig høj pålidelighed af meddelelseslevering; brugervenlighed for en person og programmer, høj hastighed for meddelelsesoverførsel.

Ulemper ved e-mail: tilstedeværelsen af ​​et sådant fænomen som spam (massereklamer og virale forsendelser ); mulige forsinkelser i levering af beskeder (op til flere dage); grænser for størrelsen af ​​én besked og på den samlede størrelse af beskeder i postkassen (personligt for brugere).

I øjeblikket kan enhver nybegynder bruger starte sin egen gratis e-mail-boks, bare registrer dig på en af ​​internetportalerne.

Navne

Hvis der i Europa, Amerika og andre regioner kun bruges to muligheder, når du skriver - "e-mail" eller "e-mail" (desuden varierer anbefalingerne om, hvorvidt man skal skrive en bindestreg eller ej: for eksempel siden marts 2011, en af ​​de stilistiske retningslinjer er AP Stylebook - anbefaler at skrive forkortelsen for "elektronisk post" som "e-mail" og ikke "e-mail" [2] ), så er der betydelig variation på russisk. Oftest Kyrilliske tekster bruger også "e-mail", det vil sige at skrive på latin uden translitteration (visuel opfattelse af andre former for skrivning er værre ). Men du kan finde andre stavemåder:

Informationsbureauet for Gramota.ru indikerede først, at det blev anbefalet at skrive e-mail (latin) eller e- mail (kyrillisk) [4] , og derefter begyndte det kun at anbefale den kyrilliske stavning af e- mail , som f.eks. i det russiske videnskabsakademis russiske retskrivningsordbog [5] [6] .

Ordbøgerne registrerede fire varianter af stavemåder: e-mail , mail [7] e-mail , e-mail [8] .

De facto i officielle russisksprogede dokumenter[ hvad? ] :

Historie

Fremkomsten af ​​e-mail kan spores tilbage til 1965 , da Massachusetts Institute of Technology (MIT) medarbejdere Noel Morris og Tom Van Vleck skrev mailprogrammet til CTSS (Compatible Time-Sharing System) styresystemet installeret på en IBM 7090/ 7094 computer.

Den generelle udvikling af e-mail har været gennem udviklingen af ​​lokal brugerinteraktion på flerbrugersystemer. Brugere kunne ved hjælp af mailprogrammet (eller dets tilsvarende) videresende beskeder til hinanden inden for samme mainframe (stor computer). Næste trin var at kunne videresende beskeden til en bruger på en anden maskine ved at angive maskinnavn og brugernavn på maskinen. Adressen kunne skrives som foo!joe(bruger joe på computer foo). Det tredje trin i udviklingen af ​​e-mail skete med fremkomsten af ​​​​transmission af breve gennem en tredje computer. I tilfælde af brug af UUCP inkluderede brugerens adresse en rute til brugeren gennem flere mellemliggende maskiner (f.eks. gate1!gate2!foo!joe et brev for joe gennem maskinporten1, port2 til maskinen foo). Ulempen ved denne adressering var, at afsenderen (eller administratoren af ​​den maskine, som afsenderen kørte på) skulle kende den nøjagtige sti til destinationsmaskinen.

Efter fremkomsten af ​​det distribuerede globale navnesystem DNS , begyndte domænenavne at blive brugt til at angive adressen - [email protected] - brugeren på example.com maskinen. Samtidig blev begrebet "på en maskine" gentænket: Dedikerede servere begyndte at blive brugt til mail, som almindelige brugere (kun administratorer) ikke havde adgang til, og brugere arbejdede på deres maskiner, mens mail ikke havde adgang til. kommer til brugernes arbejdsstationer, men til postkasser, en server hvorfra brugerne hentede deres mail ved hjælp af forskellige netværksprotokoller (blandt de mest almindelige i øjeblikket er POP3 , IMAP , MAPI , webgrænseflader). Samtidig med fremkomsten af ​​DNS blev et system til at reservere postleveringsruter opfundet, og domænenavnet i postadressen ophørte med at være navnet på en bestemt computer og blev blot et fragment af postadressen. Mange servere kan være ansvarlige for at vedligeholde et domæne (måske fysisk placeret på forskellige kontinenter og i forskellige organisationer), og brugere fra det samme domæne har muligvis intet til fælles med hinanden (dette gælder især for brugere af gratis e-mail-servere).

Derudover var der andre e-mail-systemer (hvoraf nogle stadig eksisterer), såsom: Netmail på Fidonet -netværket , X.400 på X.25 - netværket[ angiv ] . Adgang til dem fra internettet og omvendt sker via en mail-gateway . For at dirigere post i X.25-netværk giver DNS en speciel ressourcepost med det passende navn X25 (kode 19).

Kronologi

MxA klassifikation

Følgende komponenter skelnes i terminologien for e-mail:

I tilfælde af brug af dedikerede servere til lagring af brugermail, kan al interaktion mellem brugeren og serveren ske ved brug af protokoller, der ikke passer ind i dette skema.

Mailservere fungerer normalt som MTA og MDA. Nogle mailservere (programmer) udfører funktionen af ​​både MTA og MDA, nogle involverer adskillelse i to uafhængige servere: MTA-server og MDA-server (i dette tilfælde, hvis der bruges forskellige protokoller til at få adgang til postkassen, for eksempel POP3 og IMAP , så MDA kan til gengæld implementeres enten som en enkelt applikation eller som et sæt applikationer, som hver især er ansvarlige for en separat protokol).

Moderne arkitektur (SMTP)

Verdens mest accepterede e- mailudvekslingsprotokol er SMTP ( simpel mailoverførselsprotokol  ). I en almindelig implementering bruger den DNS til at bestemme regler for videresendelse af mail (selvom i private systemer som Microsoft Exchange kan SMTP handle baseret på oplysninger fra andre kilder).  

Forskellige domæner har deres egne uafhængige mailsystemer. Hvert maildomæne kan have flere brugere. (Men det kan faktisk være, at én organisation eller person ejer mange domæner, der betjenes (fysisk) af ét mailsystem). Mail overføres mellem noder ved hjælp af mailoverførselsprogrammer ( engelsk  mailoverførselsagent , MTA ; som f.eks. sendmail , exim 4, postfix , Microsoft Exchange Server , Lotus Domino osv.). Systemernes adfærd, når de kommunikerer med hinanden, er strengt standardiseret, til dette bruges SMTP-protokollen (og overholdelse af denne standard, sammen med universel DNS-understøttelse af alle deltagere, er grundlaget for evnen til at kommunikere "alle til alle" uden tidligere aftaler). Interaktionen mellem mailsystemet og brugerne er generelt ikke reguleret på nogen måde og kan være vilkårlig, selvom der er både åbne og lukkede (bundet til software fra specifikke producenter) protokoller til interaktion mellem brugere og mailsystemet. Det program, der kører i mailsystemet og betjener brugere, kaldes MDA ( mail delivery agent ) .  I nogle mailsystemer kan MDA og MTA være kombineret til ét program, i andre systemer kan de være adskilt som separate programmer eller endda køre på forskellige servere. Det program, som brugeren tilgår med, kaldes MUA ( mail user agent ) . Hvis webgrænsefladen bruges til at arbejde med mail, udføres dens funktion af webgrænsefladeapplikationen, der kører på serveren.  

Inden for et givet mailsystem (normalt inden for samme organisation) kan der være mange mailservere, der udfører både videresendelse af mail inden for organisationen og andre email-relaterede opgaver: spamfiltrering, antivirusscanning af vedhæftede filer, autosvar, indgående/udgående mail arkivering, der giver adgang til brugere på forskellige måder (fra POP3 til ActiveSync ). Interaktion mellem servere inden for det samme mailsystem kan enten være underlagt generelle regler (ved brug af DNS og mail routing regler ved brug af SMTP protokollen), eller følge virksomhedens egne regler (den anvendte software).

Relæer

DNS giver dig mulighed for at angive enhver internetvært som modtagerserver ( MX-post ), ikke nødvendigvis en del af modtagerdomænets domænezone . Dette kan bruges til at konfigurere videresendelse (videresendelse) af mail gennem tredje servere. En tredjepartsserver (f.eks. mere pålidelig end brugerens servere) accepterer mail for brugerens domæne og videresender den til brugerens mailservere så hurtigt som muligt. Historisk set var der ingen kontrol over "til hvem der skulle videresendes" mail (eller det blev ikke tillagt behørig betydning), og servere uden en sådan kontrol videresendte mail til nogen domæner. Sådanne servere kaldes åbne relæer (i øjeblikket vises nye åbne relæer primært på grund af konfigurationsfejl).

For deres brugere er mailsystemservere relæer (brugere sender ikke mail til modtagerens mailsystemservere, men til "deres" mailserver, som sender breve videre). I mange udbydernetværk er muligheden for at sende breve via SMTP -protokol uden for netværket lukket (på grund af brugen af ​​denne funktion af trojanske heste , vira ). I dette tilfælde leverer udbyderen sin egen SMTP-server, hvorigennem al mail sendes uden for netværket. I dette tilfælde anses et åbent relæ for at være et sådant relæ, der ikke kontrollerer, om brugeren er "venner" (kontrollen kan udføres både på baggrund af netværksadressen på brugerens computer, og på baggrund af brugeridentifikation med adgangskode/certifikat).

Mail routing

Mailserveren, der har modtaget mail (fra en lokal kilde eller fra en anden server), kontrollerer, om der er specifikke regler for behandling af mail (regler kan være baseret på et brugernavn, på et domæne i en adresse, på indholdet af et brev , osv.), hvis der ikke findes specifikke regler, tjekker den, om maildomænet er lokalt for serveren (det vil sige, om serveren er den endelige modtager af beskeden). Hvis det er tilfældet, accepteres brevet til behandling. Hvis mail-domænet ikke er lokalt, så anvendes mail-routing-proceduren (som er grundlaget for overførsel af breve mellem forskellige servere på internettet).

Routing bruger kun domænedelen af ​​destinationsadressen (det vil sige delen efter @-symbolet). For modtagerdomænet slås alle MX-poster op. De er sorteret i faldende prioritetsrækkefølge. Hvis mailserveradressen matcher en af ​​de værter, der er angivet i MX-posterne, kasseres alle poster med en lavere prioritet end værtens prioritet i MX-posten (samt MX-posten for selve værten), og leveringen sker til den/de først reagerende vært(er) prøves i faldende prioritetsrækkefølge). Dette gøres i tilfælde af, at afsenderens mailserver er et relæ fra modtagerens mailserver. Hvis MX-posten for domænet ikke findes, forsøges der at levere mail ved hjælp af A-posten, der svarer til domænet. Hvis der ikke er nogen registrering om domænet, genereres en besked om umuligheden af ​​levering (bounce-meddelelse). Denne meddelelse genereres med MAIL FROM:<>( RFC 5321 ), feltet "Til" angiver afsenderen af ​​den originale meddelelse, og feltet "Fra" angiver en e-mail i formen MAILER-DAEMON@имя сервера. Servernavnet er navnet på den internetvært, der genererede meddelelsen. MAIL FROM:<>giver dig mulighed for at beskytte mailservere mod endeløs cirkulation af fejlmeddelelser mellem servere - hvis serveren opdager, at den ikke kan levere et brev med en tom returadresse, så ødelægger den det. En besked om umuligheden af ​​levering kan også genereres efter et stykke tid. Dette opstår, hvis det detekterede problem bestemmes til at være forbigående, men timeout for meddelelseskøen udløber ( RFC 5321 , afsnit 4.5.4.1. Sendestrategi).

Hvis netværket har forskellige DNS-servere (f.eks. eksterne - på internettet og lokale - inden for egne grænser), så er det muligt, at de "interne" DNS-servere peger på en server, der ikke er tilgængelig på internettet, som den højeste prioritetsmodtager, hvor mail omdirigeres fra relæ angivet som destinationsvært for internettet. Denne opdeling gør det muligt at dirigere post i henhold til almindelige regler mellem servere, der ikke har adgang til internettet.

E-mail-modtagelsesprotokoller

Når mailen når destinationsserveren, gemmer den den modtagne mail midlertidigt eller permanent. Der er to forskellige modeller til at arbejde med post: konceptet med en postbutik ( boks ) og en postterminal .

POP3

I begrebet postlagring gemmes post på serveren midlertidigt i et begrænset antal (svarende til en postkasse til papirpost), og brugeren får periodisk adgang til postkassen og "henter" breve (det vil sige, at mailklienten downloader en kopi af brevet til sig selv og sletter originalen fra postkassen). Baseret på dette koncept fungerer POP3 -protokollen .

IMAP

Konceptet med en postterminal indebærer, at al korrespondance forbundet med en postkasse (inklusive kopier af sendte breve) gemmes på serveren, og brugeren tilgår depotet (nogle gange traditionelt også kaldet en "postkasse") for at se korrespondance (både ny og arkiv) og skrive nye breve (inklusive svar på andre breve). IMAP-protokollen og de fleste webgrænseflader til gratis e-mail-tjenester fungerer efter dette princip . Sådan lagring af mailkorrespondance kræver væsentligt mere kapacitet fra mailservere, som følge heraf er der i mange tilfælde en adskillelse mellem mailservere, der videresender mail- og maillagerservere.

Forskelle

Baseret på hvordan protokollerne fungerer, kan de opdeles efter to hovedkriterier:

Under visse betingelser kan maillagerserveren konfigureres til at opføre sig på samme måde som klienten: en sådan server får adgang til mailserveren ved hjælp af POP3-protokollen og tager post for sig selv. Sådanne løsninger bruges normalt i små organisationer, der ikke har infrastrukturen til at implementere fuldgyldige mailservere; i dette tilfælde bruges en lokal server til at gemme mail og udbyderens mailserver, der leverer tjenesten til at modtage mail via POP3 (f.eks. ved hjælp af fetchmail ). Den største ulempe ved en sådan løsning er forsinkelsen i leveringen (da softwaren, der indsamler mail, tilgår serverne med en vis forsinkelse) - for eksempel tillader POP3-stikket fra Exchange 2003 Server som en del af Windows SBS ikke at indstille et interval på mindre end 15 minutter gennem konfigurationsgrænsefladen [10] , da overdreven kontrolfrekvens kan forårsage problemer med belastningen på mailserveren. Nogle mailservere har funktioner til at beskytte mod denne adfærd.

Bogstavets struktur

Når den transmitteres ved hjælp af SMTP-protokollen, består en e-mail af følgende dele.

SMTP-konvolutdata

SMTP-konvolutdataene indeholder parametre, der er indstillet af kommandoerne af samme navn:

E-mail-overskrifter

E-mail-headere er beskrevet af RFC- standarder :

Overskrifter er adskilt fra selve bogstavet med en tom linje. Overskrifter bruges til at logge passagen af ​​et brev og servicebemærkninger (nogle gange kaldet kludges ). I Microsoft Outlook kaldes disse overskrifter "Internetoverskrifter". Overskrifterne angiver normalt: de mailservere, som brevet passerede igennem (hver mailserver tilføjer information om, hvem den modtog dette brev fra), oplysninger om, hvorvidt dette brev ligner spam, oplysninger om antivirusscanning, brevets hastende niveau ( måske skifte mailserver). Også i overskriften er normalt skrevet det program, hvormed brevet blev oprettet. Da headerne er proprietære informationer, skjuler mailklienter dem oftest for brugeren under normal læsning af beskeder, men giver også mulighed for at se disse headere, hvis der er behov for en mere detaljeret analyse af beskeden. Hvis en e-mail fra SMTP-format konverteres til et andet format (for eksempel konverteres e-mails til MAPI i Microsoft Exchange 2007), så gemmes headerne separat for at aktivere diagnostik.

Overskrifter tilføjes normalt nedefra og op (det vil sige, hver gang en overskrift skal tilføjes til en besked, tilføjes den på den første linje før alle de foregående).

Ud over serviceoplysninger gemmer e-mail-headere også oplysninger, der vises til brugeren, dette er normalt afsenderen af ​​brevet, modtageren, emnet og afsendelsesdatoen.

Meddelelsesoverskrifter kan kun indeholde 7-bit tegn [13] . Hvis det er nødvendigt at bruge nationale tegn i nogle felter, er brugen af ​​kodninger påkrævet. Typisk er dette Base64 eller Quoted-Printable .

Fælles overskrifter
  • Return-Path:( RFC 821 , RFC 1123 ) - returadressen i tilfælde af fejl, når det er umuligt at levere brevet til destinationsadressen. Kan afvige fra MAIL FROMog overskrifter From:, Sender:eller Reply-To:, men matcher normalt MAIL FROM.
  • Received:( RFC 822 , RFC 1123 ) - data om passage af et brev gennem hver specifik mailserver (MTA). Når man passerer flere mailservere (den sædvanlige situation), tilføjes nye headers oven på de tidligere, til sidst vil overførselsloggen blive skrevet i omvendt rækkefølge (fra noden tættest på modtageren til længst).
  • MIME-Version:( RFC 1521 ) - Den MIME - version , som denne meddelelse blev oprettet med. Ofte er denne titel skabt før alle de andre, så det er normalt den allerførste (det vil sige den sidste på listen).
  • From:( RFC 822 , RFC 1123 , RFC 1036 ) - afsenderens navn og adresse (det er i denne overskrift, at tekstfeltet med afsenderens navn vises). Kan ikke matche return-patheller endda matche SMTP-headeren MAIL FROM:.
  • Sender:( RFC 822 , RFC 1123 ) - afsenderen af ​​brevet. Tilføjet for at kunne angive, at et brev på vegne af nogen (fra) er sendt af en anden person (f.eks. en sekretær på vegne af chefen). Nogle mailklienter viser beskeden i nærværelse af afsender og fra som "besked fra 'afsender' på vegne af 'fra'". Afsender er en informationsheader (og kan også være forskellig fra SMTP-headeren MAIL FROM).
  • To:( RFC 822 , RFC 1123 ) - Modtagerens navn og adresse. Det kan være indeholdt flere gange (hvis brevet er adresseret til flere modtagere). Ud fra dette felt dannes indholdet af SMTP-feltet RCPT TO.
  • Cc:( RFC 822 , RFC 1123 ) - (fra den engelske  carbonkopi ) indeholder navne og adresser på de sekundære modtagere af det brev, som kopien sendes til. Deltager i dannelsen af ​​SMTP-feltet RCPT TOsamt "Til"-feltet.
  • Bcc:( RFC 822 , RFC 1123 ) - (fra engelsk  blind carbon copy ) indeholder navne og adresser på modtagerne af brevet, hvis adresser ikke skal vises til andre modtagere. Deltager i dannelsen af ​​SMTP-feltet RCPT TO, ligesom felterne "Til" og "Cc", men er ikke til stede i den sendte besked.
  • Reply-To:( RFC 822 , RFC 1036 ) er det navn og den adresse, som svar på dette brev skal adresseres til. Hvis et brev for eksempel sendes af en robot, så vil Reply-Toadressen på den postkasse, der er klar til at modtage et svar på brevet, blive angivet som adressen.
  • Message-ID:( RFC 822 , RFC 1036 ) - en unik meddelelsesidentifikator . Består af adressen på den afsendende vært og et nummer (unik inden for værten). Den unikke talgenereringsalgoritme afhænger af serveren/klienten. Ser sådan ud [email protected]:. Sammen med andre identifikatorer bruges den til at søge efter passagen af ​​en specifik meddelelse gennem postsystemets logfiler (mailsystemer registrerer passagen af ​​et brev ved dens Message-ID) og til at pege på et brev fra andre bogstaver (bruges til at gruppere og bygge meddelelser kæder). Normalt oprettet af mail-klienten (MUA) på tidspunktet for skrivelsen.
  • In-Reply-To:( RFC 822 ) - peger på Message-ID, som dette brev er et svar på (ved hjælp af dette kan mailklienter nemt bygge en korrespondancekæde - hvert nyt svar indeholder Message-ID for den forrige besked).
  • Subject:( RFC 822 , RFC 1036 ) — emnet for e-mailen.
  • Date:( RFC 822 , RFC 1123 , RFC 1036 ) — den dato, hvor e-mailen blev sendt.
  • Content-Type:( RFC 1049 , RFC 1123 , RFC 1521 , RFC 1766 ) — meddelelsesindholdstype ( HTML , RTF, almindelig tekst) og kodning, hvori meddelelsen blev oprettet (se nedenfor om kodninger).
  • Return-Receipt-To:( RFC 2076 ) - Den e-mail, hvor modtagerens mailserver skal sende leveringsbeskeden. RFC 2076 er nævnt i afsnittet "Ikke internetstandard" og understøttes derfor muligvis ikke af servere.
  • Disposition-Notification-To:( RFC 3798 ) - e-mail, hvor modtagerens mailklient skal sende en leveringsbesked, hvis brugeren tillader det (gennem indstillinger osv.).

Ud over de standard, kan mail-klienter, servere og mail-processorer tilføje deres egne headere, der starter med "X-" (for eksempel: X-Mailer, X-MyServer-Note-OKeller X-Spamassasin-Level).

Brødteksten i brevet

Brødteksten er adskilt fra overskriften med en tom linje. I ikke-smtp-standarder afhænger brevets format af systemstandarden (f.eks. MAPI ), men før bogstavet "forlader" det MAPI-kompatible system (f.eks. inden det sendes over internettet), er det normalt konverteret til SMTP-kompatibel form (ellers ville beskeddirigeringen være umulig, fordi standarden for afsendelse af mail på internettet er SMTP).

Kun printbare tegn er tilladt i meddelelsens brødtekst. Derfor, med henblik på at overføre binær information (billeder, eksekverbare filer osv.), bruges kodninger, der bringer data til en 7-bit form - Base64 eller UUE . Derudover var begrænsningen i begyndelsen af ​​eksistensen af ​​e-mail mere alvorlig - nogle mailsystemer understøttede kun 7-bit beskeder. For at kunne arbejde med sådanne systemer kan almindelig tekst, i nærværelse af nationale tegn, også kodes i 7-bit form. Base64 eller Quoted-Printable bruges til dette . Men postsystemer, der kun kan håndtere 7-bit beskeder, eksisterer næppe nu.

Lædebogstaver

På grund af tilstedeværelsen af ​​en unik identifikator i brevet, samt det faktum, at langt de fleste mailklienter, når de besvarer et brev, kopierer dennes identifikator i feltet In-Reply-To("som svar på"), bliver det muligt at pålideligt gruppebeskeder langs en kæde ( eng.  tråd ). Dette implementeres forskelligt i forskellige e-mail-klienter. For eksempel giver Microsoft Outlook dig mulighed for at finde alle relaterede e-mails, og Gmail-webgrænsefladen grupperer meddelelser baseret på tråddata i et enkelt objekt. Nogle e-mail-klienter (såsom mutt ) giver dig mulighed for at strukturere kæder (normalt dannet i mailinglister, når der er mange abonnenter i en samtale) i form af et træ (spørgsmålet genererede flere svar, som hver blev kommenteret - dette dannede flere grene af træet). Sådanne klienter ved normalt også, hvordan man tvangsklipper trådene, når emnet for meddelelsen ændres (forudsat at ændringen i emnet for meddelelsen betyder en ny diskussion, selvom det måske er forårsaget af en tidligere samtale).

Email kryptering

To standarder er i vid udstrækning brugt til mailkryptering: S/MIME (ved hjælp af en offentlig nøgleinfrastruktur) og OpenPGP (ved brug af certifikater med et tillidsskema, der grupperer sig omkring brugeren).

Tidligere var der også MOSS- og PEM- standarder , men på grund af inkompatibilitet med hinanden og ulejligheden ved brug slog de ikke rod.

S/MIME- og OpenPGP-standarderne giver tre typer beskyttelse: mutabilitet, uigenkaldelig signatur og fortrolighed (kryptering). Derudover tillader S/MIME version 3 brugen af ​​sikker bekræftelse (hvor en kvittering for modtagelse af et brev kun kan genereres med succes, hvis brevet er nået frem til modtageren intakt).

Begge standarder bruger symmetriske kryptografiske algoritmer til at kryptere meddelelsesteksten, og den symmetriske nøgle krypteres ved hjælp af modtagerens offentlige nøgle. Hvis brevet er adresseret til en gruppe mennesker, krypteres den symmetriske nøgle på skift af hver af modtagernes offentlige nøgler (og nogle gange, for nemheds skyld, af afsenderens offentlige nøgle, så han kan læse brevet sendt af ham) .

Kommerciel brug

I øjeblikket er der følgende modeller for kommerciel brug af postsystemer:

  • Hjemme- og virksomhedsmailsystemer - opererer på ejerens eget eller lejede udstyr af postsystemet (normalt er han også ejer af det domæne, hvor mailserveren opererer).
  • Tjenesten med at modtage/sende e-mail leveres af en tredjepart. Organisationen (personen) ejer domænet og opbevarer selvstændigt korrespondancearkivet.
  • Tjenester til modtagelse/afsendelse og opbevaring af post udføres af en tredjepartsorganisation på egne faciliteter. Kunden får adgang til entreprenørens system til udsendelse af breve og til adgang til brevarkivet. Maildomænet ejes af kunden.
  • Modtagelse, afsendelse, opbevaring af breve udføres af bobestyreren, postdomænet tilhører bobestyreren. De fleste af disse tjenester er gratis og fungerer ved at vise annoncer til brugeren eller er en gratis tilføjelse til andre tjenester fra udøveren (for flere detaljer, se: Gratis posttjenester ).

Postlister

Mailsystemet giver dig mulighed for at organisere komplekse systemer baseret på videresendelse af mail fra én til mange abonnenter, disse er:

  • Postlister - et brev fra samme adresse med det samme (eller ændres i henhold til skabelonen) indhold, sendt til abonnenter på mailinglisten . Teknisk set kan det organiseres som afsendelse af flere e-mails (bruges til skabelon-e-mails) eller afsendelse af e-mails med flere modtagere (i TIL, CC, BCC-felter). Til at administrere store mailinglister (mere end 10-50 abonnenter) bruges specialiserede programmer (for eksempel postmand ). En korrekt organiseret postliste bør kontrollere returnering af breve (beskeder om umuligheden af ​​at levere et brev) med udelukkelse af utilgængelige modtagere fra postlisten, give abonnenter mulighed for at afmelde sig fra postlister. Uønskede forsendelser kaldes spam og komplicerer funktionen af ​​postsystemer betydeligt.
  • Korrespondancegrupper er en specialiseret type postliste, hvor et brev til gruppeadressen (en almindelig postadresse behandlet af et specialiseret program) sendes til alle medlemmer af gruppen. Det er en analog af nyhedskonferencer, ekkokonferencer. En korrekt konfigureret postliste bør kontrollere cyklusser (to postrobotter, der abonnerer på hinanden, er i stand til at skabe en endeløs løkke af afsendelse af breve), begrænse listen over postlistedeltagere, der har ret til at sende en besked, og opfylde andre krav til postliste .

Postlisteadministratorer bruges til at administrere postlister . Ud over at vedligeholde en adresseliste og sende en given besked, sørger de for filtrering af breve, mulighed for forudgående moderering af breve, før de placeres på mailinglisten, vedligeholde arkiver, administrere tilmelding/afmelding, postsammendrag (kort indhold) i stedet for hele postvolumen.

Eksempler på programmer til håndtering af forsendelser:

Spam

Spam er en slags forsendelse med det formål at reklamere (ofte uopfordret) for et bestemt produkt eller en bestemt tjeneste, en analog af papirreklamer, der distribueres gratis i postkasserne i boligbyggerier.

Efterhånden som e-mail voksede i popularitet, begyndte den (sammen med usenet-nyhedsgrupper ) at blive brugt til at udsende uopfordrede salgsfremmende meddelelser, svarende til hvordan brochurer smides ind i almindelige postkasser. Men i modsætning til de betydelige omkostninger ved en papirmailingliste, koster det stort set ingenting for afsenderen at sende et betydeligt beløb (millioner og milliarder) af meddelelser. Dette førte til en uforholdsmæssig stigning i antallet og størrelsen af ​​reklameforsendelser (ifølge nogle data [14] udgør spam i øjeblikket 70-90 % af alle postbeskeder, dvs. den oversteg postens nyttelast med 2-10 gange) .

For at sende spam bruges alle mulige tekniske tricks i øjeblikket aktivt: åbne relæer , remailere , proxyservere, gratis e-mail-servere (tillader automatisering af afsendelse af mail), botnets , falske beskeder om umuligheden af ​​levering.

Med stramningen af ​​reklameforbuddet blev beskederne opdelt i legitime forsendelser (som brugeren normalt abonnerer på, og som han til enhver tid kan afslå) og illegitime (kaldes faktisk spam). For at bekæmpe spam er der udviklet forskellige mekanismer ( sortlister over afsendere, grå lister , der kræver, at mailserveren sendes igen, kontekstfiltre). En af konsekvenserne af introduktionen af ​​anti-spam-værktøjer var muligheden for en " falsk positiv " beslutning vedrørende spam, det vil sige, at en del af breve, der ikke er spam, begyndte at blive markeret som spam. I tilfælde af en aggressiv anti-spam-politik (ødelæggelse af meddelelser, der ser ud til at være spam automatisk uden at underrette afsenderen/modtageren), fører dette til problemer med e-mailflowet, der er svært at opdage.

Lovgivningsmæssig regulering i Rusland

Føderal lov nr. 152-FZ "Om personlige data" .

De mest populære e-mail-tjenester

De mest populære e-mail-tjenester leveres af it-virksomheder sammen med andre webprodukter: søgemaskiner, cloud-lagring osv. Russisksprogede e-mail-tjenester er udviklet af Google ( Gmail ), Yandex ( Yandex.Mail ), Mail.ru ( Mail.ru ), Microsoft ( Hotmail og Outlook ).

Se også

Noter

  1. ↑ 1 2 E-mail - Ordbog - SeoPult.Ru .
  2. ↑ E- mail mistet bindestreg
  3. ↑ ComputerPress magazine 6'2001 - Internetmail
  4. ↑ 1 2 Spørgsmål nr. 220471 Gramota.ru
  5. ↑ Søg efter et svar . new.gramota.ru. Dato for adgang: 14. marts 2019.
  6. ↑ Spørgsmål nr. 275417 Gramota.ru
  7. ↑ Søg efter et ord: søg efter mønsteret "*m?ile"
  8. ↑ Ordbogssøgning - Ordkontrol: * mail Gramota.ru
  9. ↑ MuttWiki: MailConcept (downlink) . Hentet 5. september 2009. Arkiveret fra originalen 16. december 2008. 
  10. ↑ POP3 Connector til Exchange 2003 (SBS2003) i Exchange Admin  (downlink)
  11. ↑ RFC 5321: 4.5.5. Meddelelser med en Null Reverse-Path
  12. ↑ Tilbagekaldsbekræftelse
  13. ↑ I øjeblikket er der udviklet et sæt standarder til at understøtte nationale tegn i e-mail ( RFC 6531 , RFC 6532 , RFC 6533 ), men ikke al software understøtter dette.
  14. ↑ Securelist - Spam i maj 2009 ifølge Kaspersky Lab udgjorde spam i maj 2009 70-90 % af den samlede mailkorrespondance.

Links

  • RFC 822  - Standard for ARPA internet tekstbeskeder
  • RFC 2142  - Postkassenavne til almindelige tjenester, roller og funktioner
  • RFC 2368  - Mailto URL-skemaet
  • RFC 5322  - Internetmeddelelsesformat
  • RFC 2045  - Format for Internet Message Bodies
  Gå til Wikidata-elementet  Ordbøger og encyklopædier
 Computer-medieret kommunikation
Asynkron konference
Synkron konference
Publikationer