Bir kişi e-posta adresi doğrulamasını ne kadar sürmelidir?


101

İnsanların e-posta adresinin onaylanmasını ne kadar uzağa götürmeleri gerektiğini merak ediyorum. Alanım öncelikle web geliştirme, ancak bu her yerde geçerlidir.

Birkaç yaklaşım gördüm:

  • basitçe "basit" bir hediye olup olmadığını kontrol etmek, ki ölü basit ama tabii ki o kadar güvenilir değil.
  • standart e-posta formatları için daha karmaşık bir regex testi
  • Bir tam regex karşı RFC 2822 - Bu sorun genellikle bir e-posta adresi geçerli olabileceğini ama muhtemelen kullanıcı ne anlama geldiğini değil
  • DNS doğrulama
  • SMTP doğrulama

Birçok insanın bildiği gibi (ancak çoğu kişi bilmez), e-posta adresleri çoğu insanın genellikle göz önünde bulundurmadığı birçok garip değişkenliğe sahip olabilir (bkz. RFC 2822 3.4.1 ), ancak Doğrulama: Sadece bir e-posta mesajının bir adrese gönderilebileceğini veya kullanıcının muhtemelen koymak istediği şeyin (başka türlü 'geçerli olan daha belirsiz olan durumların pek çoğunda bulunmadığını) garanti etmeye mi çalışıyorsun?' 'adres).

Düşündüğüm bir seçenek sadece daha ezoterik bir adrese sahip bir uyarı veriyor, ancak isteğin devam etmesine izin veriyor, ancak bu bir forma daha fazla karmaşıklık katıyor ve çoğu kullanıcının kafası karışabilir.

DNS doğrulama / SMTP doğrulama beyninde olmayanlara benziyor olsa da, DNS sunucusu / SMTP sunucusunun geçici olarak kapalı kaldığı ve bir kullanıcının bir yere kayıt yapamadığı ya da kullanıcının SMTP sunucusunun gereken özellikleri desteklemediği sorunları öngörüyorum.

Buradaki bazı deneyimli geliştiriciler bunu nasıl ele alabilir? Listede bulunduğumdan başka yaklaşımlar var mı?

Düzenleme: Tamamen unuttum, onay e-postası gönderdim! Bunu işaret ettiği için cevap verenlere teşekkür ederiz. Evet, bu oldukça kusursuz, ancak katılan herkes için ekstra güçlük gerektiriyor. Kullanıcının bir e-posta alması gerekir ve geliştiricinin geçerli olarak onaylanmadan önce kullanıcı verilerini hatırlaması gerekir.


Şahsen adresin sahipliğini onaylamak için bir e-posta ile takip eden çift Regex Warn ve Reddet stratejisi ile giderdim.
James Snell

Büyük soru, adres için ne amaçla istediğinizi sormak. Örneğin, kullanıcıya bir doğrulama e-postası gönderecekseniz, o zaman çok basit bir kontrol yeterli olacaktır, çünkü muhtemelen kullanıcı geçerli bir adres vermeye motive olur.
SDsolar

Yanıtlar:


80

Kullanıcıya e-posta göndermek ve çoğu forumda olduğu gibi yanıt beklemek dışında geçerli bir e-posta adresini onaylamanın% 100 güvenilir bir yolu yoktur.

Basit "@" geçerlilik kuralı ile gideceğim ve ardından e-posta adresini onaylamak için kullanıcıya e-posta göndereceğim.

Buna rağmen, bu benim kişisel görüşüm ... Başka öneriler bekliyorum.


6
Tamamen katılıyorum. Ya bu adresi gerçekten umursuyorsun ya da umursamıyorsun. Yarı bakım için herhangi bir gerekçe göremiyorum.
Benjol

3
Şimdiye kadar en iyi cevap. @ Değerini doğrulayın , ardından adresi doğrulayın (bir e-posta ile) - buradaki küçük fark.
billy.bob

... bu yüzden çoğu forumun yaptığı bu.
Dan Ray,

@Billy Bob ile aynı fikirdeyim, doğrulama e-postası tarafından takip edilen basit bir onaylamanın e-postanın doğru olduğunu kanıtlamanın en etkili yolu olduğu konusunda hemfikirim.
SDsolar

“Geçerli” bir e-posta adresi de yanlış kişiye gidiyor olabilir, bu nedenle doğrulama e-postası gerçekten emin olmanın tek yoludur. Her biri, birileri benim için kendi e-posta adresini yanlış yazdığında onlardan birkaçını alıyorum.
axl

57

Bir öneri: İçinde + bulunan adresleri reddetmeyin. Onları reddetmek can sıkıcıdır, ancak geçerli bir karakterdir ve gmail kullanıcıları gelen postaları daha kolay etiketlemek ve sıralamak için address +label@gmail.com adresini kullanabilir.


8
+1 !!! Facebook'tan, tüm sitelerin e-postalarını filtrelemek imkansız görünüyor!
jnylen

Bu olmadan filtre edebilirsiniz - sadece kullanıcı gönderen bilgisi
Casebash

1
GMail, diğer posta sunucularından aldı. Qmail ve postfix'in popülerleştirdiğine inanıyorum.

23
Bu düşünceye katılsam da, bu soruyu cevaplamaya bile başlamıyor.
Bryan Oakley

29

Gönderinizde "SMTP doğrulama" derken, sunucuya bağlanmayı ve kabul edilip edilmediğini görmek için bir RCPT TO denemek istediğiniz anlamına geliyor. Bunu bir onay e-postası göndermekten farklı kıldığınız için, kullanıcı işlemleriyle aynı çizgide yapmak istediğinizi varsayıyorum. Ağ sorunları, DNS arızaları, vb. Gibi sorunlara ek olarak, gri liste bu yöntemle çok büyük zarara neden olabilir. Metodun değişkenliği vardır, fakat esasen gri liste her zaman IP başına bağlanan alıcıya ilk girişimi savunur. Dediğim gibi, bu değişkenlik gösterebilir, bazı ana bilgisayarlar geçersiz adresleri ilk denemede reddedebilir ve yalnızca geçerli adresleri erteleyebilir, ancak farklı uygulamaları programlı olarak sıralamanın güvenilir bir yolu yoktur.

Bir adresin geçerli olduğundan ve başvurunuz için gerçekten kullanılmasını isteyen sahibi tarafından gönderildiğinden emin olmanızın tek yolu bir doğrulama e-postası göndermektir. İstenmeyen postalardan filtrelenmediği sürece sanırım =).


25

E-posta doğrulama için bir regex kullanmanın bir diğer zayıflığı, tüm geçersiz olanları reddederken geçerli tüm üst düzey alan adlarını yakalamanın neredeyse imkansız olmasıdır .

Örneğin, Jeff Atwood'un cevabındaki temel e-posta regex'i:

B \ [A-Z, 0-9 ._% + -]. + '[A-Z, 0-9 .-] + [AZ] {2,4} \ B

iki ila dört karakterden oluşan herhangi bir TLD'yi kabul eder. Dolayısıyla, örneğin .spam kabul edilecek, ancak .museum ve .travel (her ikisi de geçerli TLD'ler) reddedilecek.

Sadece bir neden daha @ aramak ve bir onay e-postası göndermek daha iyidir.


24

Uluslararası alan adları ile hemen hemen her şey mümkündür:

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

Herhangi bir test yapmak istiyorsanız, önce onu punycode'a dönüştürmelisiniz.

Punycode olmadan yapmanız gereken tek şey orada test etmek için:

  • en az bir tane
  • yerel bölümde en az bir karakter
  • etki alanı bölümünde en az bir nokta
  • alandaki en az dört karakterdir (hiç kimsenin tld’de bir adresi olmadığını, tld’ün en az 2 karakter olduğunu varsayarak)
function isEmail(address) {
    var pos = address.lastIndexOf("@");
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}

1
Eğer aşağıdaki yanıtında kodu kullanabilirsiniz punycode dönüştürmek için javascript kullanmak isterseniz: stackoverflow.com/questions/183485/...

Yeterince doğru - o zaman @ işaretinin sağlanması bir e-posta adresi gibi "göründüğünden" emin olmanın tek yolu olabilir.
SDsolar

19

@ Ve gibi basit şeyleri kontrol etmekte en iyisin. JavaScript’te ve aslında e-postalarına bir doğrulama gönderir. Hesaplarını doğrularlarsa, kendinize geçerli bir e-posta adresiniz olur. Bu şekilde, çalışan bir adresiniz olduğundan emin olursunuz ve formda fazla otoriter olmanız gerekmez.


Bu harika bir çözüm. Burada bir @ ardında bir nokta ve ardından bir nokta aranacak bir regexp var:/.+@.+\..+/
Evan Moran

11

Yanlış negatif vermeyen açık kaynaklı bir doğrulayıcı kullanın. Sizin için sıfır çaba ve uygulamanız için sağlam doğrulama.

Şimdi Cal Henderson, Dave Child, Phil Haack, Doug Lovell ve RFC 3696'dan test vakaları derledim. Toplamda 158 test adresi.

Tüm bu testleri bulabildiğim bütün onaylayıcılara karşı koştum. Karşılaştırma burada: http://www.dominicsayers.com/isemail

İnsanlar doğrulayıcılarını geliştirirken bu sayfayı güncel tutmaya çalışacağım. Cal, Dave ve Phil'e bu testleri ve kendi validatörümün yapıcı eleştirilerini derlemedeki yardımları ve işbirlikleri için teşekkürler .

İnsanlar , özellikle RFC 3696'ya karşı olan bilgilerin farkında olmalıdır . Kanonik örneklerin üçü aslında geçersiz adreslerdir. Bir adresin maksimum uzunluğu 320 değil 254 veya 256 karakterdir .


Karşılaştırma bağlantısı aşağı :(
Zero3

10

Cevaplar göz önüne alındığında (onay e-postalarını tamamen unuttuğum için), düşük sürtünmeli bir çözüm için uygun bir uzlaşma gibi görünüyor:

  1. E-posta adresinin geçerli görünüp görünmediğini kontrol etmek için regex kullanın ve daha gizliyse ancak dürüst olmaktan kaçının.
  2. E-posta adresinin geçerli olduğundan emin olmak için SMTP doğrulamasını kullanın.
  3. SMTP doğrulama işlemi başarısız olursa - ve yalnızca o zaman - son çare olarak bir onay e-postası kullanın. Onay e-postaları, düşük sürtünme olarak kabul edilmeleri için başvurunuz dışında çok fazla etkileşim gerektiriyor gibi görünüyor, ancak mükemmel bir geri dönüş.

1
Bir kullanıcının onay göndermeden e-posta adresine sahip olduğunu nasıl kontrol edebilirsiniz? Örneğin, e-posta adresinizi yazdıklarını varsayalım. Geliştiricinin bir onay e-postası sağlamayacağına karar verdiğinden ve bu nedenle adresinizi bilen herhangi birinin sizi sitelerine kaydettirmesine izin vermez misiniz?
Rupert Madden-Abbott

1
SMTP doğrulaması? Sunucuya adresin olup olmadığını sorun. Spam uzun zaman önce ondan kurtuldu.

6

RegexBuddy , kütüphanesinden e-posta ile ilgili aşağıdaki normal ifadeleri sunar:

E-posta adresi (temel)

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

E-posta adresi (RFC 2822, basitleştirilmiş)

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

Fakat Peter ve SuperJoe'nin cevaplarına katılıyorum; tek gerçek "test" aslında bir doğrulama e-postası gönderiyor.


1
Temel e-posta kontrolünüz gibi şeylere karşı başarısız olur bob@mydivision.mycompany.com. Ayrıca yalnızca büyük harf ASCII kullandığınız için büyük küçük harf duyarlı bir eşleşme gerektiğini söylemelisiniz.
unpythonic

Neden büyük harfleri (ikinci regex ile) reddetmelisiniz? Yerel bölümün alıcı MTA’a kadar onaylanması gerekmiyor mu? Beyaz boşluk ve tırnak hariç.
Dirk Jäckel

@dirk işaretinin işaret ettiği gibi, çalıştırırken bu regex'e "büyük / küçük harfe duyarlı değildir" bayrağını uygularsınız.
Jeff Atwood

Birkaç tane TLD> 4 karakter olduğundan temel olanı iyi değil. En az 2, en fazla 2 {2,}
yapmam

4

Yardım masasındaki birinin O'Malley veya O'Brien adındaki biri veya kesme işareti olan başka bir e-posta adresi tarafından bağırdığı 4 farklı şirkette çalıştım. Daha önce önerildiği gibi, bütün regex'ler her şeyi yakalayamayacak, ancak biraz güçlük çekecek ve bir uyarı oluşturmadan bir kesme işareti kabul edeceksiniz.

-
bmb


Amin. Bu arada, karma işareti (#) için de geçerlidir.
Tomalak

2
İnsanların adlarında karma işaretleri bulunmaması, e-posta adreslerinde geçerli olmadıkları anlamına gelmez.
Dave Sherohman,


3

Bir e-postayı doğrulamak istiyorsanız (yani, kullanıcının e-posta adresine sahip olduğundan emin olun), onay e-postası yapabileceğiniz tek şeydir. O zaman yine birçok insan spam adresleri atadı veya OneWayMail gibi hizmetleri kullandı ve size gerçek e-posta adreslerini vermek istemiyorlarsa, kullanmayacaklar. Yani temelde kullanıcı engellemesini yaratıyorsunuz.

Doğrulama söz konusu olduğunda, kullanıcının istemeden yanlış bir e-posta adresi girmemesini sağlamak için kesinlikle doğru motivasyondur. Bununla birlikte, en azından HTML formları için (e-posta adreslerini toplamanın en yaygın yoludur), doğru yöntem değildir.

Birincisi, e-posta adresinin gerçek "kelimeleri" ndeki yazım hatalarını tanıyamazsınız. Bunun back2dso@example.comyanlış olduğunu, sadece biçime dayanarak bulma imkanınız yok.
Ancak daha da önemlisi, kullanıcı bakış açısından, girmek isteyebileceğiniz yalnızca bir tane (veya tamamen dolu) bir e-posta adresi vardır. Muhtemelen çoktan girmişsindir.
Bir adresi doğrulamaya çalışmak yerine, tüm tarayıcıların e-posta alanını tanımasını ve böylece e-posta adresini ilk etapta girme gereksinimini ortadan kaldırmasını sağlamaya odaklanmalısınız. Tabi bu geçerli değildir, eğer e-posta adreslerini daha önce tarayıcılarına hiç girmemiş kullanıcılar tarafından vurulacak türden bir site oluşturuyorsanız. Ama sanırım en azımız böyle bir durumda.


2

Bence, e-postayı hangi bağlam için kullandığınıza bağlı. Daha ciddi projeler daha katı onaylama gerektirir ancak bence bir konformasyon bağlantısı ile verilen adrese bir e-posta gönderenlerin çoğu e-posta adresinin geçerli olmasını sağlayacaktır.


2

@ Mike - Onay e-postalarının gönderilmesinin nedeninin bir kısmının yalnızca e-posta adresinin geçerli olduğundan emin olmak değil, aynı zamanda onu gönderen kullanıcı tarafından erişilebilir olmasını sağlamak olduğunu düşünüyorum. Bir kişi, e-posta adresinde farklı, geçerli bir e-posta adresine yol açacak tek harfli bir yazım hatası kolayca koyabilir, ancak bu yanlış adres olacağı için yine de bir hata olur .


2

Şimdiye kadar e-posta doğrulama için karşılaştığımız en eksiksiz ve doğru regex belgelenmiş biridir burada . Kalbin zayıflığı için değil; İnsanların ayrıştırılmasını kolaylaştırmak için parçalara bölünmesi yeterince karmaşıktır (örnek kod Java'dadır). Ancak, onaylama ile tüm yoldan gitmeye değer olduğu durumlarda, daha iyi olacağını sanmıyorum.

Her durumda, ifadenizin önemli olduğunu düşündüğünüz durumları kapsadığını doğrulamak için birim testini kullanmanızı öneririm. Bu şekilde, onunla birlikte dinkederken, daha önce işe yaramış bir davayı kırmadığınızdan emin olabilirsiniz.


2

Hangi seçeneği, sana zamanın% 99, kullanıcı inanarak tarafında err gerek yok aslında kendi e-posta adresi ne olduğunu biliyoruz. Avustralya’dan biri olarak, ara sıra, bir .com.au alan adına sahip olamayacağımı söyleyen çok akıllıca bir e-posta doğrulama buluyorum. İnternetin ilk günlerinde aklınıza daha çok gelirdi.

Bugünlerde bir onay e-postası göndermek kullanıcılar için kabul edilebilir bir durumdur ve aynı zamanda kaydolma ve verilen adreslerini doğrulama konusunda da yararlıdır.


2

Çalıştığım yerlerde geliştirilen bazı sitelerde, her zaman onay e-postaları kullandık. Bununla birlikte, kullanıcıların e-posta adreslerini muhtemelen çalışamayacak şekillerde yanlış yazmaları ve sonra gelmeyecek onay e-postasını beklemeye devam etmesi şaşırtıcı bir şekilde yaygındı. Bu durumlarda kullanıcıyı uyarmak için geçici kod eklemek (veya alan adı bölümü için DNS doğrulaması) iyi bir fikir olabilir.

Gördüğüm yaygın vakalar:

  • Etki alanı adının ortasına bir mektup bırakarak veya birkaç diğer basit yazım hatası varyantı.
  • TLD karmaşa (örneğin, bir ilave .brbir üzere .cometki alanı veya bırakarak .brbir gelen .com.bretki).
  • www.Bir e-posta adresinin yerel kısmının başına bir ekleme (Bunu telafi etmiyorum; formun birkaç e-posta adresini gördüm www.username@example.com).

Daha da tuhaf olaylar vardı; yerel kısım olarak tam bir etki alanı adı gibi @şeyler , iki (gibi bir şey username@domain.tld@example.com) ile adresleri vb.

Elbette, çoğu hala geçerli RFC-822 adresleriydi, bu yüzden teknik olarak MTA'nın onlarla ilgilenmesine izin verdiniz. Bununla birlikte, kullanıcıyı, girilen e-posta adresinin muhtemelen sahte olduğu konusunda uyarmak, özellikle hedef kitlenizin bilgisayar bilgisi olmadığında, yardımcı olabilir.


Bu sitelerdeki sorun gibi gözüküyor, kullanıcılar gerçekten anlamadıkları bilgileri girmek zorunda kaldılar. Her site, kullanıcıları için e-posta ile iletişim kurmasını gerektirmez, site için işleri kolaylaştırır.
bzlm

2

Dünyadaki tüm regex doğrulaması, birinin yanlış veya sahte bir e-posta adresi girmesini engellemez. Bu sadece can sıkıcı bir durum.


Hiç DeBounce Email Validation Tool'u denediniz mi? Bu servise bir göz atmanızı öneririm.
Iman Hejazi,

2

Hedefe bağlı. Bir ISS iseniz ve kullanıcıların geçerli e-posta adresleri oluşturduklarını doğrulamanız gerekiyorsa, mümkün olan her şeye karşı doğrulayan Regex'e gidin. Yalnızca kullanıcı hatalarını yakalamak istiyorsanız, aşağıdaki düzenden ne haber:

[Tüm Karakterler, boşluksuz] @ [harfler ve sayılar] (. [Harfler ve sayılar]) burada son grubun en az bir kez belirdiği yer.

Bunun için RegEx şöyle görünür:

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

Ve emin olmak için bir onay e-postası gönderin.


2
Bir yazım hatası var (yalnızca TLD olarak "w" ye izin vermek istemiyorsanız) ve alan adlarını tire (-) ile eşleştirmiyor. Bu daha iyi çalışır: [\ S] + @ [\ w -] + (. [\ W -] +) +

1

@ Yaakov (burada bir tür 'yanıtla' ile cevap verebilir)

Onay e-postalarının gönderilmesinin nedeninin bir kısmının sadece e-posta adresinin geçerli olduğundan emin olmak için değil, aynı zamanda gönderen kullanıcı tarafından erişilebilir olduğunu düşünüyorum. Bir kişi, e-posta adresinde farklı, geçerli bir e-posta adresine yol açacak tek harfli bir yazım hatası koyabilir, ancak bu yanlış adres olacağı için yine de bir hata olur.

Katılıyorum, ama buna değdiğinden emin değilim. Ayrıca bu amaçla onay alanlarımız var (e-posta adresinizi tekrar tekrar). Site türünün farklı yaklaşımlar gerektirdiği başka bir durum.

Ek olarak, bir onay e-postası gönderilmesi, orijinal kullanıcıya girdikleri adresin yanlış olduğunu göstermez. Onay e-postasını almadıktan sonra, uygulamanızın / sitenizin hatalı olduğunu varsayabilirler; en azından kullanıcının derhal hesabını kullanmaya başlamasını sağlayarak, özellikle uygun şekilde görünür bir yerde görüntüleniyorsa, e-posta adreslerini düzeltebilirler.


1

Kurslar için atlar.

Bunların tümü geçerlidir, kendileri ve kendileri için eksiksiz bir e-posta doğrulama sistemleridir ve verilen bir web sitesi için bir tanesi diğerlerinden daha uygun (veya garanti edildiği kadar iyi) olacaktır. Çoğu durumda, birkaç doğrulama aşaması faydalı olabilir.

Bir banka için bir web sitesi geliştiriyorsanız, bunların hepsine salyangoz postası veya telefon doğrulaması isteyeceksiniz.

Bir yarışma için bir web sitesi geliştiriyorsanız, bunlardan hiçbirini istemeyebilirsiniz - işlem sonrası e-postaları doğrulayın ve eğer biri başarısız olursa, giren kişi için çok kötüyse - sunucu performansına büyük bir insan sıkıntısı vererek değer verebilirsiniz ( Örneğin, TV yarışması) herkesin doğru satır içi olarak doğrulandığından emin olunması üzerine.

Bir kişi e-posta doğrulamasını ne kadar sürmelidir?

Gerektiği kadar ve garantili.

Ve başka yok (KISS)


1

Mailinator veya MyTrashMail gibi geçici e-posta spam kovası sitelerini kullanan ve onay e- postasıyla ilgilenen insanları da koruyan siteler gördüm . Bunları filtrelemelisin demiyorum, sadece söylüyorum.


E-posta onayında ne şekilde "dolaşıyor"? Hem Mailinator hem de MyTrashMail, aynı adrese gelen postaları kabul eder. Kullanıcı onları kontrol etmek için zahmet etmiyorsa, bu başka bir hikaye.
bzlm

1

E-posta doğrulamanızda ne yakalamaya çalışıyorsunuz?

E-posta adreslerinin regex doğrulaması, en azından, adresin sözdizimsel olarak doğru ve nispeten makul olduğunu doğrulayabilir. Ayrıca, eğer regex oldukça doğru değilse, fiili, teslim edilebilir adresleri reddetme tehlikesi vardır (daha önce de belirtildiği gibi).

SMTP doğrulaması, adresin verilebilir olduğunu, grilistin veya kullanıcıların hakkında mümkün olduğu kadar az bilgi vermek üzere yapılandırılmış sunucular tarafından uygulanan sınırlamalara tabi olduğunu belirleyebilir. MTA’nın sahte bir adres için posta kabul ettiğini iddia edip etmediğini, ardından bir anti-spam stratejisinin bir parçası olarak bıraktığınızı bilemezsiniz.

Ancak bir onay mesajı göndermek , bir adresin girmiş olan kullanıcıya ait olduğunu doğrulamanın tek yoludur. Formunuzu dolduruyorsam, size eposta adresimin oldukça kolay olduğunu söyleyebilirim president@whitehouse.gov. Bir regex size sözdizimsel olarak geçerli olduğunu söyleyecektir, bir SMTP RCPT TO size teslim edilebilir bir adres olduğunu söyleyecektir, ama kesinlikle benim adresim olmadığı kesin .


1

HTML5'in gelmesiyle birlikte, olasılıklara en az bir yeni yaklaşım eklenir: müşteri tarafında doğrulamaya olanak sağlayan ' email ' tipi girişin kullanılması . Firefox, Chrome, Safari ve Opera’nın şu anki sürümleri bunu destekliyor (ve diğer tarayıcılar sadece type = text gibi davranıyorlar, bu nedenle tabii ki onaylama işleminiz olmadıkça kullanılabilir.)

Hiçbir zaman (birkaç kez belirtildiği gibi) uygulanabilir bir adres garanti edemez, ancak olası kullanıcı hatalarını yakalamanız gereken yerlerde çok yararlı olabilir (ve sonunda sunucu tarafı kontrolünü değiştirir).


Firefox uygulaması <input type="email">HTMLElement: dxr.mozilla.org/mozilla-central/source/dom/html/...
TIFFON

0

Üç ana e-posta doğrulama seviyesi:

1) Düzgün bir biçimde biçimlendirilmiş bir e-posta adresi olup olmadığını düzenli bir şekilde kontrol edin.

2) Alan adının bir e-posta servisi olup olmadığını görmek için MX kayıtlarını kontrol edin.

3) bir onay linki veya kodu içeren bir onay e-postası göndermek

Seviye 1:

Visual Studio'da "Normal İfade Doğrulayıcısı" nı kullanabilirsiniz. Ve "ValidationExpression" özelliğinde, e-posta adresleri için normal ifade biçiminde eklenecek bir sihirbazı olan "..." düğmesini tıklayabilirsiniz.

Seviye 2:

İşte bir e-posta etki alanının geçerli MX kayıtları olup olmadığını doğrulamak için nslookup'ı kullanmak için aşağıdaki C # kodum. Win 2008 R2 ve Win 7'de hızlı ve iyi çalışır.

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

Başka bir seçenek de Arsofttools nuget paketini kullanmak, ancak Windows Server 2008 R2'de deneyimledim ancak Win 7'de hızlı çalıştığı için yavaş olabilir.

3. seviye:

E-posta onayı için, ya bir e-posta belirli altıgen url (şifreleme işlevlerini kullanarak) vb üretebilir http://domain.com/validateEmail?code=abcd1234 kullanıcı tıkladığında e-posta adresini doğrulamak için. Bu url'yi bellekte depolamaya gerek yoktur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.