Validasi alamat email: yang bisa dan tak bisa dibuktikan regex

Empat pertanyaan yang berbagi satu kata

“Apakah ini alamat email yang valid?” bukan satu pertanyaan. Ini empat pertanyaan, tingkat kesulitannya makin naik, dan yang terakhir satu-satunya yang sebenarnya ingin dijawab semua orang — itulah sebabnya begitu banyak kode validasi yang rumit soal yang pertama dan diam soal sisanya.

Berikut keempatnya, dalam urutan sebuah formulir pendaftaran menemuinya.

Apakah bentuknya seperti sebuah alamat?

Sebuah pemeriksaan sintaks. Ia berjalan di browser, tidak berbiaya apa pun, dan menangkap koma yang salah ketik serta @ yang hilang. Ini satu-satunya lapisan yang jujur bisa menolak sesuatu dengan sendirinya — dan bahkan begitu, ia seharusnya menolak jauh lebih sedikit daripada kebanyakan pola.

Bisakah domain itu menerima surat sama sekali?

Sebuah pemeriksaan DNS. Satu query mengatakan apakah ada apa pun, di mana pun, yang bersedia menerima surat untuk bagian setelah @. Ia menangkap nama domain dengan satu huruf hilang dan domain yang sudah kedaluwarsa tahun lalu, dan ia sama sekali tidak bisa memberi tahu apa pun soal kotak suratnya.

Apakah kotak surat itu ada?

Sebuah pemeriksaan SMTP — dan yang paling lama dibahas panduan ini soal mengapa Anda tidak boleh mempercayainya. Anda bisa bertanya. Jawabannya sering kali sebuah ya yang sopan dari sebuah server yang menerima nama apa pun, atau sebuah kegagalan sementara yang disengaja, atau sebuah penerimaan yang diikuti sebuah bounce beberapa menit kemudian.

Apakah itu alamat mereka?

Tidak ada apa pun di sisi teknis yang bisa menjawab ini. Sebuah alamat bisa sempurna, bisa dikirimi surat, dan milik orang lain — salah ketik satu digit, atau diketik dengan sengaja supaya lolos dari Anda. Cuma sebuah pesan yang tiba dan dipakai yang menutup pertanyaan ini.

Tiga yang pertama murah dan cuma membuktikan sedikit. Yang keempat satu-satunya yang pantas menyandang namanya, dan itulah yang berbiaya sebuah pesan. Semua yang ada di bawah ini soal memakai yang tiga murah itu dengan baik supaya yang mahal tidak terbuang percuma.

Lapisan satu: pola, dan empat hal yang tidak bisa diketahuinya

Tidak ada ekspresi reguler resmi untuk sebuah alamat email, dan memang tidak bisa ada. RFC 5322 mendefinisikan sebuah gramatika, bukan sebuah pola, dan gramatika itu mengizinkan komentar dalam tanda kurung, spasi yang terlipat, dan string bertanda kutip yang bisa berisi hampir semua karakter — tidak satu pun dari itu yang seharusnya diterima formulir pendaftaran sungguhan, dan semuanya harus diterima sebuah pola yang setia pada standar.

Yang memang ada adalah sebuah definisi yang sengaja dibuat lebih sempit dan sudah diterapkan browser: yang diberikan spesifikasi HTML untuk sebuah field <input type="email">. Ini sebuah kompromi yang disengaja, bukan sebuah transkripsi dari standarnya, ini yang sudah dipegang formulir Anda bahkan sebelum satu baris kode Anda berjalan, dan ini cukup pendek untuk dibaca sekali baca:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Pakai itu, atau pakai yang sudah dibawa platform Anda. Keempat yang di bawah ini adalah lapisan yang sama, dan memilih salah satunya adalah keputusan yang lebih kecil daripada apa yang Anda lakukan sesudahnya:

Apa pun yang Anda pakai, yang penting adalah apa yang tidak dikatakannya. Sebuah pola yang mengembalikan true sudah memberi tahu Anda satu hal dan empat bukan-hal.

Bukan bahwa domainnya ada

Sebuah alamat pada domain yang belum pernah didaftarkan siapa pun lolos dari setiap pola di bagian ini. Tidak ada apa pun yang dicari dan tidak ada apa pun yang dihubungi; tidak ada ekspresi reguler yang pernah membuat sebuah permintaan jaringan.

Bukan bahwa kotak suratnya ada

Bahkan pada domain yang sungguhan, polanya tidak punya pendapat soal bagian sebelum @. Bagian itu cuma milik server penerima, dan itu justru hal yang tidak akan pernah diberitahukan DNS kepada Anda.

Bukan bahwa alamatnya bisa dikirimi surat

Sebuah domain bisa punya record yang sempurna dan sebuah server surat yang sudah dimatikan selama sebulan. Sintaks adalah sifat sebuah string; keterkiriman adalah sifat dunia pada saat Anda menekan kirim.

Bukan bahwa itu milik orang yang mengetiknya

Alamat buruk paling umum di database mana pun adalah alamat yang sungguhan dan bisa dikirimi surat, milik seseorang yang tidak pernah mendaftar — karena satu huruf salah ketik, atau karena formulirnya diisi dengan sebuah kebohongan yang terlihat masuk akal.

Apa yang legal, dan apa yang salah dibuang

Kebanyakan bug validasi bukan alamat buruk yang berhasil masuk. Itu adalah orang-orang yang tidak bisa mendaftar, dan mereka tidak pernah muncul di log yang dibaca siapa pun — formulirnya bilang tidak, dan mereka pergi ke tempat lain. Keenam hal ini yang paling sering melakukannya.

Dan tiga angka, yang layak ditulis langsung ke dalam kode Anda karena tidak pernah berubah:

64 karakter

Jumlah maksimum bagian sebelum @. Apa pun yang lebih panjang bukan alamat yang panjang, itu bukan alamat.

255 karakter

Jumlah maksimum domainnya, termasuk titik-titiknya. Belum pernah ada yang sah mendekati angka ini, dan batas ini ada terutama supaya Anda punya satu batas untuk dipakai.

254 karakter

Jumlah maksimum seluruh alamat saat dibawa sebuah server — yang lebih kecil daripada jumlah dua angka di atas kalau dijumlahkan. Inilah angka yang harus dipakai di kolom database dan di maxlength field-nya.

Lapisan dua: satu pencarian, dan apa yang dipastikannya

Bagian setelah @ adalah sebuah domain, dan sebuah domain entah punya tempat untuk menaruh surat atau tidak. Satu query DNS menjawab itu dalam beberapa milidetik, dan itulah pemeriksaan bernilai paling tinggi di seluruh panduan ini — karena kesalahan yang ditangkapnya, sebuah nama domain yang diketik sedikit salah, dengan jarak yang jauh adalah kegagalan sungguhan paling umum yang ada.

$ dig +short MX example.com

Sebuah jawaban berarti sebuah host sudah disebutkan namanya. Tidak ada jawaban bukan berarti tidak ada surat: sebuah domain tanpa record MX tapi punya record A tetap menerima, karena pengirim jatuh ke situ sebagai cadangan. Ada empat kemungkinan hasil, dan cuma dua yang merupakan kegagalan.

Tempat pemeriksaan ini biasanya salah bukan pada pencariannya. Melainkan pada di mana pencarian itu diletakkan — di jalur kritis, per ketukan tombol, dengan sebuah kegagalan yang memblokir submit-nya. Enam aturan menjaganya tetap berguna:

1. Jalankan saat field-nya sudah selesai diisi, bukan selagi sedang diketik. Satu query saat fokusnya pindah, atau satu saat submit. Satu query per ketukan tombol ya tetap satu query per ketukan tombol.
2. Ubah domainnya ke huruf kecil dulu. DNS tidak peduli tapi cache Anda peduli: dua ejaan dari domain yang sama adalah satu query, bukan dua.
3. Minta MX, dan jatuh ke A sebagai cadangan. Dua query, dan cuma yang kedua yang bersyarat. Sebuah library yang cuma memeriksa MX saja akan menolak domain yang sebenarnya berfungsi.
4. Simpan jawabannya di cache selama beberapa menit. Segelintir domain menyumbang kebanyakan pendaftaran di mana pun, jadi kebanyakan pencarian berubah menjadi tanpa pencarian sama sekali.
5. Kalau ragu, terima. Kalau resolvernya time out, terima saja alamatnya. Semenit buruk di penyedia DNS Anda tidak boleh pernah berubah menjadi formulir yang menolak semua orang.
6. Sarankan sebuah koreksi; jangan pernah menerapkannya sendiri. Kalau domainnya cuma satu huruf beda dari yang umum, tawarkan koreksinya sebagai sesuatu yang bisa diklik. Diam-diam menulis ulang apa yang diketik seseorang adalah cara sebuah tautan konfirmasi berakhir ke orang asing.

Pencarian ini punya satu biaya yang layak diketahui: inilah saat pertama formulir Anda berbicara ke dunia luar soal sesuatu yang diketik pengunjung. Kalau itu penting, alternatifnya adalah melewati lapisan ini sepenuhnya dan biarkan pesannya sendiri yang menjadi keseluruhan pemeriksaan.

Lapisan tiga: bertanya ke server, dan mengapa jawabannya bukan jawaban

Ada sebuah cara untuk bertanya ke sebuah server surat apakah ia akan menerima sebuah alamat tertentu tanpa mengirim apa pun kepadanya. Buka percakapannya, sebutkan nama pengirim, sebutkan nama penerima, baca balasan untuk satu perintah itu, lalu tutup sebelum pesannya:

220 mx1.example.com ESMTP ready
EHLO checker.example.net
250 mx1.example.com
MAIL FROM:<probe@example.net>
250 2.1.0 Ok
RCPT TO:<someone@example.com>
250 2.1.5 Ok
QUIT
221 2.0.0 Bye

250 setelah RCPT TO itulah yang pada akhirnya dijual setiap layanan verifikasi alamat di dunia ini. Ada gunanya bersikap tepat soal betapa kecil nilainya itu.

Sebuah domain catch-all menjawab ya untuk segalanya

Sebuah domain yang dikonfigurasi untuk menerima nama apa pun — yang persis dilakukan layanan ini, dan yang dilakukan sangat banyak domain perusahaan — membalas 250 untuk sebuah alamat yang belum pernah dipakai siapa pun. Jawabannya benar, dan itu bukan informasi.

Sebuah server yang berhati-hati sengaja menjawab 450

Greylisting menolak percobaan pertama dari sebuah pengirim yang tidak dikenal dan memintanya kembali lagi sebentar lagi. Pengirim sungguhan akan kembali; sebuah penguji tidak akan pernah kembali. Kegagalan sementara itu adalah sebuah bukan-jawaban yang disengaja, dan membacanya sebagai “tidak ada kotak surat seperti itu” persis kesalahan yang memang dirancang untuk dihasilkannya.

Sebagian server menerima dulu dan menolak belakangan

Penyedia besar rutin mengambil pesannya selama percakapan dan memutuskan soal itu belakangan, yang mengubah sebuah penolakan menjadi sebuah bounce yang tiba beberapa menit setelah pengujian Anda kembali dengan hasil bersih.

Sebagian server menjawab tidak kepada semua orang yang tidak mereka kenali

Sebuah server yang sudah memutuskan alamat Anda adalah orang asing bisa menolak penerimanya karena alasan yang sama sekali tidak berhubungan dengan si penerima. Yang Anda ukur adalah reputasi Anda sendiri, bukan kotak surat mereka.

Dan itu menghabiskan reputasi yang sedang Anda lindungi

Sebuah koneksi yang menyebutkan nama-nama penerima dan tidak pernah mengirim apa pun persis berbentuk sebuah directory harvest, karena memang itulah wujudnya. Melakukannya dalam jumlah besar dari alamat Anda sendiri adalah jalan tercepat menuju sebuah blocklist — dan sebuah pengirim yang masuk blocklist adalah pengirim yang pesan-pesan aslinya berhenti sampai.

Ada satu kasus sempit ketika pengujian ini sungguh-sungguh berguna: satu alamat saja, diperiksa dengan tangan, pada sebuah domain yang Anda jalankan sendiri atau punya izin untuk diutak-atik. Sebagai sebuah langkah di dalam formulir pendaftaran, ini lambat, sering salah, dan kadang-kadang malah merugikan justru hal yang seharusnya dilindunginya.

Alamat peran, domain buangan, dan daftar yang akan Anda beli

Di antara pencarian domain dan pesan sungguhan itu ada sekeluarga pemeriksaan yang sama sekali bukan soal validitas. Itu soal apakah Anda menginginkan alamat ini, yang merupakan sebuah keputusan bisnis yang memakai kostum teknis — dan layak dipisahkan dari tiga lapisan di sekitarnya justru karena alasan itu.

Alamat peran

Nama-nama seperti info@, support@ dan admin@. Itu sungguhan, dan biasanya sebuah kotak surat bersama, bukan seseorang, yang membuatnya rumah yang buruk untuk apa pun yang di baliknya ada sebuah kata sandi. Layak ditandai. Jarang layak ditolak.

Domain sekali pakai

Alamat seperti yang dibagikan situs ini, pada domain-domain yang memang ada supaya bisa dibuang. Memeriksa terhadap sebuah daftar publik domain-domain itu cukup wajar, selama Anda jujur bahwa setiap daftar semacam itu tidak lengkap dan sedikit usang pada hari Anda mengunduhnya.

Alamat dari penyedia gratis

Sebagian formulir bisnis menolak apa pun yang bukan domain perusahaan. Itu sebuah kebijakan, kadang itu kebijakan yang tepat, dan itu layak dituliskan sebagai sebuah kebijakan — sebuah kalimat yang bisa dibaca pengunjung — bukan disembunyikan di dalam sesuatu yang disebut validasi.

Domain populer yang salah ketik tipis

Nama sebuah penyedia yang terkenal dengan satu huruf salah. Yang ini berbeda dari tiga lainnya: ini bukan sebuah kebijakan, ini menangkap sebuah kesalahan sungguhan, dan orangnya selalu senang. Ini satu-satunya entri di sini yang layak dibangun.

Tiga yang pertama berbagi satu sifat yang membuatnya sulit dinilai: Anda bisa mengukur apa yang mereka loloskan dan Anda tidak bisa mengukur apa yang mereka korbankan.

Kami jelas punya kepentingan di sini, jadi berikut versi jujurnya. Kalau yang ada di balik formulir Anda adalah sebuah uji coba gratis dengan sesuatu yang mahal menyertainya, menolak domain buangan akan menghemat uang Anda dan Anda memang sebaiknya melakukannya. Kalau itu sebuah newsletter, sebuah unduhan, atau sebuah akun yang dibayar seseorang, Anda kebanyakan cuma membebani orang yang berhati-hati — dan orang yang berhati-hati itulah yang membaca apa yang Anda kirim.

Lapisan empat: pesan yang menjadi pemeriksaannya

Semua yang di atas mempersempit lapangan. Tidak satu pun darinya memastikan satu-satunya fakta yang penting — bahwa alamat ini sampai ke orang yang ada di depan Anda — dan cuma satu hal yang melakukannya: kirim sesuatu ke sana, dan lihat apakah itu dipakai.

Inilah putaran yang sudah dimiliki nyaris setiap pendaftaran dan diperlakukan sebagai formalitas belaka oleh separuhnya:

1. Terima alamatnya lewat satu pemeriksaan yang longgar. Pola di browser, dan tidak ada apa pun lagi yang berdiri di antara pengunjung dan tombolnya.
2. Buat akunnya dalam keadaan belum diverifikasi. Bukan sebuah penahanan pada formulirnya, bukan sebuah layar “pending”: orangnya sudah masuk, dan yang belum bisa dilakukannya cuma segelintir hal yang memang membutuhkan alamatnya.
3. Kirim satu pesan berisi sebuah tautan atau kode sekali pakai. Satu saja, dengan masa berlaku, terikat pada akun dan alamat itu dan tidak ada yang lain.
4. Biarkan tautannya menjadi buktinya. Sebuah klik, atau sebuah kode yang diketik kembali, adalah keseluruhan verifikasinya. Tidak ada apa pun lagi di panduan ini yang menghasilkan jawaban sekokoh itu.
5. Beri mereka jalan kembali. Sebuah “kirim ulang” yang terlihat jelas, dan sebuah cara untuk mengubah alamatnya tanpa kehilangan akunnya — karena alasan paling umum sebuah tautan tidak pernah diklik adalah sebuah salah ketik yang akhirnya kini bisa dilihat orangnya sendiri.
6. Kedaluwarsakan yang tidak pernah dikonfirmasi siapa pun. Sebuah pembersihan diam-diam setelah jangka waktu tertentu mencegah salah ketik dan alamat buangan menumpuk menjadi sebuah daftar yang tidak dipercaya siapa pun.

Itu menciptakan sebuah masalah praktis, dan itulah alasan situs ini ada. Putaran itu kini jalur paling penting di dalam produknya, dan mengujinya berarti menerima surat sungguhan di sebuah alamat yang Anda kendalikan — berulang-ulang, di dalam sebuah pipeline, tanpa seorang manusia pun yang membuka sebuah kotak masuk.

Sebuah alamat pada salah satu domain publik tidak butuh pendaftaran dan tidak butuh kunci, dan apa pun yang tiba di sana bisa dibaca lewat HTTP sedetik kemudian:

$ curl -sG https://grabmail.io/api/v1/mailbox \
  --data-urlencode "address=signup-42@grabmail.io"

Dari situ, seluruh alur verifikasi bisa dijalankan dari ujung ke ujung oleh sebuah test suite, atau sebuah domain milik Anda sendiri bisa diarahkan ke sini supaya setiap run mendapat sebuah alamat yang belum pernah ada sebelumnya. Pesan disimpan selama 5 hari lalu dihapus, yang merupakan masa hidup yang tepat untuk sebuah test fixture dan yang salah untuk sebuah kotak surat.

Apa yang sebenarnya harus dipasang di formulir

Diringkas, dalam urutan kode itu berjalan:

1. Trim, dan cuma trim. Spasi di salah satu ujungnya adalah bekas copy-paste dan tidak pernah disengaja. Tidak ada lagi apa pun soal string itu yang boleh Anda ubah.
2. Cocokkan dengan satu pola yang longgar. Milik browser, atau milik platform Anda. Tolak @ yang hilang dan koma yang salah ketik, dan jangan tolak apa pun yang lain.
3. Batasi panjangnya sampai 254. Satu angka, di kolom database dan di field-nya, dan satu kelas input penuh yang bisa berhenti Anda pikirkan.
4. Cari domainnya, di luar jalur kritis, dan tetap terima kalau gagal. MX lalu A, disimpan di cache, dan tidak pernah menjadi alasan untuk memblokir sebuah submit yang sebenarnya akan berhasil.
5. Tawarkan sebuah koreksi; jangan buat sendiri. Satu huruf beda dari domain yang umum adalah sebuah pertanyaan untuk ditanyakan, bukan sebuah temuan untuk ditindaklanjuti.
6. Kirim pesannya. Itulah validasinya. Semua yang di atasnya cuma triase.
7. Katakan apa yang salah, dengan kata-kata. Inilah bagian yang menentukan apakah ada yang benar-benar menyelesaikannya:

Perhatikan berapa banyak baris yang mengatakan hal salah yang sama. “Masukkan alamat email yang valid” adalah default di mana-mana karena itu benar untuk setiap kasus dan berguna untuk tidak satu pun darinya: di tiga dari lima baris alamatnya memang valid, dan orang yang mengetiknya tidak punya cara untuk mengetahui ia ada di baris yang mana.

Versi singkatnya

1. Trim string-nya. Jangan ubah apa pun lagi soal itu.
2. Cocokkan dengan satu pola yang longgar — milik browser atau milik platform Anda — dan berhenti di situ. Jangan tulis pola sendiri.
3. Tolak apa pun di atas 254 karakter, dan simpan sebuah kolom seukuran itu.
4. Cari MX untuk domainnya, jatuh ke A sebagai cadangan, simpan di cache, lakukan di luar jalur kritis, dan terima alamatnya kalau pencariannya gagal.
5. Tolak sebuah domain yang tidak me-resolve dan sebuah domain yang mempublikasikan null MX. Terima apa pun yang lain yang diberikan DNS kepada Anda.
6. Tawarkan sebuah saran ejaan kalau domainnya salah ketik tipis. Jangan pernah menerapkannya sendiri.
7. Putuskan secara terpisah, dan secara tertulis, apakah Anda memblokir alamat buangan atau alamat peran — dan mengapa.
8. Kirim sebuah pesan dengan tautan sekali pakai, perlakukan kliknya sebagai verifikasi, dan permudah mengirim ulang serta mengoreksi alamatnya.
9. Uji putaran itu terhadap sebuah kotak masuk sungguhan, termasuk jalur-jalur ketika itu gagal, dan hapus akun yang belum dikonfirmasi sesuai jadwal.

Sembilan baris, dan cuma dua yang terakhir yang benar-benar memastikan sesuatu. Tujuh lainnya ada supaya pesan di ujung semua itu layak dikirim.

Pertanyaan