tl; dr di bawah.
Protokol SMTP tidak memiliki pengertian penerima CC atau BCC; ini adalah konvensi yang diadakan oleh klien surat. Server SMTP biasanya hanya peduli tentang perutean informasi dan data. Ini adalah perbedaan penting, karena tanpa kemampuan ini, BCC tidak akan ada. Sebagai komunikasi BCC yang sah pertimbangkan transkrip klien berikut:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Sekarang, dalam hal ini, Anonymous dikirimi pesan tentang pertemuan ini. Namun, versi surat ini tidak dialihkan ke Jane Doe; dia tidak tahu apa-apa tentang Anonymous yang diberi tahu. Sebaliknya, Jane Doe akan dikirimi pesan dengan badan dan tajuk yang berbeda:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Di sini, karena Anonim ada di BCC, pesan yang dikirim ke Jane Doe tidak termasuk daftar penerima BCC. Karena konvensi BCC, amplop email mungkin tidak termasuk penerima yang benar-benar menerima pesan, dan itu mungkin juga termasuk penerima yang tidak muncul di header pesan.
Seperti disebutkan oleh @JonasWielicki , yang juga dimaksudkan untuk saya sertakan, adalah bahwa MUA (Mail User Agent) biasanya bertanggung jawab untuk mengirim beberapa email yang diperlukan untuk mengimplementasikan BCC. Server email tidak tahu apa-apa tentang BCC, sehingga MUA harus mengimplementasikan BCC dengan mengirim banyak email dengan rute email berbeda yang ditentukan dalam header amplop. Untuk alasan ini, BCC biasanya membutuhkan waktu lebih lama untuk mengirim daripada email biasa, karena badan pesan yang berbeda harus dibuat dan dikirim secara terpisah.
Ini juga membantu dengan beberapa aturan kepatuhan email. Misalnya, server email mungkin memiliki aturan yang dikonfigurasi untuk secara otomatis BCC server email arsip (semua email yang dikirim juga diarsipkan), dalam hal ini server email bahkan mungkin bukan penerima yang sebenarnya.
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Di sini, penerima adalah pihak lain yang benar-benar dirahasiakan kepada salah satu penerima atau bahkan pengirim. Ini adalah fitur protokol, biasanya digunakan untuk menyampaikan atau mengarsipkan pesan.
Apa yang dilakukan pesan spam ini adalah memanfaatkan perilaku itu. Ini adalah celah standar yang secara teknis harus berfungsi dengan server surat yang sesuai. Tentu saja, banyak server yang diperbarui menggunakan "ekstensi" seperti DKIM untuk memverifikasi bahwa email seperti itu asli, tetapi masih ada banyak server email lama di luar sana yang tidak peduli, hanya karena tergoda untuk tidak memperbaiki hal-hal yang tidak rusak.
Perhatikan juga bagaimana saya telah menentukan header Tanggal. Ini bisa berupa nilai sembarang (tapi diformat dengan baik); banyak klien dengan senang hati akan menampilkan rentang tanggal hukum apa pun dari masa lalu yang jauh ke masa depan yang jauh. Saya secara pribadi telah mengirim email kepada diri saya sendiri bertahun-tahun yang lalu yang akan tetap di bagian atas kotak surat saya lama setelah harapan hidup saya, serta email yang mendahului akun email saya dan kelahiran saya sendiri.
tl; dr
Jadi, secara ringkas, pengirim mem-spoof email, server email asal menerimanya / menyampaikannya, server email Anda menerimanya dan menyimpannya di kotak masuk Anda, dan klien Anda dengan setia menampilkan data yang ada di kotak masuk Anda kepada Anda, semua tanpa menghindari keamanan apa pun. Keamanan "Mengirim" seringkali jauh lebih sedikit dibatasi daripada keamanan "menerima" dalam perspektif itu, karena POP3 hampir selalu membutuhkan nama pengguna dan kata sandi sebelum Anda dapat mengakses kotak surat (secara teoritis Anda bisa mengelak dari ini, tapi saya tidak tahu ada yang sah layanan surat yang melakukannya).