Pertama, anda menggunakan ejen pengguna mel, atau MUA untuk membaca dan menghantar e-mel dari peranti anda (seperti gmail, atau aplikasi mel pada peranti Apple). Program-program ini hanya aktif semasa anda menggunakannya.
Umumnya, mereka berkomunikasi dengan ejen pemindahan surat, atau MTA (juga dikenali sebagai pelayan e-mel, host MX, dan penukar surat), yang berfungsi untuk menerima dan menyimpan e-mel anda.
E-mel disimpan dari jauh sehingga anda membuka MUA anda untuk memeriksa e-mel anda. E-mel dihantar oleh ejen penghantaran surat (MDA), yang biasanya dibungkus dengan MTA.
Surat digunakan untuk dihantar ke pelayan e-mel menggunakan SMTP, atau Simple Mail Transfer Protocol. SMTP adalah protokol komunikasi untuk e-mel.
Walaupun sekarang, sementara banyak sistem proprietari seperti Microsoft Exchange dan program mel web seperti Gmail menggunakan protokol mereka sendiri secara dalaman, mereka menggunakan SMTP untuk memindahkan mesej ke luar sistem mereka (contohnya, jika pengguna Gmail ingin mengirim e-mel kepada klien Outlook).
Surat kemudian akan dimuat dari pelayan menggunakan Post Office Protocol (POP3) POP3 adalah protokol lapisan aplikasi yang menyediakan akses melalui jaringan protokol internet (IP) agar aplikasi pengguna dapat menghubungi kotak surat pada pelayan surat. Ia boleh menyambung, mengambil mesej, menyimpannya di komputer pelanggan, dan memadam atau menyimpannya di pelayan.
Ia dirancang untuk dapat menguruskan sambungan internet sementara, seperti dial-up (jadi hanya akan menyambung dan mengambil e-mel ketika disambungkan, dan membolehkan anda melihat mesej ketika anda berada di luar talian). Ini lebih popular apabila akses dial-up lebih meluas.
Kini, IMAP, Protokol Akses Mesej Internet, kebanyakan telah menggantikan POP3. IMAP boleh membenarkan beberapa pelanggan mengurus peti mel yang sama (sehingga anda dapat membaca e-mel anda dari desktop, komputer riba, dan telefon, dll. Dan semua mesej anda akan berada di sana, disusun dengan cara yang sama).
Akhirnya, mel web menggantikan kedua-duanya. Webmail membolehkan anda masuk ke laman web dan menerima mesej dari mana sahaja atau mana-mana peranti (yay!), Namun anda perlu disambungkan ke internet semasa menggunakannya. Sekiranya laman web (seperti gmail) adalah MUA anda, anda tidak perlu mengetahui tetapan pelayan SMTP atau IMAP.
Bagaimana e-mel dilindungi?
Malangnya, keselamatan tidak benar-benar dimasukkan ke dalam protokol mel dari awal (seperti kebanyakan protokol internet permulaan). Pelayan hanya diharapkan dapat mengambil mesej dari sesiapa sahaja dan menyampaikannya ke pelayan lain yang dapat membantu menghantar mesej ke destinasi terakhirnya (penerima di medan ke:
Tidak mengejutkan, ini menjadi masalah apabila internet berkembang dari beberapa kumpulan pemerintah dan penyelidikan menjadi sesuatu yang digunakan oleh sebahagian besar dunia untuk melakukan semuanya. Tidak lama lagi e-mel spam dan phishing menjadi (dan kekal) masalah besar bagi semua orang.
Sebagai tindak balas, kami secara kolektif telah berusaha untuk menerapkan beberapa langkah yang menghalang orang membaca mesej (enkripsi) orang lain dan mengesahkan bahawa mesej sebenarnya berasal dari pengirim yang dimaksudkan (pengesahan).
Sebilangan besar tempat menggunakan TLS (keselamatan lapisan pengangkutan, pengganti SSL, lapisan soket selamat), protokol kriptografi yang menyediakan penyulitan dalam perjalanan. Ini memberikan perlindungan ketika pesan dikirim, tetapi tidak ketika data sedang dalam keadaan rehat, (misalnya, disimpan di komputer anda).
Ini memastikan bahawa mesej tidak diubah atau diintip semasa dalam perjalanan dari MTA ke MTA. Walau bagaimanapun, ini tidak mengesahkan bahawa mesej itu tidak diubah semasa perjalanan.
Sebagai contoh, jika e-mel melalui beberapa pelayan mel sebelum sampai ke tujuan akhir, menggunakan TLS akan memastikan ia dienkripsi antara pelayan, tetapi setiap pelayan dapat mengubah kandungan mesej. Untuk mengatasinya, kami telah membuat SPF, DKIM, dan DMARC.
SPF (Kerangka Dasar Pengirim)
SPF membenarkan pemilik domain (seperti google.com) untuk menetapkan rekod TXT dalam DNSnya yang menyatakan pelayan mana yang dibenarkan untuk menghantar e-mel dari domain tersebut (untuk arahan mengenai cara melakukannya untuk pelbagai penyedia hosting, lihat ini tapak).
Bagaimana ianya berfungsi?
Rekod ini menyenaraikan peranti (biasanya melalui IP) yang dibenarkan dan boleh berakhir dengan salah satu pilihan berikut:
-all = Sekiranya cek gagal (sumber e-mel bukan salah satu peranti yang disenaraikan) hasilnya adalah HardFail. Sebilangan besar sistem mel akan menandakan mesej ini sebagai spam.
? all = = Sekiranya cek gagal (sumber e-mel bukan salah satu peranti yang disenaraikan) hasilnya adalah neutral. Ini biasanya digunakan untuk ujian, bukan domain pengeluaran.
~ semua = Sekiranya cek gagal (sumber e-mel bukan salah satu peranti yang disenaraikan) hasilnya adalah SoftFail. Ini bermaksud bahawa mesej ini mencurigakan, tetapi tidak semestinya diketahui buruk. Beberapa sistem mel akan menandakan mesej ini sebagai spam, tetapi kebanyakannya tidak.
Header SPF dapat membantu pelayan itu sendiri, kerana mereka memproses mesej. Sebagai contoh jika pelayan berada di pinggir rangkaian, ia tahu mesej yang diterimanya harus datang dari pelayan dalam rekod SPF pengirim. Ini membantu pelayan menyingkirkan spam dengan lebih pantas. Walaupun ini terdengar hebat, sayangnya, terdapat beberapa masalah besar dengan SPF.
- SPF tidak memberitahu pelayan e-mel apa yang harus dilakukan dengan mesej - yang bermaksud bahawa mesej boleh gagal dalam pemeriksaan SPF dan masih dapat dihantar.
- Rekod SPF tidak melihat alamat 'dari' yang dilihat pengguna, tetapi melihat 'jalan balik'. Ini pada dasarnya setara dengan alamat pengembalian yang anda tulis pada sepucuk surat. Ini memberitahu pelayan e-mel yang menangani surat di mana untuk mengembalikan mesej (dan disimpan di tajuk e-mel - pada dasarnya pelayan maklumat teknikal digunakan untuk memproses e-mel).
Ini bermaksud saya boleh memasukkan apa sahaja yang saya mahukan ke alamat dari: dan itu tidak akan mempengaruhi pemeriksaan SPF. Sebenarnya, kedua-dua alamat e-mel tersebut dapat dikuasai oleh penggodam. Oleh kerana tidak ada penyulitan yang terlibat, tajuk SPF tidak dapat dipercayai sepenuhnya.
- Rekod SPF perlu sentiasa dikemas kini yang sukar di organisasi yang besar dan sentiasa berubah.
- Pemajuan pecah SPF. Ini kerana jika e-mel dari, katakanlah google.com, diteruskan oleh [email protected], pengirim sampul surat tetap tidak berubah (alamat dari masih mengatakan google.com). Pelayan e-mel penerima menganggap bahawa ia mengaku berasal dari google.com, tetapi berasal dari bobsburgers.com, jadi ia gagal dalam pemeriksaan SPF (walaupun surat itu sebenarnya berasal dari google.com).
Untuk membaca lebih lanjut mengenai SPF, baca artikel-artikel ini. Anda boleh memeriksa sama ada domain tertentu mempunyai rekod SPF dan DMARC yang dikonfigurasi di sini.
DKIM (MailKeys DomainKeys)
DKIM serupa dengan SPF. Ia menggunakan catatan TXT dalam DNS domain pengirim juga, dan ia memberikan beberapa pengesahan terhadap mesej itu sendiri. Ini berusaha untuk memberikan pengesahan bahawa pesan tidak diubah dalam perjalanan.
Bagaimana ianya berfungsi?
Domain pengirim menghasilkan pasangan kunci awam / peribadi dan memasukkan kunci awam dalam rekod TXT DNS domain (jika anda tidak tahu apa itu pasangan kunci awam / swasta, lihat artikel ini tentang kriptografi)
Kemudian, pelayan mel domain (di sempadan luar - pelayan yang menghantar e-mel di luar domain (mis. Dari gmail.com ke outlook.com)) menggunakan kunci peribadi untuk menghasilkan tandatangan seluruh badan mesej, termasuk tajuk.
Untuk menghasilkan tandatangan biasanya memerlukan teks dicincang dan disulitkan (untuk keterangan lebih lanjut mengenai proses ini, lihat artikel ini).
Menerima pelayan mel menggunakan kunci awam dalam rekod DNS TXT untuk menyahsulitkan tandatangan dan kemudian mencantumkan mesej dan tajuk yang relevan (mana-mana tajuk yang dibuat semasa surat itu berada di dalam infrastruktur pengirim - contohnya jika beberapa pelayan gmail memproses e-mel sebelum itu dihantar secara luaran ke outlook.com).
Pelayan kemudian akan memeriksa untuk memastikan kedua-dua hash itu sepadan. Sekiranya mereka melakukannya, mesej itu mungkin tidak berubah (kecuali seseorang telah menjejaskan kunci peribadi pengirim) dan sah dari pengirim yang dinyatakan. Sekiranya hash tidak sesuai, mesej itu bukan dari pengirim yang dinyatakan, atau diubah oleh beberapa pelayan lain dalam perjalanan, atau kedua-duanya.
DKIM melakukan pekerjaan yang sangat baik pada satu tugas yang sangat spesifik - menjawab soalan 'adakah e-mel ini diubah dalam perjalanan atau tidak dari pengirim yang dikatakan?'. Walau bagaimanapun, itu sahaja. Ini tidak memberitahu anda bagaimana menangani e-mel yang gagal dalam ujian ini, pelayan mana yang mungkin mengubah mesej, atau perubahan apa yang dibuat.
DKIM juga digunakan oleh beberapa ISP, atau Penyedia Perkhidmatan Internet, untuk menentukan reputasi domain anda (adakah anda mengirim banyak spam? Adakah anda mempunyai keterlibatan yang rendah? Berapa kerap e-mel anda melantun?).
Untuk membaca lebih lanjut mengenai DKIM, baca artikel ini. Anda boleh mengesahkan rekod DKIM di sini.
DMARC (Pengesahan, Pelaporan, dan Kesesuaian Mesej Berasaskan Domain)
DMARC pada dasarnya adalah arahan untuk pelayan e-mel mengenai cara mengendalikan rekod SPF dan DKIM. Ia tidak melakukan ujian sendiri, tetapi memberitahu pelayan mel bagaimana menangani pemeriksaan yang dilakukan oleh SPF dan DKIM.
ISP yang mengambil bahagian akan melihat rekod DMARC yang diterbitkan dan menggunakannya untuk menentukan bagaimana menangani DKIM atau SPF yang gagal. Oleh itu, sebagai contoh, jenama yang sering ditipu mungkin menerbitkan rekod DMARC yang mengatakan bahawa jika DKIM atau SPF gagal, lepaskan mesej.
Selalunya ISP juga akan menghantar laporan mengenai aktiviti domain anda kepada anda dengan sumber e-mel dan sama ada ia lulus / gagal DKIM / SPF. Ini bermaksud bahawa anda akan dapat melihat kapan orang melakukan spoofing (kononnya untuk menghantar dari) domain anda atau mengubah mesej anda.
Untuk melaksanakan DMARC, anda perlu membuat catatan DMARC, berdasarkan keperluan anda (dari memantau lalu lintas e-mel anda untuk mengetahui apa semua sumber e-mel anda sehingga meminta tindakan diambil, seperti menolak sebarang e-mel yang gagal DKIM atau SPF). Anda boleh mengetahui lebih lanjut mengenai melakukannya di sini dan di sini.
Untuk membaca lebih lanjut mengenai DMARC, baca artikel ini. Anda boleh memeriksa sama ada domain tertentu mempunyai rekod SPF dan DMARC yang dikonfigurasi di sini.
Balut
Tidak satu pun langkah keselamatan ini sempurna, tetapi bersama-sama, mereka melakukan tugas yang baik untuk membantu kita meningkatkan keselamatan sistem e-mel di seluruh dunia.
Semakin banyak organisasi yang mengambil langkah-langkah ini (sama ada menggunakan pelaksanaan sumber terbuka atau membayar produk) semakin baik semua orang. Keselamatan yang ditambahkan setelah protokol atau produk dikembangkan biasanya lebih mahal, kurang efektif, dan lebih sukar dilaksanakan, daripada keselamatan yang terdapat di dalam produk.
Namun, kebanyakan protokol yang bergantung pada internet semasa dirancang untuk internet awal - untuk sekumpulan kecil peminat, saintis, dan orang pemerintah - bukan rangkaian di seluruh dunia di mana kita menjalankan bangunan, peranti pintar, transit awam, loji nuklear (!), dan sebagainya.
Oleh itu, ketika internet terus berkembang, kita harus terus menyesuaikan diri dan mengembangkan cara baru untuk mendapatkan sistem yang kita andalkan.