Cara kerja email

dan yang terpenting karena berakhir di spam

Karena ini adalah subjek yang kompleks yang cocok untuk diskusi teknis yang luas, untuk membuatnya dipahami oleh publik "normal", saya mencoba menyederhanakannya. Anggaplah kita memiliki dua teman yang saling menulis, pengirim A dipanggil BENDA dan penerima B dipanggil BUGO.

Coso menulis email ke Bugo. Apa yang terjadi di balik layar?
Server A Coso mengirim email ke server B Bugo.
Secara sederhana, cosi@vattelapesca.it menulis ke bugo@nonmissassare.com.

Semua baik-baik saja untukmu. Dimana masalahnya? Sebenarnya tidak seperti itu. Itu sering terjadi. Saya menghilangkan detail tentang bagaimana surat "dikemas" dan dikirim dalam paket untuk beberapa rute berbeda di seluruh dunia internet untuk dipasang kembali oleh server surat Bugo karena ini menjadi hal yang sangat panjang dan kami akan keluar jalur.

Kami kembali dari cosi@vattelapesca.it yang menulis kepada bugo@nonmissassare.com.

Coso tidak menerima tanggapan. Hari-hari berlalu dan masih tidak mendapat tanggapan. Namun itu adalah komunikasi yang penting! Jadi dia menelepon Bugo di telepon dan Bugo menjawab bahwa dia tidak pernah menerima email itu!

Umumnya, Bugo kemudian memanggil Manajer IT-nya atau manajer hosting dan kemudian orang yang memasok kotak surat dan server surat mulai mengoceh: “Ini! Kembalikan uangku, pencuri! Email tidak berfungsi!!! Saya tidak mendapatkan email dari cosi@vattelapesca.it.

Anda semua memiliki sedikit masalah ini. Intinya adalah setelah semuanya berlalu, hari ini dengan masalah keamanan yang ada, banyak hal telah berubah, terima kasih juga kepada Anda yang sangat ceroboh..

Saat Coso mengirim email ke Bugo, mailserer Bugo memeriksa kembali, menyukai salmon, dan menelusuri kembali jalur kebalikan dari email yang diterima. Dan periksa beberapa hal:

Hal pertama yang diperiksa adalah apakah pengirimnya benar-benar seperti yang mereka katakan. Ini mungkin tampak sepele bagi Anda, tetapi tidak sama sekali! Fakta bahwa Anda adalah cosi@vattelapesca.it itu tidak berarti apa-apa.

Nyatanya, server surat Bugo memeriksa apakah IP dari host pengirim, yaitu "vattelapesca.com” dalam hal ini, cocok dengan IP server surat. Dangkal? TIDAK! Ini sering menjadi masalah pertama yang dihadapi. Manajer TI internal perusahaan sering membuat kesalahan sederhana dengan salah mengonfigurasi zona DNS domain dan tidak menetapkan IP server surat dengan benar. Ini terutama benar jika ada beberapa domain berbeda di satu server. Seringkali, dalam kasus mereka yang menjual layanan hosting dengan mempartisi server yang mereka kelola, mereka salah dalam hal ini. Penyedia besar menangani masalah ini secara sistemik dan oleh karena itu masalahnya hampir tidak pernah ditemukan. Namun di perusahaan besar/menengah, dengan manajer TI yang kurang maksimal, yang mengelola server surat mereka sendiri secara internal, masalah ini menjadi sering terjadi.

Pada dasarnya, mailserver Bugo mengarsipkan email sebagai spam karena tidak mengerti siapa sebenarnya pengirimnya. Dalam kasus ini, bahkan email dibakar sepenuhnya dan bahkan tidak dapat dipulihkan dari folder spam.

Alih-alih, mari kita pastikan bahwa konfigurasi server surat pengirim sudah benar dan server surat Bugo, dengan melakukan kebalikannya, menyatakan bahwa IP-nya benar dan oleh karena itu pengirimnya adalah seperti yang dia katakan.

Namun surat masih belum sampai ke tujuannya. Lagi-lagi panggilan Bugo ke manajer TI-nya, dll… Manajer TI memeriksa dan memverifikasi bahwa penandaan SPF tidak ada. Aduh! Apa itu penandaan SPF?

Sender Policy Framework (SPF) adalah sistem validasi email yang dirancang untuk mendeteksi upaya spoofing email. Sistem ini menawarkan kepada administrator domain email sebuah mekanisme untuk menentukan host yang berwenang untuk mengirim pesan dari domain itu, yang memungkinkan penerima untuk memeriksa validitasnya. [Daftar host yang berwenang untuk mengirim email untuk domain tertentu diterbitkan dalam Sistem Nama Domain (DNS) untuk domain tersebut, dalam bentuk data TXT yang diformat khusus. Phishing, dan terkadang bahkan spam, menggunakan alamat pengirim palsu, jadi memposting dan memverifikasi catatan SPF dapat dianggap sebagai bagian dari teknik anti-spam.

Diterjemahkan, server surat Bugo memeriksa bahwa server surat Coso memiliki otorisasi untuk mengirim email dari host Coso, yaitu cosi@vattelapesca.it, sehingga memverifikasi validitas pengirim dan daftar host resmi. Jika tanda SPF hilang, banyak server surat, setidaknya yang serius saat ini, membakar surat, seringkali Anda bahkan tidak menemukannya lagi di kotak spam.

Selesai? TIDAK!

Mari kita berpura-pura itu cosi@vattelapesca.it juga memiliki penandaan SPF yang dikonfigurasi dengan benar.

Email masih belum sampai. Lagi-lagi panggilan dari Bugo ke manajer IT-nya dan manajer IT yang mengontrol. Dan apa yang dia temukan?

Tanda DKIM hilang Appero! Dan apa ini? Iblis apa ini?

DomainKeys Identified Mail (DKIM): memungkinkan pengelola domain menambahkan tanda tangan digital melalui kunci pribadi ke pesan email. Oleh karena itu DKIM menambahkan alat lebih lanjut untuk memverifikasi korespondensi antara pengirim dan domain miliknya.

Sekali lagi, untuk menyederhanakannya, dengan email, cosi@vattelapesca.it itu juga mengirimkan kunci pribadi acak yang ditautkan ke kunci publik yang berada di zona DNS domain vattelapesca.it dan server surat penerima memeriksa apakah kunci sudah ditautkan. Jika tidak, email tersebut berakhir di spam.

Kontrol yang sempurna hanyalah Reverse+SPF+DKIM. Jika email tidak lolos pemeriksaan ini, email tersebut akan dibakar.

Seringkali beberapa pelanggan meminta saya untuk memasukkan daftar putih misalnya domain vattelapesca.it tetapi jika melakukan sebaliknya, IP masih belum benar, Daftar Putih tidak berguna. Selain itu, ini adalah permintaan yang salah karena alasan sederhana: Anda tidak dapat mengetahui apakah pengirim yang dimaksud "beriktikad baik" karena kadang-kadang, bahkan pengirimnya sendiri tidak mengetahuinya. Seolah-olah Anda memiliki seorang teman yang tinggal di dekat kamp pengembara dan Anda memintanya untuk tetap membuka pintu depan, "dengan itikad baik".

Tapi mari kita lanjutkan.

Di cek, anggap saja enkripsi DKIM juga oke. Atau mungkin bahkan tidak perlu. Tapi emailnya tidak sampai.

Lagi-lagi panggilan Bugo ke Manajer TI-nya yang sekarang kelelahan. Permintaannya pasti: taruh cosi@vattelapesca.it masuk daftar putih.

Tapi kamu tidak bisa. Anda melanggar protokol keamanan yang membahayakan seluruh perusahaan. Manajer TI memeriksa dan…

Domain vattelapesca ada di beberapa RBL/DNSBL. Ah! Caper! Tapi apakah mereka?

Daftar Blackhole berbasis DNS (juga DNSBL, Real-time Blackhole List atau RBL) adalah sarana yang memungkinkan untuk menerbitkan daftar alamat IP, dalam format khusus yang dapat dengan mudah "ditanya" melalui Internet. Seperti namanya, mekanisme kerjanya didasarkan pada DNS (Domain Name System). DNSBL terutama digunakan untuk menerbitkan alamat IP yang terkait dengan spammer dalam beberapa cara. Sebagian besar server email dapat dikonfigurasi untuk menolak atau menandai pesan yang dikirim dari host pada satu atau beberapa daftar.

Tetapi pada saat itu Manajer TI Bugo menjawab kepada majikannya dan berkata: "Teman-teman, jika mereka terdaftar di RBL, bukan kami yang harus memahami mengapa dan menyelesaikan masalah, Manajer TI pengirim harus memikirkannya ”.

Dan email itu berakhir di tempat sampah.

Akan ada lebih banyak lagi untuk ditambahkan tetapi saya ingin berhenti di sini. Namun, katakanlah semua ini adalah minimum yang sangat diperlukan, bahwa tidak cukup untuk memblokir orang jahat, kontrol lain ditambahkan dan juga masalah yang melekat pada protokol DKIM yang merupakan protokol terbuka dan dapat ditafsirkan dan oleh karena itu tidak ada keseragaman, jadi sehingga sering terjadi masalah pengiriman/penerimaan dari/ke kotak surat di Libero, Virgilio, Gmail dll…. dan mereka adalah masalah yang sangat sulit untuk dipecahkan. Selain itu, ada masalah terkait perilaku individu yang seringkali bertentangan dengan netiket seperti penggunaan header email yang salah, pengiriman simultan ke beberapa pengguna berbeda yang tidak terenkripsi, dan sebagainya.

Sebuah dunia terbuka di mana teknisi, ilmuwan komputer, insinyur, matematikawan, fisikawan saling berhadapan tanpa, bagaimanapun, pada prinsipnya berhasil menemukan solusi (dan menurut saya mereka tidak akan pernah menemukannya).

Yang bisa saya katakan adalah bahwa pilihan layanan hosting yang baik harus melalui berbagai faktor yang tidak pernah harga dan di atas semua itu harus menanggapi kebutuhan keamanan yang harus menjadi ABC dari setiap perusahaan yang saat ini terpapar di internet dalam berbagai bentuk dan dengan berbagai cara.