Hvordan fungerer e-mail?

Først bruger du en mailbrugeragent eller MUA til at læse og sende e-mail fra din enhed (såsom gmail eller mail-appen på Apple-enheder). Disse programmer er kun aktive, når du bruger dem.

Generelt kommunikerer de med en mailoverførselsagent eller MTA (også kendt som en mailserver, MX-vært og e-mailveksler), der tjener til at modtage og gemme dine e-mails.

E-mails gemmes eksternt, indtil du åbner din MUA for at kontrollere din e-mail. E-mails leveres af mail leveringsagenter (MDA), som normalt er pakket med MTA.

E-mail blev tidligere sendt til en mailserver ved hjælp af SMTP eller Simple Mail Transfer Protocol. SMTP er en kommunikationsprotokol til e-mail.

Selv nu, mens mange proprietære systemer som Microsoft Exchange og webmail-programmer som Gmail bruger deres egne protokoller internt, bruger de SMTP til at overføre meddelelser uden for deres systemer (for eksempel hvis en Gmail-bruger vil sende en e-mail til en Outlook-klient).

Mail ville derefter blive downloadet fra serveren ved hjælp af Post Office Protocol (POP3). POP3 er en applikationslagsprotokol, der giver adgang via et internetprotokol (IP) -netværk for et brugerapplikation til at kontakte en postkasse på en mailserver. Det kan oprette forbindelse, hente meddelelser, gemme dem på klientens computer og slette eller gemme dem på serveren.

Det var designet til at være i stand til at administrere midlertidige internetforbindelser, såsom opkald (så det bare forbinder og henter e-mail, når der er forbindelse, og giver dig mulighed for at se beskederne, når du var offline). Dette var mere populært, når opkaldsadgang var mere udbredt.

Nu har IMAP, Internet Message Access Protocol, for det meste erstattet POP3. IMAP kan tillade flere klienter at administrere den samme postkasse (så du kan læse din e-mail fra din desktop, laptop og telefon osv., Og alle dine beskeder vil være der, organiseret på samme måde).

Til sidst erstattede webmail begge. Webmail giver dig mulighed for at logge ind på et websted og modtage meddelelser fra hvor som helst eller hvilken som helst enhed (yay!), Men du skal være forbundet til internettet, mens du bruger den. Hvis webstedet (som gmail) er din MUA, behøver du ikke kende SMTP- eller IMAP-serverindstillinger.

Hvordan er e-mail sikret?

Desværre var sikkerhed ikke rigtig indbygget i mailprotokoller fra starten (som de fleste begyndende internetprotokoller). Servere forventede bare at tage enhver besked fra nogen og sende den videre til enhver anden server, der kunne hjælpe med at dirigere meddelelsen til dens endelige destination (modtageren i feltet til:).

Ikke overraskende blev dette et problem, da Internettet udvidede fra nogle få regeringer og forskningsgrupper til noget, som de fleste af verden bruger til at gøre stort set alt. Snart blev spam og phishing-e-mails (og forbliver) et kæmpe problem for alle.

Som svar har vi samlet forsøgt at implementere flere foranstaltninger, der forhindrer folk i at læse andres meddelelser (kryptering) og validere, at meddelelser faktisk kom fra den påståede afsender (godkendelse).  

De fleste steder bruger TLS (transportlagsikkerhed, erstatning for SSL, sikker sockets-lag), en kryptografisk protokol, der giver kryptering under transit. Det giver beskyttelse, når meddelelsen transmitteres, men ikke når dataene er i ro (f.eks. Når de gemmes på din computer).

Dette sikrer, at en besked ikke ændres eller snokes på, mens den rejser fra MTA til MTA. Dette bekræfter dog ikke, at meddelelsen ikke blev ændret under rejsen.

For eksempel, hvis e-mailen går gennem flere mailservere, før den når sin endelige destination, vil TLS sikre, at den er krypteret mellem serverne, men hver server kan ændre meddelelsesindholdet. For at løse dette har vi oprettet SPF, DKIM og DMARC.

SPF (Sender Policy Framework)

SPF tillader ejeren af ​​et domæne (som google.com) at indstille en TXT-post i sin DNS, der angiver, hvilke servere der har tilladelse til at sende mail fra dette domæne (for instruktioner om, hvordan man gør dette for en række hostingudbydere, se dette websted).

Hvordan virker det?

Denne post viser de enheder (typisk efter IP), der er tilladt, og kan ende i en af ​​følgende muligheder:

-all = Hvis kontrollen mislykkes (kilden til e-mailen er ikke en af ​​de anførte enheder) er resultatet en HardFail. De fleste mailsystemer markerer disse meddelelser som spam.

? all = = Hvis kontrollen mislykkes (kilden til e-mailen er ikke en af ​​de anførte enheder), er resultatet neutralt. Dette bruges typisk til testning, ikke produktionsdomæner.

~ all = Hvis kontrollen mislykkes (kilden til e-mailen er ikke en af ​​de anførte enheder), er resultatet en SoftFail. Dette betyder, at denne besked er mistænksom, men ikke nødvendigvis en kendt dårlig. Nogle mailsystemer markerer disse meddelelser som spam, men de fleste gør det ikke.

SPF-headere kan være nyttige for serverne selv, da de behandler meddelelser. For eksempel, hvis en server er ved kanten af ​​et netværk, ved den, at meddelelser, den modtager, skal komme fra servere i afsenderens SPF-post. Dette hjælper servere med at slippe af med spam hurtigere. Selvom dette lyder godt, er der desværre et par store problemer med SPF.

  1. SPF fortæller ikke en mailserver, hvad de skal gøre med meddelelsen - hvilket betyder, at en meddelelse kan mislykkes med en SPF-kontrol og stadig leveres.
  2. En SPF-post ser ikke på den 'fra' adresse, som brugeren ser, den ser på 'returstien'. Dette svarer stort set til den returadresse, du skriver på et brev. Det fortæller mailservere, der håndterer brevet, hvor de skal returnere meddelelsen (og den er gemt i e-mail-overskrifterne - i det væsentlige tekniske informationsservere bruger til at behandle e-mail).

    Det betyder, at jeg kan sætte hvad jeg vil i adressen fra: og det påvirker ikke SPF-kontrollen. Faktisk kan begge disse e-mail-adresser forfalskes relativt af en hacker. Da der ikke er nogen kryptering involveret, kan SPF-headere ikke være fuldt ud tillid til.

  3. SPF-optegnelser skal konstant holdes ajour, hvilket kan være vanskeligt i store, stadigt skiftende organisationer.
  4. Videresendelse bryder SPF. Dette skyldes, at hvis en e-mail fra f.eks. Google.com videresendes af [email protected], forbliver konvolutafsenderen uændret (fra-adressen står stadig google.com). Den modtagende mailserver mener, at den hævder at være fra google.com, men kommer fra bobsburgers.com, så den mislykkes med SPF-kontrollen (selvom mailen faktisk kommer fra google.com).

For mere læsning om SPF, se disse artikler. Du kan kontrollere, om et specifikt domæne har SPF- og DMARC-poster konfigureret her.

DKIM (DomainKeys Identified Mail)

DKIM svarer til SPF. Det bruger også TXT-poster i det afsendende domænes DNS, og det giver en vis godkendelse af selve meddelelsen. Det forsøger at give verifikation af, at beskeder ikke blev ændret under transit.

Hvordan virker det?

Det afsendende domæne genererer et offentligt / privat nøglepar og placerer den offentlige nøgle i domænet DNS TXT-post (hvis du ikke ved hvad et offentligt / privat nøglepar er, skal du tjekke denne artikel om kryptografi).

Derefter bruger domænet mailservere (på den ydre grænse - de servere, der sender e-mail uden for domænet (f.eks. Fra gmail.com til outlook.com)) den private nøgle til at generere en signatur af hele meddelelsestypen, inklusive overskrifter.

Generering af en signatur kræver normalt, at teksten hashes og krypteres (for flere detaljer om denne proces, se denne artikel).

Modtagende mailservere bruger den offentlige nøgle i DNS TXT-posten til at dekryptere signaturen og derefter hash beskeden og relevante overskrifter (eventuelle overskrifter, der blev oprettet, mens mailen var inde i afsenderens infrastruktur - for eksempel hvis flere gmail-servere behandlede e-mailen før den blev sendt eksternt til outlook.com).

Serveren kontrollerer derefter for at sikre, at de to hashes matcher. Hvis de gør det, er meddelelsen sandsynligvis uændret (medmindre nogen har kompromitteret afsenderens private nøgle) og legitimt fra den påståede afsender. Hvis hasherne ikke stemmer overens, er meddelelsen enten ikke fra den påståede afsender, eller den blev ændret af en anden server i transit eller begge dele.

DKIM gør et meget godt stykke arbejde på en meget specifik opgave - besvare spørgsmålet 'blev denne e-mail ændret under transport eller ikke fra den påståede afsender?'. Det er dog alt, hvad det gør. Det fortæller dig ikke, hvordan du skal håndtere e-mails, der fejler denne test, hvilken server der muligvis har ændret meddelelsen, eller hvilke ændringer der blev foretaget.  

DKIM bruges også af nogle internetudbydere eller internetudbydere til at bestemme omdømmet for dit domæne (sender du masser af spam? Har du lavt engagement? Hvor ofte hopper dine e-mails?).

For mere læsning om DKIM, se denne artikel. Du kan validere en DKIM-post her.

DMARC (domæne-baseret meddelelsesgodkendelse, rapportering og overensstemmelse)

DMARC er i det væsentlige instruktioner til mailservere om, hvordan man håndterer SPF- og DKIM-poster. Det udfører ikke nogen egne tests, men det fortæller mailservere, hvordan de skal håndtere de kontrol, som SPF og DKIM udfører.

Deltagende internetudbydere vil se på offentliggjorte DMARC-poster og bruge dem til at bestemme, hvordan man håndterer DKIM eller SPF mislykkes. Så for eksempel kan et almindeligt forfalsket brand muligvis udgive en DMARC-post, der siger, at hvis DKIM eller SPF fejler, skal du slippe beskeden.

Ofte sender internetudbydere også rapporter om dit domænes aktivitet til dig med kilde til e-mailen, og om den har bestået / mislykkedes DKIM / SPF. Dette betyder, at du får se, når folk spoofer (påstås at sende fra) dit domæne eller ændrer dine beskeder.

For at implementere DMARC skal du oprette en DMARC-post baseret på dine behov (fra overvågning af din e-mail-trafik for at finde ud af, hvad alle dine e-mail-kilder er, til at bede om handlinger, som at afvise e-mails, der fejler DKIM eller SPF). Du kan lære mere om at gøre det her og her.

For mere læsning om DMARC, se denne artikel. Du kan kontrollere, om et specifikt domæne har SPF- og DMARC-poster konfigureret her.

Pak ind

Ingen af ​​disse sikkerhedsforanstaltninger er perfekte, men sammen gør de et anstændigt job med at hjælpe os med at forbedre sikkerheden for e-mail-systemer over hele verden.

Jo flere organisationer, der vedtager disse foranstaltninger (enten ved hjælp af open source-implementeringer eller betaler for et produkt), jo bedre har alle det. Sikkerhed tilføjet efter at en protokol eller et produkt er udviklet er normalt dyrere, mindre effektiv og sværere at implementere end sikkerhed er indbygget i produktet.

Imidlertid var de fleste af de protokoller, som det nuværende internet er afhængig af, designet til det tidlige internet - for en lille gruppe entusiaster, forskere og regeringsfolk - ikke et verdensomspændende netværk, hvor vi driver bygninger, smarte enheder, offentlig transport, atomkraftværker (!), og så videre.

Da internet er fortsat med at ekspandere, er vi derfor nødt til at fortsætte med at tilpasse og udvikle nye måder at sikre de systemer, vi stoler på.