Hvad er der i en e-mail-header, og hvorfor skal du være ligeglad?

Har du nogensinde fået en spam- eller phishing-besked fra en e-mail-adresse, som du ikke genkendte? Måske tilbød nogen dig en gratis tur, bad dig om at sende dem bitcoin i bytte for personlige fotos eller bare sendte dig en uønsket marketing-e-mail?

Har du spekuleret på, hvor disse e-mails kom fra? Set en spammer spoof din e-mail-adresse og spekulerede på, hvordan de gjorde det?

E-mail-spoofing eller at få en e-mail til at se ud som om e-mailen kom fra en anden adresse end den gjorde (for eksempel en e-mail, der ser ud til at komme fra whitehouse.gov, men faktisk er fra en svindler) er bemærkelsesværdigt let.

Core-e-mail-protokoller har ikke nogen metode til godkendelse, hvilket betyder, at 'fra' -adressen stort set kun er en udfyldning.

Normalt når du får en e-mail, ser det sådan ud:

From: Name  Date: Tuesday, July 16, 2019 at 10:02 AM To: Me 

Nedenfor er emnet og beskeden.

Men hvordan ved du, hvor e-mailen virkelig kom fra? Er der ikke yderligere data, der kan analyseres?

Det vi leder efter er de fulde e-mail-overskrifter - det du ser ovenfor er bare en delvis overskrift. Disse data giver os nogle yderligere oplysninger om, hvor e-mailen kom fra, og hvordan den nåede din indbakke.

Hvis du vil se på dine egne e-mail-overskrifter, kan du få adgang til dem i Outlook og Gmail. De fleste mailprogrammer fungerer på samme måde, og en simpel Google-søgning fortæller dig, hvordan du får vist overskrifter på alternative posttjenester.

I denne artikel ser vi på et sæt rigtige overskrifter (selvom de er stærkt redigeret - jeg har ændret værtsnavne, tidsstempler og IP-adresser).

Vi læser overskrifterne fra top til bund, men vær opmærksom på, at hver nye server tilføjer deres header til toppen af ​​e-mail-kroppen. Det betyder, at vi læser hvert overskrift fra den endelige Message Transfer Agent (MTA) og arbejder ned til den første MTA for at acceptere beskeden.

Interne overførsler

Received: from REDACTED.outlook.com (IPv6 Address) by REDACTED.outlook.com with HTTPS via REDACTED.OUTLOOK.COM; Fri, 25 Oct 2019 20:16:39 +0000

Dette første hop viser en HTTPS-linje, hvilket betyder, at serveren ikke modtog beskeden via standard SMTP og i stedet oprettede beskeden fra input, den modtog i en webapplikation.

Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1358.20; Fri, 25 Oct 2019 20:16:38 +0000 Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.office365.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2385.20 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000 Authentication-Results: spf=softfail (sender IP is REDACTEDIP)smtp.mailfrom=gmail.com; privatedomain.com; dkim=pass (signature was verified)header.d=gmail.com;privatedomain.com; dmarc=pass action=noneheader.from=gmail.com;compauth=pass reason=100Received-SPF: SoftFail (REDACTED.outlook.com: domain of transitioning gmail.com discourages use of IPAddress as permitted sender)

Dette er de første to overskriftblokke er interne mailoverførsler. Du kan fortælle, at disse blev modtaget af Office365-servere (outlook.com) og routet internt til den korrekte modtager.

Du kan også fortælle, at meddelelsen sendes via krypteret SMTP. Du ved dette, fordi overskriften viser "med Microsoft SMTP Server" og derefter specificerer den TLS-version, den bruger, såvel som den specifikke chiffer.

Den tredje headerblok markerer overgangen fra en lokal mailserver til en mailsfiltreringstjeneste. Du ved dette, fordi det gik "via Frontend Transport", som er en Microsoft-Exchange-specifik protokol (og derfor ikke var strengt SMTP).

Denne blok inkluderer også nogle e-mail-kontroller. Outlook.com's overskrift beskriver deres SPF / DKIM / DMARC-resultater her. En SPF softfail betyder, at denne IP-adresse ikke er autoriseret til at sende e-mails på gmail.com's vegne.

"dkim = pass" betyder, at e-mailen er fra dens påståede afsender og (sandsynligvis) ikke blev ændret under transit.  

DMARC er et sæt regler, der fortæller mailserveren, hvordan SPF og DKIM-resultater skal fortolkes. Pass betyder sandsynligvis, at e-mailen fortsætter til sin destination.

For mere information om SPF, DKIM og DMARC, se denne artikel.

Intern / ekstern overgang

Received: from Redacted.localdomain.com (IP address) byredacted.outlook.com (IP address) with Microsoft SMTPServer (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id15.20.2305.15 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000 Received-SPF: None (Redacted.localdomain.com: no senderauthenticity information available from domain [email protected]) identity=xxx; client-ip=IPaddress;receiver=Redacted.localdomain.com;envelope-from="[email protected]";x-sender="[email protected]"; x-conformance=sidf_compatible Received-SPF: Pass (Redacted.localdomain.com: domain [email protected] designates sending IP as permittedsender) identity=mailfrom; client-ip=IPaddress2;receiver=Redacted.localdomain.com;envelope-from="[email protected]";x-sender="[email protected]"; x-conformance=sidf_compatible;x-record-type="v=spf1"; x-record-text="v=spf1ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

Dette er Googles SPF-post - fortæller den modtagende server, at e-mailen, der siger, at den kommer fra gmail.com, kommer fra en Google-godkendt server.

Received-SPF: None (redacted.localdomain.com: no senderauthenticity information available from domain [email protected]) identity=helo;client-ip=IPaddress; receiver=Redacted.localdomain.com;envelope-from="[email protected]";x-sender="[email protected]";x-conformance=sidf_compatibleAuthentication-Results-Original: [email protected]; [email protected]; spf=Pass [email protected];spf=None [email protected]; dkim=pass (signatureverified) [email protected]; dmarc=pass (p=none dis=none) d=gmail.comIronPort-SDR: IronPort-PHdr: =X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: =X-IronPort-AV: ;d="scan"X-Amp-Result: SKIPPED(no attachment in message)X-Amp-File-Uploaded: False

Dette viser nogle yderligere SPF / DKIM / DMARC-kontroller samt resultaterne fra en IronPort-scanning.

Ironport er et populært e-mail-filter, der bruges af mange virksomheder til at lede efter spam, vira og andre ondsindede e-mails. Den scanner links og vedhæftede filer i e-mailen og bestemmer, om e-mailen er ondsindet (og skal slettes), om den sandsynligvis er legitim og skal leveres, eller om den er mistænksom, i hvilket tilfælde den kan vedhæfte et overskrift til kroppen, som fortæller brugerne at være forsigtige med e-mailen.

Received: from redacted.google.com ([IPAddress])by Redacted.localdomain.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; Fri, 25 Oct 2019 16:16:36 -0400 Received: by redacted.google.com with SMTP idfor [email protected]; Fri, 25 Oct 2019 13:16:35 -0700 (PDT) X-Received: by IPv6:: with SMTP id; Fri, 25 Oct 2019 13:16:35 -0700 (PDT) Return-Path: [email protected] Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT) Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT)

Dette afsnit viser de interne humle, som e-mailen tog fra afsenderens oprindelige enhed gennem gmail's routing-system og til modtagerens Outlook-miljø. Herfra kan vi se, at den oprindelige afsender var fra en Macbook ved hjælp af en hjemme-router med Verizon Fios i NYC.

Dette er slutningen på humlen, der viser ruten, som e-mailen har taget fra afsender til modtager. Efter dette vil du se e-mailens brødtekst (og de overskrifter, du typisk ser som "fra:", "til:" osv.), Måske med en vis formatering baseret på medietypen og e-mail-klienten (f.eks. MIME-version, indholdstype, grænse osv.). Det kan også indeholde nogle bruger-agentoplysninger, som er detaljer om, hvilken type enhed der sendte beskeden.

I dette tilfælde ved vi allerede, at den afsendende enhed var en Macbook på grund af Apples navngivningskonvention, men den kan også indeholde detaljer om CPU-typen, versionen, endda browseren og versionen, der blev installeret på enheden.

I nogle tilfælde, men ikke alle, kan det også indeholde afsenderenhedens IP-adresse (selvom mange udbydere vil skjule disse oplysninger uden en stævning).

Hvad kan e-mail-overskrifter fortælle dig?

E-mail-overskrifter kan hjælpe med at identificere, hvornår der ikke sendes e-mails fra deres påståede afsendere. De kan give nogle oplysninger om afsenderen - selvom det normalt ikke er nok til at identificere den sande afsender.

Retshåndhævelse kan ofte bruge disse data til at indkalde oplysningerne fra den rigtige internetudbyder, men resten af ​​os kan for det meste bare bruge dem til at hjælpe med at informere efterforskninger, generelt til phishing.

Denne proces gøres sværere ved, at overskrifter kan falskes af ondsindede servere eller hackere. Uden at kontakte hver servers ejer og kontrollere, at overskrifterne i din e-mail matcher deres SMTP-logfiler, hvilket er omhyggeligt og tidskrævende, vil du ikke være sikker på, at overskrifterne er nøjagtige (bortset fra overskrifterne, der er vedhæftet af dine egne mailservere).

Uden at kontakte hver servers ejer og individuelt kontrollere, at overskrifterne i din e-mail matcher deres SMTP-logfiler, hvilket er omhyggeligt og tidskrævende, vil du ikke være sikker på, at overskrifterne er nøjagtige ..

DKIM, DMARC og SPF kan alle hjælpe med denne proces, men er ikke perfekte, og uden dem er der slet ingen verifikation.

Vil du ikke analysere dine egne overskrifter? Denne side vil gøre det for dig.