Email yang dikirimkan kepada saya ditujukan ke MAIL@MAIL.COM. Bagaimana ini dilakukan?


103

Saya baru-baru ini mengirim email penipuan, dan untuk cekikikan saya membukanya untuk membacanya. Sangat sederhana, dan tidak banyak usaha yang dilakukan.

Saya perhatikan sesuatu yang aneh; email ini tidak ditujukan kepada saya. Pada awalnya, saya mencurigai CC, atau BCC, tetapi tidak ada alamat email saya. Saya telah memberikan gambar di bawah ini. Bagaimana ini dilakukan?

masukkan deskripsi gambar di sini


8
Posting tajuk pesan lengkap ... juga Anda mungkin memiliki alamat SMTP sekunder di server email tempat mungkin dikirim. Admin server email harus dapat membantu menyarankan Anda tentang hal ini tetapi mengedit Anda menjawab dan memposting detail tajuk pesan lengkap dari pesan ini juga.
Pimp Juice

55
Anda mungkin berada di bidang salinan karbon dari email.
Mokubai

61
Anda tidak akan melihat daftar BCC, itulah bagian terakhir "B" . ;)
Ƭᴇcʜιᴇ007

14
@tuskiomi Tidak, tidak di Outlook. Gmail memang menunjukkan bcc: me, mungkin orang lain juga melakukannya ... Tetapi jika Anda melihat header pesan lengkap Anda akan melihat email Anda di sana
wysiwyg

20
@tuskiomi - Tidak, Anda tidak akan pernah melihat orang yang terdaftar di BCC, bahkan diri Anda sendiri. Selain itu, jika itu adalah spam, bahkan mungkin tidak ada daftar BCC yang sebenarnya; spamware dapat mengatur daftar penerima dengan cara apa pun yang diinginkannya, dan yang paling penting adalah seperti apa dialog spamware dengan server email - bukan seperti apa isi surat itu. Satu-satunya cara Anda akan melihat alamat email Anda adalah jika Anda melihat header internet.
Jeff Zeitlin

Jawaban:


152

Pesan email Internet terdiri dari dua bagian. Kita bisa menyebutnya sebagai amplop dan pesan payload atau hanya pesan .

Amplop memiliki data perutean: utamanya, ini adalah alamat pengirim dan satu atau lebih alamat penerima.

Pesan memiliki konten pesan: baris subjek, isi pesan, lampiran, dan sebagainya. Itu juga membawa beberapa informasi teknis seperti trace ( Received:) header, data DKIM, dan sebagainya; serta alamat pengirim dan penerima yang ditampilkan (apa yang Anda lihat di From, Todan Ccbidang di klien email Anda).

Inilah intinya: Keduanya tidak harus setuju!

Server email akan melihat data amplop untuk menentukan cara mengirim pesan. Di sisi lain, dengan beberapa pengecualian, pesan itu sendiri akan diperlakukan hanya sebagai data. Khususnya, server surat berperilaku baik tidak melihat To:dan Cc:bidang pesan itu sendiri untuk menentukan daftar penerima, juga tidak melihat From:bidang untuk menentukan alamat pengirim.

Saat Anda menulis dan mengirim email, klien email Anda mengambil apa yang Anda masukkan ke dalam bidang Ke, Cc dan Bcc, dan menerjemahkannya ke dalam informasi perutean amplop. Ini terutama dilakukan dengan menghapus nama lengkap (hanya menyisakan alamat email), tetapi juga dapat melibatkan hal-hal seperti penulisan ulang alamat, ekspansi alias, dan sebagainya. Hasilnya adalah daftar alamat e-mail yang diberikan ke server surat yang dibicarakan oleh klien surel Anda sebagai daftar penerima. Daftar Ke dan Cc disimpan dalam email, tetapi Bcc tidak diteruskan ke server, membuatnya tidak terlihat oleh penerima pesan. Alamat pengirim berfungsi sangat mirip.

Ketika pesan mencapai tujuan akhirnya, data amplop dibuang, atau disimpan di header pesan terperinci. Itulah salah satu alasan mengapa Spittin 'IT meminta header pesan lengkap dalam komentar untuk pertanyaan Anda.

Selain itu, dengan email Internet, dimungkinkan untuk berbicara langsung ke server email, dan dengan demikian menyuntikkan pesan yang memiliki ketidakcocokan antara data amplop dan data pesan bahwa klien email yang normal dan berperilaku baik tidak akan biarkan kamu menulis. Selain itu, server surat melakukan berbagai tingkat pemeriksaan pada alamat pengirim yang diberikan dalam data amplop; beberapa hampir tidak memeriksa sama sekali di luar memastikan itu adalah alamat email yang valid secara sintaksis . Header Dari dari data pesan semakin tidak diperhatikan.

Karena klien email penerima menampilkan apa yang ada di header Dari, Kepada, dan Cc, bukan data alamat dari amplop, dimungkinkan untuk meletakkan apa pun yang Anda inginkan di sana dan klien email penerima tidak akan memiliki jalan lain kecuali percaya bahwa itu cukup akurat. Untuk surat yang sah biasanya cukup akurat; untuk spam, hampir tidak pernah ada.

Dalam dunia nyata, benda-benda fisik dihuni oleh manusia saja, yang pengirim amplop dan amplop penerima sesuai dengan alamat pengirim dan alamat penerima, masing-masing, bahwa Anda menulis di bagian luar amplop; dan From:dan To:/ Cc:header sesuai dengan apa pun yang Anda masukkan sebagai alamat Anda dan penerima, masing-masing, dalam surat yang Anda masukkan ke dalam amplop.


8
Saya berharap orang membuat lebih banyak analogi dunia nyata di sini sehingga orang lain akan memahami apa yang setara secara fisik. "Pengirim" email seperti orang yang menyerahkan amplop kepada tukang pos; alamat "dari" adalah alamat yang dituju. Seperti Anda bisa menjadi sekretaris yang mengirim atas nama orang lain, dll.
Mehrdad

21
@Mehrdad No; alamat pengirim amplop (SMTP) adalah seperti alamat pengirim di luar amplop (di mana ia dikirim jika tidak dapat dikirim), sedangkan alamat di Fromheader adalah apa pun yang Anda tulis di selembar kertas yang Anda tempel di dalam amplop dan bahwa tukang pos bahkan tidak tahu.
CVn

Saya sedang memikirkan header Pengirim ketika saya menulis itu, dan itu hanya sebuah contoh. Hanya mengatakan itu akan bagus untuk menambahkan contoh seperti ini ke jawaban Anda.
Mehrdad

91
The jumlah huruf tebal di sini benar-benar perlu di terbaik . Dan itu hanya pendapat saya .
JakeGould

3
@SupremeGrandRuler Karena informasi penerima (berbeda dengan Pengirim atau Jalur Pengembalian yang mungkin) tidak terdapat dalam email. Bayangkan daftar penerima lengkap dimasukkan, termasuk alamat yang MUA dapatkan dari bidang Bcc (ingat: SMTP (protokol amplop) tidak tahu tentang Bcc, hanya tahu tentang penerima) ... Itu akan menjadi masalah privasi (dan buang banyak ruang) tidak hanya pada milis besar (beroperasi dengan prinsip yang sama seperti Bcc).
Jonas Schäfer

23

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).


3
Anda harus mencatat bahwa pengupasan Bcc biasanya tidak ditangani oleh server mail (transkrip SMTP yang Anda berikan menyarankan sebaliknya, karena HELO terdengar seperti server email dan bukan MUA). Untuk memberikan salinan dengan header Bcc kepada orang yang dituju dalam header itu membutuhkan kerja ekstra oleh MUA dengan mengirim dua email terpisah.
Jonas Schäfer

@JonasWielicki Itu poin yang bagus. Saya telah menambahkan edit ke efek itu.
phyrfox

5
Jika Anda menambahkan baris bcc ke surat yang dikirim itu tidak buta lagi :)
eckes

1
Sebenarnya mengharuskan klien untuk mengirim beberapa pesan jika BCC salah. Sangat bagus untuk mengirim hanya satu pesan. Klien SMTP dapat mendaftar beberapa RCPT TOinstruksi. Satu-satunya persyaratan adalah bahwa server SMTP penerima menjadi server otoritatif untuk kedua penerima, atau bersedia untuk menyampaikan apa pun yang bukan.
Patrick

6

SMTP dan email adalah layanan Internet yang sangat lama dari era ketika keamanan dan otentikasi dianggap kurang serius (DNS adalah contoh lain). Desain protokol tidak berupaya memverifikasi keaslian alamat pengirim, dan hanya memvalidasi alamat penerima sejauh memastikan bahwa email tersebut dapat dikirimkan.

Email ditransmisikan melalui protokol SMTP. Protokol SMTP relatif bodoh; ini menyediakan fasilitas untuk mengirimkan plaintext ke alamat email dan sangat sedikit lagi. Struktur plaintext ini didefinisikan oleh RFC 5322 . Gagasan umum adalah bahwa teks email memiliki metadata yang disebut tajuk, dan badan teks pesan yang sebenarnya. Header email ini dihasilkan oleh pengirim (tidak ada yang bisa dipercaya) dan berisi bidang seperti "ke:", "dari:", "subjek:", dll ...

Protokol SMTP tidak (dan tidak seharusnya) memvalidasi bahwa header email cocok dengan beberapa hal yang didefinisikan dalam protokol SMTP, yang pada dasarnya adalah alamat email Anda dan alamat email pengirim yang tidak pernah divalidasi dengan cara apa pun.

Hampir semua yang ada dalam pesan email bisa palsu.

Satu-satunya hal yang bahkan dapat dipercaya jauh tentang konten email hari ini adalah tanda tangan DKIM, yang membuktikan bahwa email tersebut diproses melalui server email yang disetujui oleh pendaftar domain. Menggali lebih dalam, Anda akan menemukan bahwa email penipuan ini tidak memiliki tanda tangan DKIM.


Saya akan menambahkan Received:header terakhir yang ditambahkan oleh sistem Anda sendiri ke bagian yang dapat dipercaya.
Hagen von Eitzen

3

Alamat Todalam tajuk email adalah untuk tujuan informasi dan ditunjukkan oleh klien email. Alamat penerima sebenarnya diberikan RCPT TOdalam SMTP. Sama halnya jika Anda menulis surat, memasukkan amplop, menuliskan Alamat-1 di amplop. Lalu pergi ke kurir, berikan alamat-2 yang lain. Kurir memasukkan amplop Anda ke dalam amplop yang lebih besar dengan Alamat-2 dan pengirimannya akan ke sana. Sekretaris Anda (perangkat lunak klien email) meletakkan amplop eksternal ke tempat sampah dan menunjukkan kepada Anda amplop internal dengan Address-1. Anda dapat melihat ini dengan tampilan RAW pada pesan email.


2

Ini adalah tampilan yang sedikit berbeda, berdasarkan memeriksa header. Jawaban lain menangani detail SMTP lebih baik daripada yang saya bisa.

Jika Anda bisa mendapatkan tajuk lengkap pesan Anda, lalu cari alamatnya, Anda dapat menemukannya di bidang yang disebut Envelope-to, Delivered-toatau X-Apparently-to. Yang pertama digunakan oleh penyedia surat saya, yang kedua oleh Gmail; Saya telah melihat yang ketiga digunakan juga. Ini adalah bidang yang berbeda tetapi untuk tujuan kami cenderung memiliki arti yang sama: kotak surat untuk mengirimkan pesan. Saya menguji dengan mengirim dari pandangan (versi desktop) dengan penerima BCCed.

Penyedia surat saya juga menggunakan Delivered-Tobidang tetapi untuk nama kotak surat di server mereka. Ini bukan alamat email saya meskipun sepertinya satu (pikirkan ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Outlook (dikombinasikan dengan server pertukaran) di sisi lain tidak termasuk dalam tajuk bidang tunggal dengan alamat email penerima jika Anda terdaftar sebagai BCC.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.