Apa yang ada dalam Header E-mel dan Mengapa Anda Perlu Peduli?

Pernah mendapat mesej spam atau pancingan data dari alamat e-mel yang tidak anda kenali? Mungkin seseorang menawari anda perjalanan percuma, meminta anda untuk mengirim mereka bitcoin sebagai pertukaran untuk gambar peribadi, atau hanya menghantar e-mel pemasaran yang tidak diingini kepada anda?

Adakah anda terfikir dari mana datangnya e-mel tersebut? Melihat spammer menipu alamat e-mel anda dan bertanya-tanya bagaimana mereka melakukannya?

Spoofing e-mel, atau membuat e-mel muncul seolah-olah e-mel itu berasal dari alamat yang berbeza daripada yang ada (contohnya e-mel yang nampaknya berasal dari whitehouse.gov, tetapi sebenarnya dari penipu) sangat mudah.

Protokol e-mel inti tidak mempunyai kaedah untuk pengesahan, yang bermaksud bahawa alamat 'dari' pada dasarnya hanyalah pengisian-kosong.

Biasanya apabila anda mendapat e-mel, ia kelihatan seperti ini:

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

Di bawah ini adalah subjek dan mesej.

Tetapi bagaimana anda tahu dari mana asalnya e-mel itu? Tidak ada data tambahan yang dapat dianalisis?

Apa yang kami cari ialah tajuk e-mel penuh - apa yang anda lihat di atas hanyalah pengepala separa. Data ini akan memberi kami beberapa maklumat tambahan mengenai dari mana datangnya e-mel dan bagaimana ia sampai ke peti masuk anda.

Sekiranya anda ingin melihat tajuk e-mel anda sendiri, berikut adalah cara mengaksesnya di Outlook dan Gmail. Sebilangan besar program mel beroperasi dengan cara yang serupa, dan carian Google yang mudah akan memberitahu anda bagaimana melihat tajuk pada perkhidmatan mel alternatif.

Dalam artikel ini, kita akan melihat sekumpulan tajuk sebenar (walaupun mereka sangat redaktur - saya telah menukar nama host, cap waktu dan alamat IP)

Kami akan membaca tajuk dari atas ke bawah, tetapi perlu diketahui bahawa setiap pelayan baru menambahkan tajuk mereka ke bahagian atas badan e-mel. Ini bermaksud kami akan membaca setiap tajuk dari Ejen Pemindahan Mesej terakhir (MTA) dan meneruskan MTA pertama untuk menerima mesej.

Pemindahan Dalaman

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

Hop pertama ini menunjukkan garis HTTPS, yang bermaksud bahawa pelayan tidak menerima mesej melalui SMTP standard dan sebaliknya membuat mesej dari input yang diterima di aplikasi web.

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)

Ini adalah dua blok header pertama adalah pemindahan surat dalaman. Anda dapat mengetahui bahawa ini diterima oleh pelayan Office365 (outlook.com), dan dihalakan secara dalaman ke penerima yang betul.

Anda juga dapat mengetahui bahawa mesej tersebut dihantar melalui SMTP yang dienkripsi. Anda tahu ini kerana tajuk menyenaraikan "dengan Microsoft SMTP Server" dan kemudian menentukan versi TLS yang digunakannya, serta cipher tertentu.

Blok pengepala ketiga menandakan peralihan dari pelayan mel tempatan ke perkhidmatan penapisan mel. Anda tahu ini kerana ia "melalui Frontend Transport" yang merupakan protokol khusus Microsoft-Exchange (dan oleh itu ia bukan SMTP).

Blok ini juga merangkumi beberapa pemeriksaan e-mel. Tajuk Outlook.com memperincikan hasil SPF / DKIM / DMARC mereka di sini. Softfail SPF bermaksud bahawa alamat IP ini tidak dibenarkan untuk menghantar e-mel atas nama gmail.com.

"dkim = pass" bermaksud bahawa e-mel adalah dari pengirimnya yang dikatakan dan (kemungkinan besar) tidak diubah dalam perjalanan.  

DMARC adalah sekumpulan peraturan yang memberitahu pelayan mel bagaimana menafsirkan hasil SPF dan DKIM. Pas mungkin bermaksud bahawa e-mel terus ke tempat tujuannya.

Untuk maklumat lanjut mengenai SPF, DKIM, dan DMARC, baca artikel ini.

Peralihan Dalaman / Luaran

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"

Ini adalah catatan SPF Google - memberitahu pelayan penerima bahawa e-mel yang mengatakan ia berasal dari gmail.com, berasal dari pelayan yang diluluskan oleh Google.

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

Ini menunjukkan beberapa pemeriksaan SPF / DKIM / DMARC tambahan, serta hasil dari imbasan IronPort.

Ironport adalah penapis e-mel popular yang digunakan oleh banyak syarikat untuk mencari spam, virus, dan e-mel jahat lain. Ini mengimbas pautan dan lampiran dalam e-mel dan menentukan apakah e-mel itu berniat jahat (dan harus ditinggalkan), jika kemungkinan itu sah dan harus dihantar, atau jika mencurigakan dalam hal ini dapat melampirkan tajuk ke badan yang memberitahu pengguna agar berhati-hati dengan e-mel tersebut.

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)

Bahagian ini menunjukkan hop dalaman yang diambil oleh e-mel dari peranti awal pengirim melalui sistem penghalaan gmail dan ke persekitaran pandangan penerima. Dari ini kita dapat melihat bahawa pengirim awal berasal dari Macbook, menggunakan penghala rumah, dengan Verizon Fios di NYC.

Ini adalah hujung hop yang menunjukkan laluan yang telah diambil oleh e-mel dari pengirim ke penerima. Setelah ini, anda akan melihat isi e-mel (dan tajuk yang biasanya anda lihat seperti "dari:", "hingga:", dll.), Mungkin dengan beberapa pemformatan berdasarkan jenis media dan pelanggan e-mel (misalnya Versi MIME, jenis kandungan, batas, dll). Ia mungkin juga mengandungi beberapa maklumat ejen pengguna, yang merupakan perincian mengenai jenis peranti yang menghantar mesej.

Dalam hal ini kita sudah tahu bahawa perangkat pengiriman adalah Macbook karena konvensi penamaan Apple, tetapi mungkin juga berisi perincian tentang jenis CPU, versi, bahkan penyemak imbas dan versi yang dipasang pada perangkat.

Dalam beberapa kes, tetapi tidak semuanya, mungkin juga mengandungi alamat IP dari alat pengirim (walaupun banyak penyedia akan menyembunyikan maklumat tersebut tanpa panggilan pengadilan).

Apa yang boleh diberitahu oleh pengepala e-mel kepada anda?

Pengepala e-mel dapat membantu mengenal pasti kapan e-mel tidak dihantar dari pengirimnya. Mereka dapat memberikan beberapa maklumat mengenai pengirim - walaupun biasanya tidak cukup untuk mengenal pasti pengirim yang sebenarnya.

Penguatkuasaan undang-undang sering dapat menggunakan data ini untuk memanggil maklumat dari ISP yang tepat, tetapi kebanyakan kita hanya dapat menggunakannya untuk membantu memberitahu siasatan, umumnya mengenai pancingan data.

Proses ini dibuat lebih sukar oleh kenyataan bahawa header dapat dipalsukan oleh pelayan atau penggodam yang berniat jahat. Tanpa menghubungi setiap pemilik pelayan dan secara sendiri mengesahkan bahawa tajuk dalam e-mel anda sepadan dengan log SMTP mereka, yang menyusahkan dan memakan masa, anda tidak akan memastikan tajuk itu tepat (selain tajuk yang dilampirkan oleh pelayan e-mel anda sendiri).

Without contacting each server's owner and individually verifying that the headers in your email match their SMTP logs, which is painstaking and time-consuming, you won't be certain the headers are all accurate..

DKIM, DMARC and SPF can all help with this process, but aren't perfect, and without them, there's no verification at all.

Don't want to analyze your own headers? This site will do it for you.