Pemroses pembayaran utama Eropa tidak bisa mengirim email ke pengguna Google Workspace

• Perusahaan pembayaran besar Eropa Viva.com mengirim email verifikasi tanpa header Message-ID, sehingga server Google Workspace menolaknya
• Dalam RFC 5322 (ditetapkan pada 2008), Message-ID ditentukan sebagai header tingkat wajib, dan Google menerapkannya secara ketat
• Email dapat diterima di alamat Gmail pribadi, sehingga terlihat perbedaan penanganan antara Google Workspace dan Gmail
• Dukungan pelanggan Viva.com tidak mengakui adanya masalah teknis, dan hanya mengonfirmasi hasil setelah pengguna menemukan jalan memutar sendiri, menunjukkan respons yang tidak profesional
• Ini adalah contoh kegagalan mematuhi RFC dasar, yang menyoroti penurunan kualitas dan daya saing infrastruktur fintech Eropa

---

Masalah email verifikasi yang tidak sampai

• Dalam proses pembuatan akun Viva.com, email verifikasi sama sekali tidak diterima
  • Digunakan email domain kustom berbasis Google Workspace, dan tidak ada email di folder spam
• Hasil Email Log Search di Google Workspace menunjukkan status “Bounced”
  • Alasan penolakan adalah “Messages missing a valid Message-ID header are not accepted”
  • Google menolak email tersebut karena melanggar spesifikasi RFC 5322
• Email yang dikirim Viva.com tidak memiliki header Message-ID, padahal ini sudah menjadi persyaratan wajib sejak 2008

Solusi sementara

• Setelah diganti ke alamat @gmail.com pribadi, email verifikasi diterima dengan normal
  • Tampaknya infrastruktur penerimaan Gmail lebih longgar atau memprosesnya melalui jalur yang berbeda
• Namun, fakta bahwa untuk mendaftar ke platform pembayaran bisnis harus memakai email pribadi tetap dianggap bermasalah

Tanggapan dukungan pelanggan

• Log Google Workspace dan tangkapan layar penjelasan masalah dikirim ke dukungan pelanggan Viva.com
• Tim dukungan membalas, “akun Anda sudah memiliki email yang terverifikasi, jadi tidak ada masalah”
  • Tidak ada pengakuan atas masalah teknis maupun eskalasi ke tim engineering
  • Mereka menganggap hasil jalan memutar yang dilakukan pengguna sendiri sebagai bukti tidak adanya masalah

Inti masalah

• Message-ID adalah header dasar yang secara default dibuat oleh semua sistem email
  • Jika header ini sampai hilang, berarti pipeline email kemungkinan dikonfigurasi dengan sangat buruk
• Dalam RFC 5322, Message-ID ditetapkan sebagai “SHOULD”, tetapi Google memperlakukannya secara praktis sebagai wajib (MUST)
• Karena Viva.com tidak mematuhinya, email tidak sampai ke pengguna Google Workspace
• Fakta bahwa perusahaan yang memproses pembayaran di seluruh Eropa gagal memenuhi spesifikasi RFC dasar menimbulkan keraguan terhadap keandalan teknisnya

Masalah struktural infrastruktur fintech Eropa

• Dalam API dan layanan perusahaan di Eropa, dokumentasi yang tidak lengkap, penanganan error yang buruk, dan dukungan yang tidak profesional terus berulang
• Ini disebut bukan masalah kemampuan engineer, melainkan kurangnya persaingan pasar dan masalah prioritas
• Stripe telah menetapkan standar tinggi untuk pengalaman developer, tetapi tidak sepenuhnya mendukung jaringan pembayaran regional Eropa (misalnya: IRIS), sehingga pilihan pengganti tetap terbatas
• Selama belum ada pesaing setara Stripe, masalah kualitas seperti ini kemungkinan akan terus berlanjut

Usulan perbaikan teknis

• Viva.com perlu menambahkan header Message-ID pada email keluar
  • Contoh: Message-ID: <[e-mail]>
  • Sebagian besar library email membuatnya secara otomatis, dan masalah ini dapat diselesaikan hanya dengan satu baris perubahan
• Perbaikan segera diperlukan agar pengguna Google Workspace bisa menerima email verifikasi dengan normal

Perbedaan istilah RFC dan kebijakan Google

• Menurut RFC 2119
  • MUST: persyaratan mutlak
  • SHOULD: hanya boleh dihilangkan jika ada alasan khusus
  • MAY: sepenuhnya opsional
• Alasan Message-ID berstatus SHOULD adalah karena sebagian klien mendelegasikannya ke server
• Untuk pencegahan spam, Google menerapkannya sebagai syarat wajib, sehingga berfungsi sebagai standar praktis yang lebih kuat daripada RFC itu sendiri
• Jika Viva.com sengaja menghilangkannya, setidaknya mereka harus memberikan peringatan bahwa “tidak kompatibel dengan Google Workspace”
  • Menjalankannya tanpa pemberitahuan apa pun juga bertentangan dengan semangat ketentuan SHOULD

[GN⁺]

Komentar Hacker News

• Masalahnya disebut terletak pada email verifikasi Viva.com yang tidak memiliki header Message-ID
  Menurut Bagian 3.6 dari RFC 5322, tertulis bahwa “every message SHOULD have a Message-ID field”, tetapi karena SHOULD bukan MUST, muncul pertanyaan apakah ini benar-benar bisa dianggap sebagai ‘persyaratan’

  • Dijelaskan bahwa SHOULD pada praktiknya adalah persyaratan yang nyaris wajib
    Kecuali ada alasan khusus, ini harus diikuti, dan sekadar “malas” tidak bisa menjadi pengecualian
    Dahulu, jika MUA mengirim email tanpa Message-ID, server akan menambahkannya secara otomatis, sehingga ditulis sebagai SHOULD
    Hal ini disebutkan dalam RFC 6409 bagian 8.3
  • Menurut RFC2119, SHOULD berarti “boleh diabaikan dalam situasi tertentu, tetapi konsekuensinya harus dipahami sepenuhnya dan dipertimbangkan dengan hati-hati”
    Tidak jelas bagaimana Google menafsirkan hal ini
  • Sebagai postmaster di perusahaan hosting, seorang komentator menekankan bahwa dalam lingkungan operasional nyata, Message-ID pada dasarnya wajib
    Mungkin masih bisa dimaklumi untuk email uji coba, tetapi jika tidak ada pada email layanan produksi, itu akan menimbulkan masalah pada filter spam dan lainnya
    Tidak adanya Message-ID biasanya merupakan tanda sistem pengiriman kustom yang ceroboh
  • Message-ID memang tidak wajib mutlak, tetapi ada keluhan terhadap layanan seperti Amazon SES yang justru menimpa Message-ID yang sudah ada
  • Secara teknis memang bisa saja tidak ada, tetapi agar diklasifikasikan sebagai email yang normal, pada praktiknya hampir wajib
    Terutama untuk layanan pembayaran, fakta bahwa mereka bahkan tidak menguji ini pada layanan email besar seperti Google Workspace dianggap absurd

• Berdasarkan pengalaman bekerja di ESP (Email Service Provider), disebutkan bahwa sebagian besar software server menolak email tanpa Message-ID
  Sulit dibayangkan ada pihak yang mengabaikan bounce dari penerima besar seperti Google

  • Dalam praktiknya, mencegah masalah pengguna lebih penting daripada berpegang kaku pada standar
    Walaupun sistem lawan tidak rasional, lebih baik menyesuaikan diri demi mencegah ketidaknyamanan pengguna
  • Untuk mengirim email ke Google Workspace, Message-ID pada dasarnya adalah MUST
    Jika tidak mau menyertakannya, seharusnya dinyatakan dengan jelas bahwa “layanan tidak tersedia untuk pengguna Google Workspace”
  • Namun kebanyakan perusahaan tidak peduli pada detail teknis seperti ini, dan hanya berpikir “yang penting layanan cepat jalan”
    Baik Viva maupun Google dianggap terlalu besar sehingga tidak terlalu memedulikan masalah sebagian pelanggan
  • Ada juga yang menunjukkan bahwa karena basisnya banyak perusahaan Eropa, porsi pengguna Google Workspace mungkin tidak terlalu besar

• Ada juga keluhan tentang layanan yang mengirim bagian alternatif text/plain email dengan sangat buruk
  Misalnya versi teks tanpa tautan, atau hanya berisi hal tak berguna seperti “ini adalah email plain text”

  • Versi plain text yang hanya menampilkan “kalimat lucu” di notifikasi dianggap yang paling menyebalkan
    Ada juga gurauan bahwa klien email seharusnya punya fitur AI untuk merangkum HTML
  • Ada layanan yang pernah mengirim informasi reservasi pelanggan lain di bagian plain text (kasus Avis)
  • Ada yang pernah melihat implementasi yang membuat text/plain dengan membuang HTML lewat browser Lynx, dan bertanya-tanya apakah itu benar-benar berguna
  • Ada juga kasus text/plain yang justru berisi source HTML atau CSS mentah

• Ada komentar yang menyindir ketidakmampuan teknis institusi keuangan
  “Major European Payment Processor” disebut pada dasarnya berarti “Major European Incompetence Center”

  • Pengguna lain mengatakan itu terdengar berlebihan, tetapi pada kenyataannya tingkat keamanan institusi keuangan memang mengerikan
    Sebagai contoh, Harland Financial Systems disebut memakai enkripsi XOR 2-byte, dan kuncinya dikirim dalam teks polos di awal koneksi
  • Pengguna lain lagi menyebut kasus korupsi di institusi keuangan AS (persetujuan yang salah, pembukaan rekening tanpa izin, dll.) dan bertanya apakah di Eropa juga mirip

• Seorang pengguna yang pindah dari Gmail ke Fastmail sebagian memahami penyaringan spam yang ketat dari Google
  Di Fastmail, katanya lebih banyak spam dan email phishing yang masuk

  • Pengguna lain mengatakan bahwa Message-ID pada dasarnya adalah standar industri de facto untuk email otomatis, jadi tindakan Google tidak berlebihan
    Ada juga kasus startup memakai template bawaan begitu saja sehingga dianggap phishing
  • Disarankan bahwa filter spam Fastmail akan belajar seiring waktu dan membaik
  • Seorang pengguna Fastmail lama bercanda bahwa kadang ada spam yang lolos, tetapi hanya email LinkedIn yang selalu berhasil masuk
  • Fastmail kadang melambat dalam merespons spam, tetapi secara umum tetap memuaskan

• Ada juga pendapat bahwa meskipun menurut RFC Viva.com memang salah, Google juga tidak pantas menolak email hanya karena item SHOULD
  Jika kemungkinan spam tinggi, seharusnya dimasukkan ke folder spam, dan bukan langsung ditolak

  • Ada yang menyoroti kenyataan bahwa tim dukungan pelanggan sering tidak meneruskan masalah ke tim teknis dan hanya mengulang jawaban formalitas
  • Dari sudut pandang staf support, ada pengalaman internal bahwa jika mereka mengakui masalah, itu bisa berdampak buruk pada evaluasi kinerja mereka
  • Ada juga komentar sinis bahwa standar email pada praktiknya tidak pernah bekerja sempurna, dan semua aturan pada dasarnya setingkat “SHOULD”

• Yang dianggap paling serius adalah Viva.com bahkan tidak pernah menguji masalah pengiriman email ke Google Workspace ini

  • Disindir bahwa sebenarnya mereka sedang melakukan “pengujian real-time” lewat kegagalan pendaftaran pengguna
    Masalahnya mungkin saja karena perubahan di pihak Google, tetapi tidak adanya monitoring dianggap masalah yang lebih besar
  • Ada juga sanggahan, “memangnya semua perusahaan di dunia memakai Google Workspace?”

• Ada yang mempertanyakan sudah berapa lama Viva.com tidak menyadari masalah seperti ini
  Jika memakai software email biasa, seharusnya masalah seperti ini tidak terjadi, sehingga kemungkinan ada misconfiguration
  SHOULD bukan MAY, dan jika tidak diimplementasikan, risikonya memang harus ditanggung
  Fakta bahwa Google memberikan pesan error yang menjelaskan penyebabnya justru dinilai sebagai hal yang patut disyukuri

• Dijelaskan bahwa Message-ID awalnya adalah field wajib yang berasal dari Usenet,
  dan dibutuhkan untuk threading, balasan, serta pengarsipan email
  Tidak adanya Message-ID dianggap berarti “tidak ingin dibalas dan tidak ingin meninggalkan catatan”, sehingga terlihat sebagai perilaku yang mencurigakan

• Menanggapi tulisan asli yang menyoroti masalah kualitas API perusahaan Eropa,
  ada yang mengatakan fenomena ini bukan masalah regional, melainkan pola umum startup dan institusi keuangan di seluruh dunia
  Perusahaan besar sering menganggap API sebagai bisnis sampingan, atau sekadar menjalankannya demi kepatuhan regulasi
  Sebaliknya, perusahaan seperti Stripe memiliki kualitas tinggi karena API adalah nadi bisnis mereka
  Ditambahkan pula bahwa startup, karena kekurangan sumber daya, sering tak punya pilihan selain memprioritaskan “API yang berjalan” daripada “API yang enak dipakai”