Saya bertanya-tanya seberapa jauh orang harus mengambil validasi alamat email. Bidang saya terutama pengembangan web, tetapi ini berlaku di mana saja.

Saya telah melihat beberapa pendekatan:

• cukup memeriksa apakah ada "@" hadiah, yang mati sederhana tetapi tentu saja tidak dapat diandalkan.
• tes regex yang lebih kompleks untuk format email standar
• sebuah regex penuh terhadap RFC 2822 - masalah dengan hal ini adalah bahwa sering alamat e-mail mungkin berlaku tetapi mungkin tidak apa berarti pengguna
• Validasi DNS
• Validasi SMTP

Seperti yang mungkin diketahui banyak orang (tetapi banyak yang tidak), alamat email dapat memiliki banyak variasi aneh yang biasanya tidak dipertimbangkan oleh kebanyakan orang (lihat RFC 2822 3.4.1 ), tetapi Anda harus memikirkan tujuan dari validasi Anda: apakah Anda hanya mencoba untuk memastikan bahwa pesan email dapat dikirim ke alamat, atau bahwa itulah yang mungkin dimaksudkan pengguna untuk dimasukkan (yang tidak mungkin dalam banyak kasus yang lebih tidak jelas dari yang sebaliknya 'valid ' alamat).

Sebuah opsi yang saya pertimbangkan hanyalah memberikan peringatan dengan alamat yang lebih esoteris tetapi masih memungkinkan permintaan untuk melewatinya, tetapi ini menambah kerumitan pada formulir dan sebagian besar pengguna cenderung bingung.

Sementara validasi DNS / validasi SMTP tampak seperti bukan-otak, saya meramalkan masalah di mana server DNS / SMTP server untuk sementara turun dan pengguna tidak dapat mendaftar di suatu tempat, atau server SMTP pengguna tidak mendukung fitur yang diperlukan.

Bagaimana mungkin beberapa pengembang berpengalaman di sini menangani ini? Apakah ada pendekatan lain selain yang saya daftarkan?

Sunting: Saya benar-benar lupa yang paling jelas dari semuanya, mengirim email konfirmasi! Terima kasih kepada para penjawab karena menunjukkannya. Ya, yang satu ini sangat mudah, tetapi itu memang membutuhkan kerepotan tambahan dari semua orang yang terlibat. Pengguna harus mengambil beberapa email, dan pengembang perlu mengingat data pengguna sebelum mereka bahkan dikonfirmasi sebagai valid.

Tidak ada cara yang dapat diandalkan 100% untuk mengkonfirmasi alamat email yang valid selain mengirim email ke pengguna dan dan menunggu jawaban, seperti kebanyakan forum.

Saya akan pergi dengan aturan validasi "@" sederhana dan kemudian mengirim email kepada pengguna untuk mengonfirmasi alamat email mereka.

Meskipun, ini adalah pendapat pribadi saya ... Saya menunggu saran lain.

Satu saran: jangan menolak alamat dengan tanda + di dalamnya. Sangat umum untuk menolaknya, tetapi ini adalah karakter yang valid, dan pengguna gmail dapat menggunakan address+label@gmail.com untuk memberi label dan mengurutkan surat masuk dengan lebih mudah.

Dalam posting Anda sepertinya ketika Anda mengatakan "validasi SMTP" yang Anda maksud terhubung ke server dan mencoba RCPT TO untuk melihat apakah itu diterima. Karena Anda membedakannya dari benar-benar mengirim email konfirmasi, saya menganggap Anda ingin melakukannya sejalan dengan tindakan pengguna. Selain masalah seperti masalah jaringan, kegagalan DNS, dll, daftar abu-abu dapat mendatangkan malapetaka dengan metode ini. Metode berbeda-beda, tetapi pada dasarnya daftar abu-abu selalu menentang upaya pertama untuk mengirim ke penerima per IP yang terhubung. Seperti yang saya katakan, ini dapat bervariasi, beberapa host mungkin menolak alamat yang tidak valid pada upaya pertama dan hanya menunda alamat yang valid, tetapi tidak ada cara yang dapat diandalkan untuk memilah implementasi yang berbeda secara terprogram.

Satu-satunya cara Anda akan pernah yakin bahwa alamat itu valid dan dikirimkan oleh pemiliknya yang benar-benar ingin menggunakannya untuk aplikasi Anda adalah dengan mengirim email verifikasi. Yah, selama itu tidak disaring spam kurasa =).

Kelemahan lain dari menggunakan regex untuk validasi email adalah hampir tidak mungkin untuk menangkap semua domain tingkat atas yang valid sambil menolak semua yang tidak valid.

Misalnya, regex email dasar dalam balasan Jeff Atwood:

\ b [A-Z0-9 ._% + -] + @ [A-Z0-9 .-] +. [AZ] {2,4} \ b

akan menerima TLD dari dua hingga empat karakter. Jadi, misalnya, .spam akan diterima, tetapi .museum dan .travel (keduanya TLD yang valid) akan ditolak.

Hanya satu alasan lagi lebih baik mencari @, dan mengirim email konfirmasi.

Dengan nama domain internasional, hampir semuanya mungkin:

• Håkan.Söderström@malmö.se
• punnycode@XN--0ZWM56D.XN--HGBK6AJ7F53BBA
• 试 @ 例子. 测试 .مثال.آزمایشی

Jika Anda ingin melakukan tes apa pun, Anda harus terlebih dahulu mengubahnya menjadi punycode.

Tanpa punycode yang harus Anda lakukan adalah mengujinya di sana:

• setidaknya satu @
• setidaknya satu karakter di bagian lokal
• setidaknya satu titik di bagian domain
• setidaknya empat karakter dalam domain (dengan asumsi bahwa tidak ada yang memiliki alamat di tld, bahwa tld setidaknya 2 karakter)

function isEmail(address) {
    var pos = address.lastIndexOf("@");
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}

Anda sebaiknya memeriksa hal-hal sederhana seperti @ dan. dalam JavaScript, dan kemudian benar-benar mengirim mereka verifikasi ke email mereka. Jika mereka memverifikasi akun mereka, Anda memiliki sendiri alamat email yang valid. Dengan begitu Anda tahu pasti bahwa Anda memiliki alamat kantor, dan Anda tidak harus terlalu suka memerintah.

Gunakan validator sumber terbuka yang tidak memberikan negatif palsu. Tanpa upaya untuk Anda dan validasi yang kuat untuk aplikasi Anda.

Saya sekarang telah mengumpulkan test case dari Cal Henderson, Dave Child, Phil Haack, Doug Lovell dan RFC 3696. 158 alamat tes di semua.

Saya menjalankan semua tes ini terhadap semua validator yang dapat saya temukan. Perbandingannya ada di sini: http://www.dominicsayers.com/isemail

Saya akan mencoba menjaga halaman ini tetap mutakhir karena orang-orang meningkatkan validator mereka. Terima kasih kepada Cal, Dave dan Phil atas bantuan dan kerja sama mereka dalam menyusun tes-tes ini dan kritik membangun dari validator saya sendiri .

Orang harus menyadari errata terhadap RFC 3696 pada khususnya. Tiga dari contoh kanonik sebenarnya adalah alamat yang tidak valid. Dan panjang maksimal alamat adalah 254 atau 256 karakter, bukan 320.

Berdasarkan pertimbangan dari jawaban (karena saya benar-benar lupa tentang konfirmasi email) menurut saya sepertinya kompromi yang cocok untuk solusi low-friction adalah dengan:

1. Gunakan regex untuk memeriksa bahwa alamat email terlihat valid, dan beri peringatan jika lebih tidak jelas tetapi jangan langsung menolak.
2. Gunakan validasi SMTP untuk memastikan bahwa alamat email itu valid.
3. Jika validasi SMTP gagal - dan hanya kemudian - gunakan email konfirmasi sebagai upaya terakhir. E-mail konfirmasi tampaknya membutuhkan terlalu banyak interaksi di luar aplikasi Anda sehingga tidak bisa dianggap sebagai gesekan rendah, tetapi mereka adalah mundur sempurna.

RegexBuddy menawarkan ekspresi reguler terkait-email berikut dari perpustakaannya:

Alamat email (dasar)

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

Alamat email (RFC 2822, disederhanakan)

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

Tetapi saya cenderung setuju dengan tanggapan Peter dan SuperJoe; satu-satunya "pengujian" sebenarnya mengirim email validasi.

Saya pernah bekerja di 4 perusahaan berbeda di mana seseorang di meja bantuan dimaki oleh seseorang bernama O'Malley atau O'Brien atau alamat email lain dengan tanda kutip. Seperti yang disarankan sebelumnya, tidak semua regex akan menangkap semuanya, tetapi menyelamatkan diri Anda dari kerumitan dan menerima tanda kutip tanpa menghasilkan peringatan.

-
bmb

Anda dapat mengambil validasi email lebih jauh untuk benar-benar menguji apakah ada kotak surat. Teknik ini memiliki kelemahan (waktu pengembangan dan juga kemungkinan mendapatkan daftar hitam untuk disalahgunakan). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Jika Anda ingin memverifikasi email (yaitu memastikan, bahwa pengguna memiliki alamat email), konfirmasi email adalah satu-satunya hal yang dapat Anda lakukan. Kemudian lagi banyak orang mendedikasikan alamat spam atau menggunakan layanan seperti OneWayMail dan jika mereka tidak ingin memberi Anda alamat email mereka yang sebenarnya, mereka tidak mau. Jadi pada dasarnya Anda membuat halangan pengguna.

Ketika datang ke validasi , untuk memastikan, bahwa pengguna tidak sengaja memasukkan alamat email yang salah, itu pasti motivasi yang tepat. Namun, setidaknya untuk formulir HTML (yang sejauh ini merupakan cara paling umum untuk mengumpulkan alamat email), ini bukanlah instrumen yang tepat.

Untuk satu, Anda tidak akan dapat mengenali kesalahan ketik di "kata" sebenarnya dari alamat email. Anda tidak memiliki cara untuk menemukan yang back2dso@example.comsalah, hanya berdasarkan format.
Tetapi yang lebih penting, dari sudut pandang pengguna, hanya ada satu (atau satu tangan penuh) alamat email yang mungkin ingin Anda masukkan. Dan Anda mungkin sudah memasukinya.
Jadi, daripada mencoba memvalidasi alamat, Anda harus fokus memastikan, bahwa semua browser mengenali bidang email dan dengan demikian menghilangkan kebutuhan untuk mengetikkan alamat email di tempat pertama. Tentu saja ini tidak berlaku, jika Anda sedang membangun jenis situs yang kemungkinan akan dihantam oleh pengguna yang tidak pernah memasukkan alamat email mereka ke browser mereka sebelumnya. Tapi saya kira paling tidak dari kita berada dalam posisi seperti itu.

Saya pikir itu tergantung pada konteks apa Anda menggunakan email. Proyek yang lebih serius memerlukan validasi yang lebih ketat, tetapi saya pikir untuk sebagian besar hal mengirim email ke alamat yang disediakan dengan tautan konformasi akan memastikan alamat email itu valid.

@ Mike - Saya pikir sebagian alasan mengapa email konfirmasi dikirim bukan hanya untuk memastikan bahwa alamat email itu valid, tetapi juga dapat diakses oleh pengguna yang mengirimkannya. Seseorang dapat dengan mudah memasukkan salah ketik satu huruf di alamat email yang akan mengarah ke alamat email yang berbeda dan valid, tetapi itu masih merupakan kesalahan karena itu alamat yang salah .

Regex paling lengkap dan akurat yang pernah saya temui untuk validasi email adalah yang didokumentasikan di sini . Ini bukan untuk orang yang lemah hati; cukup rumit sehingga dipecah menjadi beberapa bagian untuk memudahkan manusia mengurai (kode sampel ada di Jawa). Tetapi dalam kasus di mana semua jalan dengan validasi layak, saya tidak berpikir itu menjadi jauh lebih baik.

Dalam kasus apa pun, saya akan menyarankan agar Anda menggunakan pengujian unit untuk mengonfirmasi bahwa ekspresi Anda mencakup kasus yang menurut Anda penting. Dengan begitu, saat Anda bermain-main dengannya, Anda dapat yakin bahwa Anda belum memecahkan beberapa kasus yang berfungsi sebelumnya.

Apa pun yang Anda pilih, saya pikir Anda perlu berbuat salah dengan meyakini bahwa 99% dari waktu tersebut, pengguna benar - benar tahu apa alamat email mereka. Sebagai seseorang dari Australia, saya kadang-kadang masih menemukan validasi email yang sangat pintar yang memberi tahu saya bahwa saya tidak mungkin memiliki domain .com.au. Dulu terjadi lebih banyak di hari-hari awal pikiran Anda.

Mengirim email konfirmasi hari ini dapat diterima oleh pengguna, dan juga berguna dalam hal ikut serta serta memvalidasi alamat yang diberikan.

Di beberapa situs yang dikembangkan di tempat saya bekerja, kami selalu menggunakan email konfirmasi. Namun, itu mengejutkan bagi pengguna untuk salah ketik alamat email mereka dengan cara yang tidak mungkin berhasil, dan kemudian terus menunggu email konfirmasi yang tidak akan datang. Menambahkan kode ad-hoc (atau, untuk bagian nama domain, verifikasi DNS) untuk memperingatkan pengguna dalam kasus ini bisa menjadi ide yang baik.

Kasus-kasus umum yang saya lihat:

• Menjatuhkan surat di tengah nama domain, atau beberapa varian kesalahan ketik sederhana lainnya.
• Kebingungan TLD (misalnya, menambahkan a .brke .comdomain, atau menjatuhkannya .brdari .com.brdomain).
• Menambahkan www.di awal bagian lokal dari alamat email (saya tidak mengada-ada; saya melihat beberapa alamat email dari formulir www.username@example.com).

Bahkan ada kasus yang lebih aneh; hal-hal seperti nama domain lengkap sebagai bagian lokal, alamat dengan dua @(sesuatu seperti username@domain.tld@example.com), dan sebagainya.

Tentu saja, kebanyakan dari mereka masih alamat RFC-822 yang valid, jadi secara teknis Anda bisa membiarkan MTA berurusan dengan mereka. Namun, memperingatkan pengguna bahwa alamat email yang dimasukkan sangat mungkin palsu dapat membantu, terutama jika audiens target Anda tidak terlalu melek komputer.

Semua validasi regex di dunia tidak akan mencegah seseorang memasukkan alamat email yang salah atau palsu. Benar-benar menjengkelkan.

Tergantung pada tujuannya. Jika Anda ISP dan Anda perlu memvalidasi bahwa pengguna membuat alamat email yang valid, pilih Regex yang memvalidasi terhadap segala yang mungkin terjadi. Jika Anda hanya ingin menangkap kesalahan pengguna, bagaimana dengan pola berikut:

[Semua Karakter, tanpa spasi] @ [huruf dan angka] (. [Huruf dan angka]) di mana grup terakhir muncul setidaknya satu kali.

RegEx untuk ini akan muncul sesuatu seperti ini:

[\S]+@[\w]+(.[\w-]+)+

Dan kemudian kirim email konfirmasi untuk memastikan.

@ Yaakov (bisa membalas dengan semacam 'membalas' di sini)

Saya pikir bagian dari alasan mengapa email konfirmasi dikirim tidak hanya untuk memastikan bahwa alamat email itu valid, tetapi juga dapat diakses oleh pengguna yang mengirimkannya. Seseorang dapat dengan mudah memasukkan salah ketik satu huruf di alamat email yang akan mengarah ke alamat email yang berbeda dan valid, tetapi itu masih merupakan kesalahan karena itu alamat yang salah.

Saya setuju, tapi saya tidak yakin itu sepadan. Kami juga memiliki bidang konfirmasi untuk tujuan itu (ulangi alamat email Anda lagi). Situasi lain di mana jenis situs mungkin memerlukan pendekatan yang berbeda.

Selain itu, mengirim email konfirmasi sendiri tidak memberikan indikasi kepada pengguna asli bahwa alamat yang mereka masukkan salah. Setelah tidak menerima email konfirmasi, mereka mungkin menganggap aplikasi / situs Anda salah; setidaknya dengan memungkinkan pengguna untuk segera mulai menggunakan akun mereka, mereka dapat memperbaiki alamat email mereka, terutama jika itu ditampilkan di tempat yang jelas terlihat.

Kuda untuk kursus.

Semua itu sah, melengkapi sistem verifikasi email di dalam dan dari diri mereka sendiri, dan untuk situs web yang diberikan lebih tepat (atau sebaik yang dibenarkan) daripada yang lain. Dalam banyak kasus beberapa langkah verifikasi mungkin berguna.

Jika Anda mengembangkan situs web untuk bank, Anda akan menginginkan verifikasi surat atau telepon siput di atas semua ini.

Jika Anda mengembangkan situs web untuk kontes, Anda mungkin tidak menginginkannya - verifikasi email dalam pemrosesan posting dan jika salah satu gagal, itu terlalu buruk bagi orang yang memasukinya - Anda mungkin menghargai kinerja server karena banyak orang ( Kontes TV, misalnya) untuk memastikan bahwa setiap orang akan divalidasi dengan benar sebaris.

Seberapa jauh seseorang harus mengambil verifikasi email?

Sejauh diperlukan dan dijamin.

Dan tidak ada lagi (CIUMAN)

Saya telah melihat situs-situs yang juga melindungi orang-orang yang menggunakan situs-situs temporer spam bucket seperti Mailinator atau MyTrashMail , yang dapat menyelesaikan masalah email konfirmasi. Saya tidak mengatakan Anda harus menyaringnya, saya hanya mengatakan.

Apa yang Anda coba tangkap dalam validasi email Anda?

Validasi validasi alamat email dapat, paling tidak, memverifikasi bahwa alamat tersebut secara sintaksis benar dan relatif masuk akal. Ini juga memiliki bahaya (seperti yang telah disebutkan berkali-kali) dari kemungkinan menolak alamat yang sebenarnya, yang dapat dikirimkan jika regex tidak cukup benar.

Verifikasi SMTP dapat menentukan bahwa alamat tersebut dapat dikirimkan, tergantung pada batasan yang diberlakukan oleh greylisting atau server yang dikonfigurasi untuk memberikan informasi sesedikit mungkin tentang penggunanya. Anda tidak memiliki cara untuk mengetahui apakah MTA hanya mengklaim menerima email untuk alamat palsu, kemudian menjatuhkannya di lantai sebagai bagian dari strategi anti-spam.

Namun, mengirim pesan konfirmasi adalah satu - satunya cara untuk memverifikasi bahwa alamat itu milik pengguna yang memasukkannya. Jika saya mengisi formulir Anda, saya dapat dengan mudah memberi tahu Anda bahwa alamat email saya adalah president@whitehouse.gov. Sebuah regex akan memberi tahu Anda bahwa secara sintaksis valid, sebuah SMTP RCPT TO akan memberi tahu Anda bahwa itu adalah alamat yang dapat dikirimkan, tetapi itu pasti bukan alamat saya .

Dengan kedatangan HTML5 setidaknya satu pendekatan baru ditambahkan ke kemungkinan: penggunaan input tipe ' email ' yang memungkinkan validasi di sisi klien. Versi Firefox, Chrome, Safari, dan Opera saat ini mendukung hal ini (dan peramban lain hanya memperlakukannya seperti type = teks, sehingga dapat digunakan tanpa masalah meskipun Anda tidak memiliki validasi tentunya.)

Itu tidak akan pernah (seperti yang ditunjukkan beberapa kali) menjamin alamat yang bisa dikerjakan, tetapi mungkin sangat bermanfaat (dan akhirnya mengganti cek sisi server) di tempat-tempat di mana Anda hanya perlu menangkap kemungkinan kesalahan pengguna.

Tiga tingkat utama validasi email:

1) cek ekspresi reguler untuk alamat email yang diformat dengan benar email@email.com

2) cek domain email terhadap data MX untuk melihat apakah nama domain memiliki layanan email

3) mengirim email konfirmasi dengan tautan atau kode konfirmasi

Tingkat 1:

Di Visual Studio, Anda dapat menggunakan "Validator Ekspresi Reguler". Dan di properti "ValidationExpression" Anda dapat mengklik tombol "..." yang memiliki panduan untuk menambahkan dalam format ekspresi reguler untuk alamat email.

Level 2:

Berikut ini adalah kode C # saya di bawah ini untuk menggunakan nslookup untuk memverifikasi apakah domain email memiliki catatan MX yang valid. Berjalan cepat dan ok pada Win 2008 R2 dan Win 7.

using System.Net.Mail;
using System.Diagnostics;

public static bool checkMXRecords(string email) 
    {
        MailAddress addr = new MailAddress(email);
        string domain = addr.Host;

        string command = "nslookup -querytype=mx " + domain;
        ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + command);

        procStartInfo.RedirectStandardOutput = true;
        procStartInfo.UseShellExecute = false;

        procStartInfo.CreateNoWindow = true;

        Process proc = new Process();
        proc.StartInfo = procStartInfo;
        proc.Start();
        string result = proc.StandardOutput.ReadToEnd();

        if (result.ToLower().Contains("mail exchanger"))
        {
            return true;
        }
        else return false;

     } // checkMXRecords

pilihan lain adalah dengan menggunakan paket nuget Arsofttools tetapi mungkin lambat pada Windows Server 2008 R2 seperti yang saya alami tetapi berjalan cepat pada Win 7.

Tingkat 3:

Untuk konfirmasi email, Anda dapat membuat url hex khusus email (menggunakan fungsi enkripsi) dll http://domain.com/validateEmail?code=abcd1234 untuk memvalidasi alamat email ketika pengguna mengkliknya. Tidak perlu menyimpan url ini dalam memori.