Berikut ini adalah beberapa fakta mengenai email yang mungkin belum disadari oleh sebagian pengguna awam, berdasarkan pengamatan pribadi. Daftar ini tidak berurutan.
Reply-To tidak perlu diisi jika sama dengan return address From.
Sepertinya ada anggapan bahwa kalau Reply-To tidak diisi maka orang tidak bisa membalas emailnya. Anggapan ini tidak benar. Reply-To hanya perlu diisi jika alamat email untuk replynya dikehendaki lain dari yang sudah disebutkan di From sebagai return address utama. Tanpa Reply-To program email bisa mendapatkan alamat pengirim dari From.
Menerima dan mengirim email itu terpisah dan tidak berhubungan langsung.
Pada jaman dahulu, email akan dikirim menggunakan protokol SMTP (masih dipakai sekarang) lalu kemudian ditampung dan dibaca langsung di server. Pengguna akan login langsung ke server untuk membaca email di situ. Karena pada jaman tersebut akses internet belum ada atau belum populer. Sampai saat itu belum ada konsep “mengambil” email, pengguna yang harus “datang” untuk membaca email. Setelah ada kebutuhan untuk membuat proses mengakses email lebih fleksibel, maka dibuat protokol seperti POP3 dan IMAP untuk mengambil atau membaca email dari server yang menampung email. Protokol SMTP tidak bisa digunakan karena SMTP membutuhkan lokasi tujuan yang sudah pasti, sedangkan lokasi pengguna seringkali tidak pasti, maka lebih masuk akal jika dibuat protokol seperti POP3 dan IMAP yang tidak mengharuskan kepastian lokasi pengguna, tapi cukup dengan asumsi kepastian lokasi mail server tujuan akhir dari SMTP.
Email tidak dapat diandalkan dan tidak aman.
Infrastruktur email yang umum dipakai tidak mensyaratkan keandalan dan keamanan, dua asumsi salah yang kerap ditemui mengenai email dan pengirimannya. Protokol pengiriman email yang ada dan digunakan saat ini (SMTP) tidak menjamin waktu dan durasi pengiriman email. Bukan tidak mungkin email yang dikirim hari ini ke si A dan si B akan diterima si A dengan segera dan baru akan diterima si B 4 hari kemudian. Walaupun secara etis dan konvensinya, mail server penerima atau relay bertanggung jawab atas pengiriman email hingga ke tujuan, tapi ini hanya best effort dan tidak dijamin. Faktor keamanan juga tidak dijamin kerahasiaannya, integritas pesannya, keabsahan identitas pengirim dan penerimanya, dan kebebasan isinya dari materi berbahaya atau yang tidak diinginkan seperti virus, spam, phishing scam, dan lain-lainnya. Walaupun sudah mulai ada yang mengimplementasikan perbaikan terhadap infrastruktur yang ada, tapi kenyataannya sekarang masih banyak yang belum. Jadi sekarang ini masih belum aman untuk berasumsi bahwa email itu reliable dan aman.
Email tidak dirancang untuk mengirimkan files.
Seperti namanya, email itu tujuan utamanya adalah berkirim pesan. Pada awalnya pesan yang berupa teks saja. Namun kemudian ada kebutuhan untuk melampirkan berbagai file ke email, sehingga dicari akal untuk melakukan hal itu, seperti menggunakan uuencode/uudecode, dan MIME. MIME ini yang sekarang menjadi standard untuk mengirimkan lampiran melalui email. Infrastruktur email dari awal berasumsi bahwa pesan itu berupa teks dan berasumsi juga bahwa pesannya hanya dalam character set ASCII yang bisa direpresentasikan dengan 7-bit encoding. Karena itu untuk mengirimkan file yang bukan teks (seperti gambar, spreadsheet, zip) harus diakali untuk bisa direpresentasikan ke 7-bit, misalnya dengan menggunakan encoding base64 atau quoted-printable. Salah satu efek samping yang paling signifikan adalah bahwa ukurannya akan menjadi lebih besar. Secara rata-rata base64 membutuhkan 4 bit untuk merepresentasikan 3 bit, jadi kurang lebih ada penambahan sekitar 33% dari aslinya. Untuk mengirimkan file 5 MB akan ada overhead sebesar sekitar 1.65 MB sehingga total akan menjadi 6.65 MB. Atau jika digunakan pengandaian kasar begini, kita membayar akses internet 300 ribu per bulan hanya untuk mengirim email saja dan semua emailnya memiliki lampiran yang menggunakan encoding base64, dan akses internetnya dicharge berdasarkan bytes yang lewat (bukan berdasarkan waktu), maka dari 300 ribu itu hampir sekitar 75 ribu-nya hanya untuk membayar overhead tersebut.
Fungsi “compose” itu untuk menulis email baru, fungsi “reply” itu untuk melanjutkan percakapan atau topik yang sudah dibahas sebelumnya.
Fungsi “reply” akan menyertakan referensi ke pesan yang dibalas, sedangkan “compose” memulai pesan dari kosong. Penyertaan referensi ini ada di header “In-Reply-To” dan/atau “References”, bukan sekedar di subject saja.
Hal ini benar-benar dirasakan efeknya terutama di lingkungan mailing list, dan terutama untuk orang (atau program) yang sangat tergantung kepada fungsi threading yang mengelompokkan pembicaraan per topik dengan alur hirarki yang jelas dan mudah diikuti, pesan mana yang mengacu atau membalas ke pesan mana. Fenomena ini kerap dikenal dengan istilah thread hijacking, atau menumpang di thread lain padahal topiknya tidak berhubungan.
Sepertinya fenomena ini disebabkan kemalasan untuk mengetikkan alamat email penerima dan/atau ketidaktahuan akan cara menggunakan fungsi “address book”.
