Karakter apa yang diizinkan di alamat email?


641

Saya tidak bertanya tentang validasi email lengkap.

Saya hanya ingin tahu karakter apa saja yang diperbolehkan user-namedan serverbagian dari alamat email. Ini mungkin terlalu disederhanakan, mungkin alamat email dapat mengambil bentuk lain, tapi saya tidak peduli. Saya hanya bertanya tentang formulir sederhana ini: user-name@server(mis. Wild.wezyr@best-server-ever.com) dan karakter yang diizinkan di kedua bagian.


185
The +diperbolehkan. Ini membuat saya gila ketika situs web tidak mengizinkannya karena email saya ada +di dalamnya dan begitu banyak situs tidak mengizinkannya.
Dan Herbert

42
Saya pikir penting untuk memberikan tautan ke spesifikasi, karena Anda benar-benar ingin memperbaikinya, dan di situlah spesifikasi tersebut muncul. Jika Anda terlalu malas untuk membaca dan memahami spesifikasi, maka silakan memeriksa karakter yang diizinkan di alamat email kepada orang-orang yang peduli tentang stuf itu.
jhwist

9
Pertanyaan sebelumnya yang mencakup materi yang sama: stackoverflow.com/questions/760150/ . Yang menyedihkan adalah, meskipun pertanyaan itu hampir 8 bulan lebih tua dari yang ini, pertanyaan yang lebih tua memiliki jawaban yang jauh lebih baik. Hampir semua jawaban di bawah ini sudah usang ketika mereka awalnya diposting. Lihat entri Wikipedia (dan jangan khawatir, ini memiliki referensi resmi yang relevan ).
John Y

10
Bertentangan dengan beberapa jawaban, ruang yang diperbolehkan di bagian lokal dari alamat email, jika dikutip. "hello world"@example.comadalah benar.
user253751

3
@LaraRuffleColes - Untuk Gmail, saat Anda membuat akun email, itu tidak memungkinkan Anda membuat alamat yang berisi tanda "+". Tanda "+" ("Penambahan alamat") memungkinkan siapa pun yang memiliki alamat Gmail untuk menambahkan tanda "+" yang diikuti oleh "string" ke akhir nama pengguna mereka untuk membuat alamat email "pengganti" ("alias") untuk digunakan untuk akun mereka. Contoh: "example@gmail.com", "example+tag@gmail.com". Penggunaan khas (dan mungkin "Primer") untuk dapat membuat alias alamat email untuk akun Anda yang memungkinkan Anda untuk menandai dan memfilter pesan email yang masuk, secara teoritis difilter oleh pengirim.
Kevin Fegan

Jawaban:


797

Lihat RFC 5322: Format Pesan Internet dan, pada tingkat lebih rendah, RFC 5321: Protokol Transfer Surat Sederhana .

RFC 822 juga mencakup alamat email, tetapi sebagian besar berhubungan dengan strukturnya:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

Dan seperti biasa, Wikipedia memiliki artikel yang layak tentang alamat email :

Bagian lokal dari alamat email dapat menggunakan salah satu karakter ASCII ini:

  • huruf latin besar dan kecil Adari Zdan ake z;
  • digit 0untuk 9;
  • karakter khusus !#$%&'*+-/=?^_`{|}~;
  • dot ., asalkan itu bukan karakter pertama atau terakhir kecuali dikutip, dan asalkan juga tidak muncul secara berurutan kecuali dikutip (mis. John..Doe@example.comtidak diperbolehkan tetapi "John..Doe"@example.comdiizinkan);
  • ruang dan "(),:;<>@[\]karakter diizinkan dengan batasan (mereka hanya diizinkan di dalam string yang dikutip, seperti yang dijelaskan dalam paragraf di bawah ini, dan di samping itu, garis miring terbalik atau tanda kutip ganda harus didahului dengan garis miring terbalik);
  • komentar diperbolehkan dengan tanda kurung di kedua ujung bagian lokal; misalnya john.smith(comment)@example.comdan (comment)john.smith@example.comkeduanya sama dengan john.smith@example.com.

Selain karakter ASCII, pada 2012 Anda dapat menggunakan karakter internasional di atasU+007F , dikodekan sebagai UTF-8 seperti yang dijelaskan dalam spesifikasi RFC 6532 dan dijelaskan di Wikipedia . Perhatikan bahwa pada 2019, standar-standar ini masih ditandai sebagai Usulan, tetapi sedang diluncurkan perlahan. Perubahan dalam spesifikasi ini pada dasarnya menambahkan karakter internasional sebagai karakter alfanumerik yang valid (atext) tanpa mempengaruhi aturan tentang karakter khusus yang diizinkan & dibatasi seperti !#dan @:.

Untuk validasi, lihat Menggunakan ekspresi reguler untuk memvalidasi alamat email .

Bagian domaintersebut didefinisikan sebagai berikut :

Standar Internet (Permintaan Komentar) untuk protokol mengamanatkan bahwa label hostname komponen hanya boleh berisi huruf ASCII amelalui z(dengan cara case-insensitive), digit 0melalui 9, dan tanda hubung ( -). Spesifikasi asli dari nama host di RFC 952 , mengamanatkan bahwa label tidak dapat dimulai dengan digit atau dengan tanda hubung, dan tidak boleh diakhiri dengan tanda hubung. Namun, spesifikasi berikutnya ( RFC 1123 ) mengizinkan label nama host untuk memulai dengan angka. Tidak ada simbol, karakter tanda baca, atau ruang kosong lainnya yang diizinkan.


15
@WildWzyr, Ini tidak sesederhana itu. Alamat email memiliki banyak aturan untuk apa yang diizinkan. Lebih mudah untuk merujuk pada spesifikasi daripada mendaftar semuanya. Jika Anda ingin Regex yang lengkap, periksa di sini untuk mendapatkan ide mengapa itu tidak begitu sederhana: regular-expressions.info/email.html
Dan Herbert

6
tidak ada daftar yang sederhana, hanya karena Anda menginginkan sesuatu yang sederhana tidak berarti demikian. beberapa karakter hanya dapat berada di lokasi tertentu dan tidak di yang lain. Anda tidak dapat memiliki apa yang Anda inginkan sepanjang waktu.

15
@WildWezyr Nah, karakter full-stop diperbolehkan di bagian lokal. Tetapi tidak di awal atau akhir. Atau dengan full-stop lainnya. Jadi jawabannya TIDAK sesederhana hanya daftar karakter yang diperbolehkan, ada aturan tentang bagaimana karakter tersebut dapat digunakan - .ann..other.@example.combukan alamat email yang valid, tetapi ann.other@example.com, meskipun keduanya menggunakan karakter yang sama.
Mark Pim

14
Juga, ingat bahwa dengan nama domain yang diinternasionalkan masuk, daftar karakter yang diizinkan akan meledak.
Chinmay Kanchi

50
Ini bukan lagi jawaban yang valid, karena alamat yang diinternasionalkan. Lihat jawaban Mason.
ZacharyP

329

Awas! Ada banyak pengetahuan yang membusuk di utas ini (hal-hal yang dulu benar dan sekarang tidak).

Untuk menghindari penolakan positif palsu terhadap alamat email aktual di dunia saat ini dan masa depan, dan dari mana saja di dunia, Anda perlu tahu setidaknya konsep tingkat tinggi RFC 3490 , "Menginternasionalkan Nama Domain dalam Aplikasi (IDNA)". Saya tahu orang-orang di AS dan A sering tidak memahami hal ini, tetapi sudah digunakan secara luas dan meningkat pesat di seluruh dunia (terutama bagian yang didominasi non-Inggris).

Intinya adalah bahwa Anda sekarang dapat menggunakan alamat seperti mason @ 日本 .com dan wildwezyr@fahrvergnügen.net. Tidak, ini belum kompatibel dengan semua yang ada di luar sana (seperti yang banyak disesalkan di atas, bahkan alamat ident + style qmail yang sederhana sering salah ditolak). Tetapi ada RFC, ada spek, sekarang didukung oleh IETF dan ICANN, dan - yang lebih penting - ada sejumlah besar dan semakin banyak implementasi yang mendukung peningkatan ini yang saat ini dalam pelayanan.

Saya sendiri tidak tahu banyak tentang perkembangan ini sampai saya pindah kembali ke Jepang dan mulai melihat alamat email seperti hei @ や る .ca dan URL Amazon seperti ini:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル メ ラ - ポ ー ー ブ ル b b / b / ref = topnav_storetab_e? yaitu = UTF8 & simpul = 3210981

Saya tahu Anda tidak ingin tautan ke spesifikasi, tetapi jika Anda hanya mengandalkan pengetahuan peretas yang sudah ketinggalan zaman di forum Internet, validator email Anda pada akhirnya akan menolak alamat email yang semakin diharapkan pengguna yang tidak berbahasa Inggris untuk bekerja. Bagi para pengguna itu, validasi seperti itu akan sama menjengkelkannya dengan bentuk mati-otak yang biasa yang kita semua benci, yang tidak dapat menangani + atau nama domain tiga bagian atau apa pun.

Jadi saya tidak mengatakan itu tidak merepotkan, tetapi daftar lengkap karakter "diizinkan dalam beberapa kondisi / / tidak ada kondisi" adalah (hampir) semua karakter dalam semua bahasa. Jika Anda ingin "menerima semua alamat email yang valid (dan banyak juga yang tidak valid)" maka Anda harus mempertimbangkan IDN, yang pada dasarnya membuat pendekatan berbasis karakter menjadi tidak berguna (maaf), kecuali Anda terlebih dahulu mengubah alamat email yang diinternasionalisasikan ke Punycode .

Setelah melakukan itu, Anda dapat mengikuti (sebagian besar) saran di atas.


17
Baik; di belakang layar, nama domain masih hanya ASCII. Tetapi, jika aplikasi atau formulir web Anda menerima input yang dimasukkan pengguna, maka ia harus melakukan pekerjaan yang sama seperti yang dilakukan browser web atau klien email saat pengguna memasukkan nama host IDN: untuk mengubah input pengguna menjadi bentuk yang kompatibel dengan DNS. Kemudian validasi. Jika tidak, alamat email yang diinternasionalkan ini tidak akan lulus validasi Anda. (Konverter seperti yang saya tautkan hanya memodifikasi karakter non-ASCII yang diberikan kepada mereka, sehingga aman untuk menggunakannya pada alamat email yang tidak diinternasionalkan (yang baru saja dikembalikan tanpa dimodifikasi).)
Mason

2
Untuk pengembang Javascript , saya sekarang sedang meneliti metode untuk melakukan ini, dan Punycode.js tampaknya menjadi solusi yang paling lengkap dan dipoles.
wwaawaw

5
Perhatikan bahwa Email yang Diinternasionalisasi (seperti yang didefinisikan saat ini) tidak mengonversi alamat non-ASCII menggunakan punycode atau serupa, sebaliknya memperluas sebagian besar protokol SMTP itu sendiri untuk menggunakan UTF8.
IMSoP

2
Apakah saya melewatkan sesuatu atau gagal menjawab pertanyaan? Saya membaca 'jawaban lain salah, Anda perlu menerima lebih banyak karakter' tetapi kemudian gagal untuk menyatakan karakter tambahan mana. Saya juga tidak bisa (dengan mudah) melihat dalam RFC itu apakah itu berarti semua poin kode Unicode atau hanya BMP.
Samuel Harmer

3
Tampaknya ini berada di jalur yang benar untuk menjadi jawaban yang benar. Saya yakin itu akan mendapatkan lebih banyak suara jika Anda memasukkan secara spesifik tentang karakter yang dilindungi dan diizinkan.
Sean

59

Format alamat email adalah: local-part@domain-part (maks. 64 @ 255 karakter, tidak lebih 256 total).

The local-partdandomain-part bisa memiliki set yang berbeda dari karakter yang diizinkan, tapi itu tidak semua, karena ada aturan lebih untuk itu.

Secara umum, bagian lokal dapat memiliki karakter ASCII ini:

  • huruf kecil huruf Latin: abcdefghijklmnopqrstuvwxyz,
  • huruf latin besar: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • digit: 0123456789 ,
  • karakter spesial: !#$%&'*+-/=?^_`{|}~ ,
  • dot: . (bukan karakter pertama atau terakhir atau diulang kecuali dikutip),
  • tanda baca ruang seperti: "(),:;<>@[\] (dengan beberapa batasan),
  • komentar: ()(diizinkan di dalam tanda kurung, mis (comment)john.smith@example.com.).

Bagian domain:

  • huruf latin kecil: abcdefghijklmnopqrstuvwxyz,
  • huruf latin besar: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • digit: 0123456789 ,
  • tanda penghubung: - (bukan karakter pertama atau terakhir),
  • dapat berisi alamat IP yang dikelilingi oleh tanda kurung: jsmith@[192.168.2.1]atau jsmith@[IPv6:2001:db8::1].

Alamat email ini valid:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (bagian lokal satu huruf)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (nama domain lokal tanpa domain tingkat atas)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (spasi antara tanda kutip)
  • example@localhost (dikirim dari localhost)
  • example@s.solutions(lihat Daftar domain tingkat atas Internet )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

Dan contoh-contoh tidak valid ini:

  • Abc.example.com(tidak ada @karakter)
  • A@b@c@example.com(hanya satu @yang diizinkan di luar tanda kutip)
  • a"b(c)d,e:f;gi[j\k]l@example.com (tidak ada karakter khusus di bagian lokal ini yang diizinkan di luar tanda kutip)
  • just"not"right@example.com (string yang dikutip harus dipisahkan dengan titik atau satu-satunya elemen yang membentuk bagian lokal)
  • this is"not\allowed@example.com (spasi, kutipan, dan garis miring terbalik mungkin hanya ada ketika dalam string yang dikutip dan didahului oleh garis miring terbalik)
  • this\ still\"not\allowed@example.com (bahkan jika lolos (didahului dengan garis miring terbalik), spasi, tanda kutip, dan garis miring terbalik masih harus diisi dengan tanda kutip)
  • john..doe@example.com(titik ganda sebelumnya @); (dengan peringatan: Gmail membiarkan ini lewat)
  • john.doe@example..com(titik ganda setelah @)
  • alamat yang valid dengan spasi terdepan
  • alamat yang valid dengan spasi tambahan

Sumber: Alamat email di Wikipedia


Regex RFC2822 Perl untuk memvalidasi email:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Regexp penuh untuk alamat RFC2822 hanya 3,7k.

Lihat juga: Parser Alamat Email RFC 822 dalam PHP .


Definisi resmi dari alamat email ada di:

  • RFC 5322 (bagian 3.2.3 dan 3.4.1, obsoletes RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (karakter yang diizinkan).

Terkait:


5
Sebagai peringatan ekstra untuk calon pelaksana regex ini: Jangan. Cukup verifikasi bahwa ia mengikuti format something@something.somethingdan menyebutnya sehari.
Chris Sobolewski

Sementara hal seperti ini tidak dapat dipertahankan, ini adalah latihan yang bagus untuk memecahkan kode dan benar-benar mencari tahu apa yang dilakukannya
berterima kasih

@ChrisSobolewski memungkinkan beberapa hal di kedua sisi '@'
Jasen

Saya sudah mencoba menerapkan ini dalam postfix melalui tabel akses pcre di bawah pembatasan check_recipient_access, pertama-tama mengubah 3 pcre panjang (dari halaman yang terhubung) menjadi satu baris masing-masing dan topping dan tailing dengan demikian: /^[...pcre ..] $ / DUNNO, kemudian menambahkan baris terakhir /.*/ TOLAK, tetapi masih memungkinkan melalui alamat email yang tidak valid. Postfix 3.3.0; perl 5, versi 26, subversi 1 (v5.26.1).
scoobydoo

3
Kegilaan, kataku. Siapa yang akan menggunakannya dalam produksi. Ada titik di mana ekspresi reguler seharusnya tidak lagi digunakan. Jauh di luar titik itu.
tomuxmon

22

Wikipedia memiliki artikel bagus tentang ini , dan spek resmi ada di sini . Dari Wikipdia:

Bagian lokal dari alamat email dapat menggunakan salah satu karakter ASCII ini:

  • Huruf besar dan kecil Bahasa Inggris (az, AZ)
  • Digit 0 hingga 9
  • Karakter! # $% & '* + - / =? ^ _ `{| } ~
  • Karakter (titik, titik, berhenti penuh) asalkan itu bukan karakter pertama atau terakhir, dan asalkan juga tidak muncul dua kali atau lebih secara berurutan.

Selain itu, string yang dikutip (yaitu: "John Doe" @ example.com) diizinkan, sehingga memungkinkan karakter yang dinyatakan dilarang, namun mereka tidak muncul dalam praktik umum. RFC 5321 juga memperingatkan bahwa "host yang mengharapkan untuk menerima mail HARUS menghindari mendefinisikan kotak surat di mana bagian-lokal membutuhkan (atau menggunakan) bentuk string-Dikutip".


@WildWezyr Nama host yang valid, yang bisa berupa alamat ip, FQN, atau sesuatu yang dapat diselesaikan ke host jaringan lokal.
JensenDied

String yang dikutip sangat penting untuk melewati gateway, ingat Banyan Vines?
mckenzm

13

Google melakukan hal yang menarik dengan alamat gmail.com mereka. alamat gmail.com hanya mengizinkan huruf (az), angka, dan titik (yang diabaikan).

misalnya, pikachu@gmail.com sama dengan pi.kachu@gmail.com, dan kedua alamat email akan dikirim ke kotak surat yang sama. PIKACHU@gmail.com juga dikirimkan ke kotak surat yang sama.

Jadi untuk menjawab pertanyaan, terkadang tergantung pada pelaksana pada seberapa banyak standar RFC yang ingin mereka ikuti. Gaya alamat gmail.com Google kompatibel dengan standar. Mereka melakukannya dengan cara itu untuk menghindari kebingungan di mana orang yang berbeda akan mengambil alamat email yang sama misalnya

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

Tautan wikipedia adalah referensi yang bagus tentang apa yang umumnya dibolehkan oleh alamat email. http://en.wikipedia.org/wiki/Email_address


2
Ya ini adalah jawaban yang bagus tentang mengapa Gmail tidak mengizinkan untuk MENCIPTAKAN email dengan ini. Tetapi Anda dapat mengirim dan menerima email {john'doe}@my.servertanpa masalah. Diuji dengan server hMail juga.
Piotr Kula

Anda dapat menguji klien Anda dengan mengirim email ke {piotr'kula}@kula.solutions- Jika berhasil, Anda akan mendapatkan balasan otomatis yang bagus dari itu. Kalau tidak, tidak akan terjadi apa-apa.
Piotr Kula

3
Gmail memang mengikuti RFC 6530 dalam arti bahwa setiap alamat email yang dimungkinkan oleh Gmail valid menurut RFC. Gmail hanya memilih untuk membatasi lebih lanjut set alamat yang diizinkan dengan aturan tambahan, dan untuk membuat alamat yang serupa dengan titik-titik di bagian lokal, secara opsional diikuti oleh "+" dan karakter alfanumerik, sinonim.
Teemu Leisti

Google membatasi kriteria pembuatan akun ... Saya pikir mereka menggosok string akun email masuk dari "tanda baca" tambahan dan mengikuti tanda alias string yang diawali agar email dapat dialihkan ke akun yang tepat. Peasy mudah. Dengan melakukan hal itu, mereka secara efektif tidak mengizinkan orang untuk membuat alamat email hanya-sentakan sehingga alamat yang valid yang dibuat sering melewati validasi sederhana dan paling kompleks.
BradChesney79

Ini bukan hanya gmail, Beberapa penyedia memiliki "relay filter" yang menolak string yang dikutip tertentu, terutama yang mengandung "=" seolah-olah mereka pembatas. Ini untuk memblokir pengguna agar tidak mengatur gateway dan membuat alamat spam di string pribadi yang dikutip. "@" valid tetapi "= @ =" tidak (dianggap) valid.
mckenzm

12

Anda bisa mulai dari artikel wikipedia :

  • Huruf besar dan kecil Bahasa Inggris (az, AZ)
  • Digit 0 hingga 9
  • Karakter! # $% & '* + - / =? ^ _ `{| } ~
  • Karakter (titik, titik, berhenti penuh) asalkan itu bukan karakter pertama atau terakhir, dan asalkan juga tidak muncul dua kali atau lebih secara berurutan.

11

Nama:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Server:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Bagaimana dengan <>dan []? Misalnya "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Tolong kutip sumber. Tanpa sumber, ini terlihat seperti dugaan.
Mathieu K.

15
Ini sudah ketinggalan zaman, dan mungkin tidak pernah benar.
Jason Harrison

9

Periksa @ dan. dan kemudian mengirim email untuk mereka verifikasi.

Saya masih tidak dapat menggunakan alamat email .name saya di 20% dari situs di internet karena seseorang mengacaukan validasi email mereka, atau karena itu mendahului alamat baru yang valid.


9
Bahkan. tidak sepenuhnya diperlukan; Saya pernah mendengar setidaknya satu kasus alamat email di domain tingkat atas (khususnya ua). Alamatnya adalah <name> @ua - no dot!

Ini adalah cara termudah untuk tidak mengacaukan validasi Anda, karena hampir semuanya diizinkan, dan jika ada sesuatu yang tidak diizinkan, server penerima akan memberi tahu Anda.
Avamander

5

Jawaban singkatnya adalah ada 2 jawaban. Ada satu standar untuk apa yang harus Anda lakukan. yaitu perilaku yang bijaksana dan akan membuat Anda keluar dari masalah. Ada standar lain (jauh lebih luas) untuk perilaku yang harus Anda terima tanpa membuat masalah. Dualitas ini berfungsi untuk mengirim dan menerima email tetapi memiliki aplikasi luas dalam kehidupan.

Untuk panduan yang baik untuk alamat yang Anda buat; lihat: http://www.remote.org/jochen/mail/info/chars.html

Untuk memfilter email yang valid, sampaikan saja sesuatu yang cukup dapat dipahami untuk melihat langkah selanjutnya. Atau mulai membaca banyak RFC, hati-hati, ini naga.


Tautan hilang. Konten apa yang ada di sana?
siapaoe

5

Bacaan yang bagus tentang masalah ini .

Kutipan:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Saya bertanya-tanya tentang '@' sebelum bagian domain. Bisakah itu digunakan?
Saiyaff Farouk

@SaiyaffFarouk sesuai dengan spesifikasinya, ya. Namun, sebagian besar penyedia email kemungkinan tidak akan mengizinkannya sebagai bagian dari validasi mereka sendiri
Luke Madhanga

blog itu mendaftar Joe.\\Blow@example.comtanpa tanda kutip. Apakah ini benar-benar valid? Tampaknya tidak jelas diberikan jawaban di sini, tapi saya bertanya karena saya telah melihat (sangat jarang) kasus string email DNS SoA rname yang berisi backslash.
wesinat0r

5

Jawaban yang diterima merujuk pada artikel Wikipedia ketika membahas bagian lokal yang valid dari alamat email, tetapi Wikipedia tidak berwenang atas hal ini.

IETF RFC 3696 adalah otoritas mengenai masalah ini, dan harus dikonsultasikan pada bagian 3. Pembatasan pada alamat email pada halaman 5:

Alamat email kontemporer terdiri dari "bagian lokal" yang dipisahkan dari "bagian domain" (nama domain yang sepenuhnya memenuhi syarat) dengan tanda-at ("@"). Sintaks bagian domain sesuai dengan yang ada di bagian sebelumnya. Kekhawatiran yang diidentifikasi di bagian itu tentang pemfilteran dan daftar nama juga berlaku untuk nama domain yang digunakan dalam konteks email. Nama domain juga dapat diganti dengan alamat IP dalam tanda kurung siku, tetapi formulir itu sangat tidak disarankan kecuali untuk tujuan pengujian dan pemecahan masalah.

Bagian lokal dapat muncul menggunakan konvensi kutipan yang dijelaskan di bawah ini. Formulir yang dikutip jarang digunakan dalam praktik, tetapi diperlukan untuk beberapa tujuan yang sah. Oleh karena itu, mereka tidak boleh ditolak dalam rutinitas penyaringan tetapi, sebaliknya harus diteruskan ke sistem email untuk evaluasi oleh tuan rumah tujuan.

Aturan yang tepat adalah bahwa setiap karakter ASCII, termasuk karakter kontrol, dapat muncul dikutip, atau dalam string yang dikutip. Ketika mengutip diperlukan, karakter backslash digunakan untuk mengutip karakter berikut. Sebagai contoh

  Abc\@def@example.com

adalah bentuk alamat email yang valid. Ruang kosong juga dapat muncul, seperti pada

  Fred\ Bloggs@example.com

Karakter backslash juga dapat digunakan untuk mengutip sendiri, misalnya,

  Joe.\\Blow@example.com

Selain mengutip menggunakan karakter backslash, karakter kutipan ganda konvensional dapat digunakan untuk mengelilingi string. Sebagai contoh

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

adalah bentuk alternatif dari dua contoh pertama di atas. Formulir yang dikutip ini jarang direkomendasikan, dan tidak lazim dalam praktiknya, tetapi, sebagaimana dibahas di atas, harus didukung oleh aplikasi yang memproses alamat email. Secara khusus, formulir yang dikutip sering muncul dalam konteks alamat yang terkait dengan transisi dari sistem dan konteks lain; persyaratan transisi tersebut masih muncul dan, karena sistem yang menerima alamat email yang disediakan pengguna tidak dapat "mengetahui" apakah alamat itu dikaitkan dengan sistem lama, formulir alamat harus diterima dan diteruskan ke lingkungan email.

Tanpa tanda kutip, bagian lokal dapat terdiri dari kombinasi
karakter alfabet, digit, atau karakter khusus apa pun

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

periode (".") juga dapat muncul, tetapi tidak dapat digunakan untuk memulai atau mengakhiri bagian lokal, juga dua atau lebih periode berturut-turut tidak muncul. Dengan kata lain, karakter grafis (pencetakan) ASCII lain selain tanda-at ("@"), garis miring terbalik, tanda kutip ganda, tanda koma, atau tanda kurung kotak dapat muncul tanpa mengutip. Jika salah satu dari daftar karakter yang dikecualikan muncul, mereka harus dikutip. Bentuk seperti

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

valid dan terlihat cukup teratur, tetapi salah satu karakter yang tercantum di atas diizinkan.

Seperti yang dilakukan orang lain, saya mengirimkan regex yang berfungsi untuk PHP dan JavaScript untuk memvalidasi alamat email:

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

3

Seperti dapat ditemukan di tautan Wikipedia ini

Bagian lokal dari alamat email dapat menggunakan salah satu karakter ASCII ini:

  • huruf latin besar dan kecil Adari Zdan ake z;

  • digit 0untuk 9;

  • karakter khusus !#$%&'*+-/=?^_`{|}~;

  • dot ., asalkan itu bukan karakter pertama atau terakhir kecuali dikutip, dan asalkan juga tidak muncul secara berurutan kecuali dikutip (mis. John..Doe@example.comtidak diperbolehkan tetapi "John..Doe"@example.comdiizinkan);

  • ruang dan "(),:;<>@[\]karakter diizinkan dengan batasan (mereka hanya diizinkan di dalam string yang dikutip, seperti yang dijelaskan dalam paragraf di bawah ini, dan di samping itu, garis miring terbalik atau tanda kutip ganda harus didahului dengan garis miring terbalik);

  • komentar diperbolehkan dengan tanda kurung di kedua ujung bagian lokal; misalnya john.smith(comment)@example.comdan (comment)john.smith@example.comkeduanya sama dengan john.smith@example.com.

Selain karakter ASCII di atas, karakter internasional di atas U + 007F, yang dikodekan sebagai UTF-8, diizinkan oleh RFC 6531 , meskipun sistem surat mungkin membatasi karakter mana yang akan digunakan saat menetapkan komponen lokal.

String yang dikutip mungkin ada sebagai entitas titik terpisah dalam bagian-lokal, atau mungkin ada ketika kutipan terluar adalah karakter terluar dari bagian-lokal (misalnya, abc."defghi".xyz@example.comatau "abcdefghixyz"@example.comdiizinkan. Sebaliknya, abc"defghi"xyz@example.comtidak; tidak juga; tidak abc\"def\"ghi@example.com). Namun string dan karakter yang dikutip, tidak umum digunakan. RFC 5321 juga memperingatkan bahwa "host yang mengharapkan untuk menerima mail HARUS menghindari mendefinisikan kotak surat di mana bagian-lokal membutuhkan (atau menggunakan) bentuk string-Dikutip".

Bagian lokal postmasterdiperlakukan secara khusus — tidak peka huruf besar-kecil, dan harus diteruskan ke administrator email domain. Secara teknis, semua komponen lokal lainnya peka huruf besar kecil, oleh karena itu jsmith@example.comdan JSmith@example.comtentukan kotak surat yang berbeda; Namun, banyak organisasi memperlakukan huruf besar dan kecil sebagai setara.

Meskipun berbagai karakter khusus yang secara teknis valid; organisasi, layanan surat, server surat dan klien surat dalam praktik sering kali tidak menerima semuanya. Misalnya, Windows Live Hotmail hanya memungkinkan pembuatan alamat email menggunakan alfanumerik, titik ( .), garis bawah ( _) dan tanda hubung ( -). Saran umum adalah untuk menghindari penggunaan beberapa karakter khusus untuk menghindari risiko email yang ditolak.


0

Jawabannya adalah (hampir) ALL(ASCII 7-bit).
Jika aturan penyertaan adalah "... diizinkan dalam kondisi / ada / tidak ada ..."

Hanya dengan melihat salah satu dari beberapa aturan inklusi yang memungkinkan untuk teks yang diperbolehkan di bagian "teks domain" di RFC 5322 di bagian atas halaman 17 kita menemukan:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

hanya tiga karakter yang hilang dalam uraian ini yang digunakan dalam domain-literal [], untuk membentuk pasangan yang dikutip \, dan karakter spasi putih (% d32). Dengan itu seluruh rentang 32-126 (desimal) digunakan. Persyaratan serupa muncul sebagai "qtext" dan "ctext". Banyak karakter kontrol juga diperbolehkan / digunakan. Satu daftar karakter kontrol tersebut muncul di halaman 31 bagian 4.1 dari RFC 5322 sebagai obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Semua karakter kontrol ini diizinkan seperti yang dinyatakan pada awal bagian 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

Dan karena itu aturan inklusi "terlalu lebar". Atau, dalam arti lain, aturan yang diharapkan "terlalu sederhana".


0

Demi kesederhanaan, saya membersihkan kiriman dengan menghapus semua teks dalam tanda kutip ganda dan yang terkait dengan tanda kutip ganda sebelum validasi, menempatkan kibosh pada pengiriman alamat email berdasarkan apa yang dilarang. Hanya karena seseorang dapat memiliki John .. "Alamat * $ hizzle * Bizzle" .. Doe@wh whatever.com tidak berarti saya harus mengizinkannya di sistem saya. Kita hidup di masa depan di mana mungkin membutuhkan waktu lebih sedikit untuk mendapatkan alamat email gratis daripada melakukan pekerjaan dengan baik menyeka pantat Anda. Dan tidak seperti kriteria email tidak diplester tepat di sebelah input yang mengatakan apa yang boleh dan tidak boleh.

Saya juga membersihkan apa yang secara khusus tidak diizinkan oleh berbagai RFC setelah materi yang dikutip dihapus. Daftar karakter dan pola yang secara khusus tidak diizinkan tampaknya merupakan daftar yang jauh lebih pendek untuk diuji.

Dilarang:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

Dalam contoh yang diberikan:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

Mengirim pesan email konfirmasi ke hasil sisa setelah upaya untuk menambah atau mengubah alamat email adalah cara yang baik untuk melihat apakah kode Anda dapat menangani alamat email yang dikirimkan. Jika email lolos validasi setelah putaran sanitasi sebanyak yang diperlukan, maka matikan konfirmasi itu. Jika suatu permintaan kembali dari tautan konfirmasi, maka email baru dapat dipindahkan dari status penyembuh || sementara || penyimpanan atau penyimpanan untuk menjadi email tersimpan kelas bonafide yang nyata.

Pemberitahuan kegagalan atau keberhasilan perubahan alamat email dapat dikirim ke alamat email lama jika Anda ingin mempertimbangkan. Penyiapan akun yang tidak dikonfirmasi mungkin keluar dari sistem karena upaya yang gagal seluruhnya setelah jangka waktu yang wajar.

Saya tidak memperbolehkan email yang tidak diinginkan di sistem saya, mungkin itu hanya membuang uang. Tetapi, 99,9% dari waktu orang hanya melakukan hal yang benar dan memiliki email yang tidak mendorong batas kesesuaian dengan jurang menggunakan skenario kompatibilitas kasus tepi. Hati-hati dengan regex DDoS, ini adalah tempat di mana Anda bisa mendapat masalah. Dan ini terkait dengan hal ketiga yang saya lakukan, saya membatasi berapa lama saya mau memproses satu email. Jika perlu memperlambat mesin saya untuk mendapatkan validasi - itu tidak melewati logika endpoint API data yang masuk saya.

Sunting: Jawaban ini terus mendapatkan dinged karena "buruk", dan mungkin layak mendapatkannya. Mungkin itu masih buruk, mungkin tidak.


2
Saya kira jawaban ini diturunkan karena ini adalah pendapat, dan sebenarnya tidak menjawab pertanyaan. Selain itu, pengguna yang mendapatkan alamat email mereka secara diam-diam tidak akan pernah menerima email dari Anda. Anda sebaiknya memberi tahu mereka bahwa alamat email mereka tidak diterima.
vcarel

2
Saya menduga downvotesnya adalah karena ada terlalu banyak ide di sini. Daftar yang dilarang, meskipun ini adalah tes unit yang berguna, harus diawali dengan apa yang diizinkan. Pendekatan pemrograman tampaknya relatif baik-baik saja, tetapi, mungkin akan lebih cocok setelah Anda mencantumkan spesifikasi yang Anda kerjakan, dll. Bagian dan penyuntingan yang ringan akan membantu. Hanya 2 sen saya.
HoldOffHunger

@vcarel - Oh, tentu saja. Validasi sisi pengguna front-end akan memberi tahu mereka aturan apa (tersedia dari tooltip) yang mereka langgar. Anda benar - ini adalah opini keseluruhan. Namun, pertanyaan di atas adalah dari seseorang yang menanyakan X untuk pertanyaan Y pasti. Ini adalah panduan dan berfungsi ... tidak hanya berfungsi, tetapi bekerja dengan baik. Saya tidak membiarkan alamat email omong kosong di sistem saya tempat saya mengambil keputusan.
BradChesney79

@HoldOffHunger Saya dapat melihat bahwa ide keseluruhan tidak dinyatakan secara koheren seperti yang seharusnya, saya dapat merevisi hari lain di mana saya memiliki lebih banyak waktu untuk mengekspresikannya dengan lebih baik. Terima kasih atas wawasannya.
BradChesney79

-1

Di PHP saya, saya menggunakan cek ini

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[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_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

coba sendiri http://phpfiddle.org/main/code/9av6-d10r


-1

Saya membuat regex ini sesuai dengan pedoman RFC:

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

1
Versi ini meningkatkan regex dengan memeriksa panjang domain / subdomain. Nikmati! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? (?: \\. [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

Gmail hanya akan mengizinkan tanda + sebagai karakter khusus dan dalam beberapa kasus (.) Tetapi karakter khusus lainnya tidak diizinkan di Gmail. RFC's mengatakan bahwa Anda dapat menggunakan karakter khusus tetapi Anda harus menghindari mengirim email ke Gmail dengan karakter khusus.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.