Pemikiran terbuka tentang email generasi kedua

Note: Tulisan ini hanya merangkum pemikiran saya. Ini bukan sesuatu yang sudah saya pikirkan secara mendalam, dan tidak perlu dianggap sebagai ide yang bagus. Sebaiknya baca dengan ekspektasi serendah mungkin.

Masalah email

• Banyak teknologi lama masih digunakan, tetapi email selalu membuat saya kesal setiap kali memakainya.
• Dari sudut pandang pengguna, email bekerja cukup baik. Kadang ada terlalu banyak email karena spam, tetapi email itu tua, andal, mudah dipahami, dan relatif mudah dicari.
• Namun, backend email berantakan.

Masalah pada backend email

• Banyak fitur email tidak memiliki spesifikasi yang jelas. Misalnya, saat mengirim balasan, tidak jelas apakah balasan harus ditempatkan di bagian atas pesan atau di bagian bawah.
• Tidak jelas HTML seperti apa yang boleh dimasukkan ke dalam email. Microsoft Outlook kadang menyalahgunakan renderer HTML Microsoft Word.
• Cara mengenkripsi email juga tidak jelas. Kita menemukan sesuatu yang disebut OpenPGP, tetapi hampir tidak pernah digunakan dan memiliki cacat besar.
• Keaslian email tidak selalu bisa diverifikasi. Karena itu, SPF diciptakan, tetapi SPF juga tidak menyelesaikan semua masalah. Lalu DKIM diciptakan, tetapi DKIM juga tidak menyelesaikan semua masalah. Kemudian DMARC diciptakan, tetapi karena DKIM sendiri punya cacat besar, DMARC pun bisa dilewati.
• Lalu ditambahkan lapisan lain bernama BIMI, yang juga bergantung pada DMARC, dan DMARC bergantung pada DKIM, sementara DKIM memiliki cacat.
• Bahkan ketika DMARC ada, 68.2% rekamannya disetel ke p=none. Ini berarti DMARC pada dasarnya tidak melakukan apa-apa.
• Semua hal di atas, ditambah kebijakan anti-spam yang agresif, membuat self-hosting email menjadi sangat sulit.
• Terakhir, ada pengelolaan reputasi IP. Beberapa alamat IP lebih “bersih” daripada yang lain, terutama pada sistem bersama seperti SendGrid atau AWS SES. Ini membuat pendaftaran akun mail massal menjadi rumit, dan sering kali email yang sah diklasifikasikan sebagai spam.

Hipotesis tentang email generasi kedua

• Buat record DNS baru MX2. Sebagian besar layanan email akan memiliki record MX2 dan MX. Layanan lama hanya akan memiliki MX.
• Jika klien email lama berusia 20 tahun mencoba mengirim pesan, ia akan mencari record MX dan mengirim pesan. Klien modern akan melihat MX2 lalu mengirim pesan.
• Layanan email yang mengimplementasikan MX2 akan memublikasikan tanggal go-live, dan setelah tanggal itu semua pesan yang dikirim ke record MX akan otomatis diklasifikasikan sebagai spam.

Prioritas email generasi kedua

1. Menyediakan spesifikasi HTML yang terstandarisasi untuk email beserta test suite kepatuhannya.
2. Menyediakan header untuk preferensi rantai email atau preferensi lain yang terkait dengan email.
3. Menyediakan salinan teks-only non-HTML bersama tampilan HTML.
4. Semua record MX2 harus menyertakan kunci publik.
5. Membuat hash untuk memverifikasi keaslian dan integritas email, mengenkripsinya, lalu menambahkannya ke header.
6. Menghapus SPF, DKIM, dan DMARC, lalu menstandarkan semuanya pada satu record MX2 untuk menyederhanakan stack email self-hosting.
7. Mengautentikasi email berdasarkan domain, bukan alamat IP.
8. Klien yang mengimplementasikan MX2 dapat memilih skema enkripsi baru yang bisa menggantikan OpenPGP.

Pemikiran tambahan

• Perlu ada cara untuk berbagi file berukuran besar.
• Tanpa keterlibatan Google dan Microsoft, MX2 tidak akan pernah terwujud.
• Mengganti SMTP dengan HTTP serta REST API yang terstandarisasi dan body JSON juga bisa dipertimbangkan.
• Penggunaan HTML itu sendiri bisa menjadi kontroversial. Email sejak awal tidak dirancang untuk HTML.
• Ada peluang untuk menegakkan standar baru secara ketat.

Pendapat GN⁺

• Upaya untuk menyelesaikan kompleksitas dan masalah keamanan sistem email ini sangat menarik. Secara khusus, usulan metode baru untuk menjamin keaslian dan integritas email bisa sangat berguna.
• Namun, memperkenalkan standar baru adalah hal yang sangat sulit. Terutama, partisipasi pemain besar seperti Google dan Microsoft sangat penting.
• Kontroversi soal penggunaan HTML masih tetap ada. Untuk menyelesaikan masalah keamanan, perlu dipertimbangkan bahasa markup lain.
• Menegakkan standar baru secara ketat memang ideal, tetapi secara realistis bisa jadi sulit. Diperlukan mekanisme tambahan untuk mencegah drift standar dan kesalahan implementasi.
• Sentralisasi sistem email mungkin dapat membantu memperkenalkan standar baru, tetapi pada saat yang sama juga dapat meningkatkan ketergantungan pada perusahaan tertentu.

[cometkim]

Setidaknya untuk peningkatan rendering, Google dan Microsoft sudah berinvestasi... karena keduanya ikut serta dan mendukung proyek AMP Email.

[coremaker]

Membuat standar data seperti JSON itu bagus.
Namun, karena spesifikasi rendering juga harus dibahas bersama, sepertinya itu tidak akan mudah.

Bukankah alasan memilih HTML juga
untuk menumpang pada spesifikasi rendering HTML+CSS?

[ldmsys]

Para komentar di atas sudah menyebut Shop Mail sebagai contoh ekstrem. Secara pribadi, saya cukup skeptis terhadap pendekatan yang secara terang-terangan mengklasifikasikan protokol yang sudah berjalan baik sebagai deprecated, lalu membuatnya hanya kompatibel dengan standar protokol baru tertentu yang tidak kompatibel.

[unsure4000]

4. Semua record MX2 harus menyertakan kunci publik.
   Ini yang agak membingungkan, karena sepertinya penyedia layanan akan memakai kunci publik yang mereka buat sendiri, bukan kunci publik yang dikirimkan oleh pengguna...

[iolothebard]

Jadi kami membuat email sisip… (Hah? Bukan itu…)

[xguru]

Sistem email memang nyaman dan bagus, tetapi saya benar-benar merasa bahwa perbaikan protokol yang bertahap memang perlu.
Bahkan beberapa puluh tahun ke depan, rasanya agak... kalau masih terus dipakai dengan cara seperti ini.

[GN⁺]

Komentar Hacker News

Ringkasan kumpulan komentar Hacker News

• Kompleksitas dan interoperabilitas sistem email

  • Berdasarkan pengalaman mengoperasikan layanan email internet, sistem email memang kompleks tetapi diadopsi secara universal dan memiliki interoperabilitas yang sangat baik.
  • Pengenalan sistem baru menghadapi kesulitan karena harus bersaing dengan investasi R&D besar-besaran pada sistem yang sudah ada.
  • Jika ingin mengusulkan sistem email baru, akan lebih baik mengajukannya di tempat seperti IETF atau M3AAWG.

• Ambiguitas dan masalah pada email

  • Kebingungan dapat muncul karena header email memiliki nilai yang duplikat atau saling bertentangan.
  • Ada berbagai masalah, seperti ketika header yang seharusnya hanya menggunakan ASCII malah berisi nilai 8-bit.
  • Cara pengelolaan thread email juga tidak distandardisasi sehingga menimbulkan masalah.

• Masalah sentralisasi email

  • Sentralisasi email tidak diinginkan. Perusahaan besar kemungkinan bertindak dengan arah yang menguntungkan diri mereka sendiri, bukan yang terbaik bagi umat manusia.
  • Self-hosting email tidak sulit, dan dapat di-host dengan mudah melalui penyedia tepercaya.

• Masalah email HTML

  • Email HTML dapat menimbulkan masalah seperti phishing dan penipuan.
  • Jika email didesain ulang, ada pendapat bahwa HTML sebaiknya dikecualikan dan diganti dengan format seperti Markdown.

• Perlunya mempertahankan sifat asinkron email

  • Email harus tetap bersifat asinkron, dan ini merupakan garis pertahanan teknis terakhir untuk mencegah budaya kerja 24 jam.
  • Inilah alasan orang tidak mengadopsi sistem yang dianggap lebih baik.

• Kesulitan mengoperasikan server email

  • Mengoperasikan server email menjadi semakin sulit karena harus memenuhi persyaratan dari penyedia besar.
  • Server kecil semakin tersingkir oleh penyedia besar atau para pengirim spam.

• Definisi email yang sah

  • Definisi email yang sah bersifat subjektif. Spam sedang merusak internet, dan diperlukan cara untuk membebankan biaya guna mencegahnya.

• Perlunya perbaikan sistem email

  • Bahkan jika sistem email didesain ulang, akan lebih baik untuk tetap mempertahankan sistem email saat ini sambil memperbaikinya.
  • Diperlukan penerapan sistem enkripsi modern dan sistem autentikasi pengirim.

• Checklist ide pencegahan spam

  • Diperlukan beberapa penyesuaian implementasi untuk mencegah spam.
  • Mail forwarder dan server SMTP sebaiknya meneruskan email secepat mungkin, dan pemfilteran spam lebih baik ditolak pada level SMTP.

Checklist ide anti-spam