Zastanawiam się, jak daleko ludzie powinni przeprowadzić weryfikację adresu e-mail. Moja dziedzina to przede wszystkim tworzenie stron internetowych, ale dotyczy to wszędzie.

Widziałem kilka podejść:

• po prostu sprawdzając, czy jest obecny znak „@”, który jest bardzo prosty, ale oczywiście nie tak niezawodny.
• bardziej złożony test wyrażenia regularnego dla standardowych formatów e-mail
• pełny regex przed RFC 2822 - problem polega na tym, że często adres e-mail może być ważne, ale to nie jest chyba to, co użytkownik rozumie
• Sprawdzanie poprawności DNS
• Sprawdzanie poprawności SMTP

Jak wiele osób może wiedzieć (ale wielu nie wie), adresy e-mail mogą mieć wiele dziwnych odmian, których większość ludzi zwykle nie bierze pod uwagę (patrz RFC 2822 3.4.1 ), ale musisz pomyśleć o celach twoja walidacja: czy po prostu starasz się upewnić, że wiadomość e-mail może zostać wysłana na adres, czy też jest to, co użytkownik prawdopodobnie zamierzał podać (co jest mało prawdopodobne w wielu bardziej niejasnych przypadkach, w przeciwnym razie „ważnych” „adresy).

Rozważaną przeze mnie opcją jest po prostu ostrzeżenie o bardziej ezoterycznym adresie, ale nadal zezwalanie na przesłanie żądania, ale to jeszcze bardziej komplikuje formularz i większość użytkowników może się mylić.

Podczas gdy sprawdzanie poprawności DNS / sprawdzanie SMTP wydaje się bezproblemowe, przewiduję problemy, w których serwer DNS / serwer SMTP jest tymczasowo wyłączony, a użytkownik nie jest w stanie się gdzieś zarejestrować lub serwer SMTP użytkownika nie obsługuje wymaganych funkcji.

Jak niektórzy doświadczeni programiści mogą sobie z tym poradzić? Czy są jakieś inne podejścia niż te, które wymieniłem?

Edycja: Całkowicie zapomniałem najbardziej oczywistego ze wszystkich, wysyłając e-mail z potwierdzeniem! Dziękuję autorom odpowiedzi za wskazanie tego. Tak, ten jest dość niezawodny, ale wymaga dodatkowego wysiłku ze strony wszystkich zaangażowanych. Użytkownik musi pobrać wiadomość e-mail, a programista musi zapamiętać dane użytkownika, zanim nawet zostaną potwierdzone jako prawidłowe.

Nie ma w 100% wiarygodnego sposobu potwierdzenia prawidłowego adresu e-mail innego niż wysłanie wiadomości e-mail do użytkownika i oczekiwanie na odpowiedź, jak większość forów.

Wybrałbym prostą regułę sprawdzania poprawności „@”, a następnie wysłałem e-mail do użytkownika, aby potwierdzić jego adres e-mail.

Chociaż to moja osobista opinia ... Czekam na inne sugestie.

Jedna sugestia: nie odrzucaj adresów ze znakiem +. Odrzucanie ich jest denerwująco powszechne, ale jest to prawidłowy znak, a użytkownicy Gmaila mogą użyć adresu +label@gmail.com do łatwiejszego oznaczania i sortowania poczty przychodzącej.

W swoim poście wydaje się, że mówiąc „sprawdzanie poprawności SMTP” masz na myśli połączenie z serwerem i próbę wykonania RCPT TO, aby sprawdzić, czy jest akceptowany. Ponieważ odróżniasz go od faktycznego wysyłania wiadomości e-mail z potwierdzeniem, zakładam, że chcesz to zrobić zgodnie z działaniami użytkownika. Oprócz problemów, takich jak problemy z siecią, awarie DNS itp., Szara lista może siać spustoszenie za pomocą tej metody. Metody są różne, ale zasadniczo szara lista zawsze odkłada pierwszą próbę dostarczenia do odbiorcy dla każdego podłączonego adresu IP. Jak powiedziałem, może się to różnić, niektóre hosty mogą odrzucać nieprawidłowe adresy przy pierwszej próbie i tylko odraczać prawidłowe adresy, ale nie ma niezawodnego sposobu na programowe uporządkowanie różnych implementacji.

Jedynym sposobem, aby upewnić się, że adres jest prawidłowy i został przesłany przez jego właściciela, który naprawdę chce, aby został użyty w Twojej aplikacji, jest wysłanie e-maila weryfikacyjnego. Cóż, dopóki nie zostanie odfiltrowany spam, tak sądzę =).

Inną słabością używania wyrażenia regularnego do sprawdzania poprawności wiadomości e-mail jest to, że prawie niemożliwe jest złapanie wszystkich prawidłowych domen najwyższego poziomu przy jednoczesnym odrzuceniu wszystkich niepoprawnych.

Na przykład podstawowe wyrażenie regularne w odpowiedzi Jeffa Atwooda:

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

zaakceptuje dowolną TLD złożoną z dwóch do czterech znaków. Na przykład .spam zostanie zaakceptowany, ale .museum i .travel (oba prawidłowe TLD) zostaną odrzucone.

Jeszcze jeden powód, dla którego lepiej jest poszukać @ i wysłać wiadomość e-mail z potwierdzeniem.

W przypadku międzynarodowych nazw domen prawie wszystko jest możliwe:

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

Jeśli chcesz wykonać jakieś testy, najpierw przekonwertuj go na punycode.

Bez kodu kreskowego wszystko co powinieneś zrobić, to przetestować, czy:

• jest co najmniej jeden @
• jest co najmniej jedną postacią w części lokalnej
• to co najmniej jedna kropka w części domeny
• ma co najmniej cztery znaki w domenie (zakładając, że nikt nie ma adresu w tld, że tld ma co najmniej 2 znaki)

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

Najlepiej po prostu sprawdź proste rzeczy, takie jak @ i. w JavaScript, a następnie wyślij im weryfikację na swój adres e-mail. Jeśli zweryfikują oni swoje konto, masz poprawny adres e-mail. W ten sposób wiesz na pewno, że masz działający adres i nie musisz być zbyt apodyktyczny w formularzu.

Użyj walidatora typu open source, który nie daje fałszywych negatywów. Zero wysiłku dla Ciebie i niezawodne sprawdzanie poprawności aplikacji.

Teraz zestawiłem przypadki testowe z Cal Henderson, Dave Child, Phil Haack, Doug Lovell i RFC 3696. W sumie 158 adresów testowych.

Przeprowadziłem wszystkie testy w stosunku do wszystkich walidatorów, jakie mogłem znaleźć. Porównanie znajduje się tutaj: http://www.dominicsayers.com/isemail

Postaram się aktualizować tę stronę, gdy ludzie ulepszają swoje moduły sprawdzające poprawność. Dziękuję Calowi, Dave'owi i Philowi ​​za ich pomoc i współpracę przy opracowywaniu tych testów oraz konstruktywną krytykę mojego własnego weryfikatora .

Ludzie powinni być świadomi erraty w szczególności przeciwko RFC 3696 . Trzy z kanonicznych przykładów są w rzeczywistości nieprawidłowymi adresami. Maksymalna długość adresu to 254 lub 256 znaków, a nie 320.

Po rozważeniu odpowiedzi (ponieważ całkowicie zapomniałem o wiadomościach e-mail z potwierdzeniem) wydaje mi się, że odpowiednim rozwiązaniem dla rozwiązania o niskim współczynniku tarcia byłoby:

1. Użyj wyrażenia regularnego, aby sprawdzić, czy adres e-mail wygląda na prawidłowy, i ostrzeż, jeśli jest bardziej niejasny, ale unikaj całkowitego odrzucania.
2. Użyj sprawdzania poprawności SMTP, aby upewnić się, że adres e-mail jest prawidłowy.
3. Jeśli sprawdzanie poprawności SMTP nie powiedzie się, to - i tylko wtedy - użyj e-maila potwierdzającego w ostateczności. Wiadomości e-mail z potwierdzeniem wydają się wymagać zbyt dużej interakcji poza aplikacją, aby można je było uznać za małe tarcie, ale są idealnym rozwiązaniem zastępczym.

RegexBuddy oferuje w swojej bibliotece następujące wyrażenia regularne związane z pocztą e-mail:

Adres e-mail (podstawowy)

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

Adres e-mail (RFC 2822, uproszczony)

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

Ale zazwyczaj zgadzam się z odpowiedziami Petera i SuperJoe; jedynym prawdziwym „testowaniem” jest w rzeczywistości wysłanie e-maila potwierdzającego.

Pracowałem w 4 różnych firmach, w których ktoś z biura pomocy został wykrzyczany przez osobę o imieniu O'Malley lub O'Brien lub inny adres e-mail z apostrofem. Jak sugerowano poprzednio, nie wszystkie wyrażenia regularne złapią wszystko, ale oszczędzaj sobie kłopotów i zaakceptuj apostrof bez generowania ostrzeżenia.

-
bmb

Możesz przejść dalej sprawdzanie poprawności wiadomości e-mail, aby faktycznie sprawdzić, czy istnieje skrzynka pocztowa. Ta technika ma swoje wady (czas opracowywania, a także możliwość umieszczenia na czarnej liście za niewłaściwe użycie). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Jeśli chcesz zweryfikować wiadomość e-mail (tzn. Upewnić się, że użytkownik jest właścicielem adresu e-mail), wiadomość e-mail z potwierdzeniem jest jedyną rzeczą, którą możesz zrobić. Z drugiej strony wiele osób ma dedykowane adresy spamowe lub korzysta z usług takich jak OneWayMail, a jeśli nie chcą podać rzeczywistego adresu e-mail, nie zrobią tego. Zasadniczo tworzysz przeszkodę dla użytkownika.

Jeśli chodzi o sprawdzanie poprawności , aby upewnić się, że użytkownik nie przypadkowo wprowadzi nieprawidłowy adres e-mail, jest to z pewnością właściwa motywacja. Jednak przynajmniej w przypadku formularzy HTML (które są zdecydowanie najczęstszym sposobem zbierania adresów e-mail), nie jest to właściwy instrument.

Po pierwsze, nie będziesz w stanie rozpoznać literówek w rzeczywistych „słowach” adresu e-mail. Nie masz możliwości stwierdzenia, że back2dso@example.comjest źle, wyłącznie na podstawie formatu.
Co ważniejsze, z punktu widzenia użytkownika istnieje tylko jeden (lub ręka pełna) adresów e-mail, które możesz chcieć wprowadzić. I prawdopodobnie już to wpisałeś.
Zamiast więc sprawdzać poprawność adresu, powinieneś skupić się na upewnieniu się, że wszystkie przeglądarki rozpoznają pole e-mail, a tym samym eliminują potrzebę wpisywania adresu e-mail w pierwszej kolejności. Oczywiście nie ma to zastosowania, jeśli budujesz witrynę, która może zostać trafiona przez użytkowników, którzy nigdy wcześniej nie wprowadzili swojego adresu e-mail w przeglądarce. Ale przypuszczam, że najmniej z nas jest w takiej sytuacji.

Myślę, że to zależy od kontekstu, w którym używasz e-maila. Poważniejsze projekty wymagają ściślejszej weryfikacji, ale myślę, że w większości przypadków wysłanie wiadomości e-mail na podany adres z linkiem potwierdzającym zapewni poprawność adresu e-mail.

@ Mike - Myślę, że jedną z przyczyn, dla których wysyłane są wiadomości e-mail z potwierdzeniem, jest nie tylko upewnienie się, że adres e-mail jest prawidłowy, ale że jest on dostępny dla użytkownika, który go przesłał. Osoba może łatwo wpisać literową literówkę w adresie e-mail, która prowadziłaby do innego, prawidłowego adresu e-mail, ale nadal byłby to błąd, ponieważ byłby to zły adres.

Najbardziej kompletnym i dokładnym wyrażeniem regularnym, jakie kiedykolwiek spotkałem do sprawdzania poprawności wiadomości e-mail, jest tutaj udokumentowane . To nie jest dla osób o słabym sercu; jest na tyle skomplikowany, że jest podzielony na części, aby ułatwić analizowanie przez ludzi (przykładowy kod znajduje się w Javie). Ale w przypadkach, w których zasługuje się na sprawdzanie poprawności, nie sądzę, aby było znacznie lepiej.

W każdym razie sugerowałbym skorzystanie z testów jednostkowych, aby potwierdzić, że Twoje wyrażenie obejmuje przypadki, które uważasz za ważne. W ten sposób, kiedy się nim zajmiesz, możesz być pewien, że nie złamałeś żadnej sprawy, która wcześniej działała.

Cokolwiek wybierzesz, myślę, że trzeba błądzić po stronie wierząc, że 99% czasu, użytkownik ma rzeczywiście wiedzieć, co ich adres e-mail jest. Jako ktoś z Australii wciąż bardzo rzadko znajduję tak bardzo sprytną weryfikację adresu e-mail, która mówi mi, że nie mogę mieć domeny .com.au. To zdarzało się znacznie więcej we wczesnych dniach Internetu.

Wysłanie wiadomości e-mail z potwierdzeniem w tych dniach jest akceptowalne dla użytkowników, a także przydatne pod względem zgody i weryfikacji dostarczonego adresu.

W niektórych witrynach opracowanych w miejscach, w których pracowałem, zawsze korzystaliśmy z wiadomości e-mail z potwierdzeniem. Jednak zaskakująco często użytkownicy błędnie wpisywali swój adres e-mail w sposób, który nie mógł działać, a następnie czekali na wiadomość e-mail z potwierdzeniem, która nie nadejdzie. Dobrym pomysłem może być dodanie kodu ad-hoc (lub, w przypadku nazwy domeny, weryfikacji DNS), aby ostrzec użytkownika w takich przypadkach.

Typowe przypadki, które widziałem:

• Upuszczenie litery na środku nazwy domeny lub kilku innych prostych wariantów literówek.
• Zamieszanie TLD (na przykład dodanie a .brdo .comdomeny lub usunięcie .brz .com.brdomeny).
• Dodanie www.na początku lokalnej części adresu e-mail (nie robię tego; widziałem kilka adresów e-mail formularza www.username@example.com).

Były jeszcze bardziej dziwne przypadki; rzeczy takie jak pełna nazwa domeny jako część lokalna, adresy z dwoma @(coś w rodzaju username@domain.tld@example.com) i tak dalej.

Oczywiście większość z nich wciąż była poprawnymi adresami RFC-822, więc technicznie możesz po prostu pozwolić MTA sobie z nimi poradzić. Jednak ostrzeżenie użytkownika, że ​​podany adres e-mail jest prawdopodobnie fałszywy, może być pomocne, szczególnie jeśli twoi odbiorcy nie są zbyt biegli w obsłudze komputera.

Cała walidacja wyrażeń regularnych na świecie nie uniemożliwia komuś wprowadzenia nieprawidłowego lub fałszywego adresu e-mail. To naprawdę denerwujące.

Zależy od celu. Jeśli jesteś dostawcą usług internetowych i musisz potwierdzić, że użytkownicy tworzą prawidłowe adresy e-mail, skorzystaj z Regex, który weryfikuje wszystko, co możliwe. Jeśli chcesz tylko złapać błędy użytkownika, co powiesz na następujący wzorzec:

[Wszystkie znaki, bez spacji] @ [litery i cyfry] (. [Litery i cyfry]), gdzie grupa końcowa pojawia się co najmniej raz.

RegEx dla tego wygląda następująco:

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

Aby się upewnić, wyślij wiadomość e-mail z potwierdzeniem.

@ Yaakov (mógłby odpowiedzieć tutaj z pewnego rodzaju „odpowiedzią” tutaj)

Myślę, że jednym z powodów, dla których wysyłane są e-maile potwierdzające, jest nie tylko upewnienie się, że adres e-mail jest prawidłowy, ale że jest on dostępny dla użytkownika, który go przesłał. Osoba może łatwo wpisać literową literówkę w adresie e-mail, która prowadziłaby do innego, prawidłowego adresu e-mail, ale nadal byłby to błąd, ponieważ byłby to zły adres.

Zgadzam się, ale nie jestem pewien, czy warto. W tym celu mamy również pola potwierdzające (powtórz swój adres e-mail). Inna sytuacja, w której typ witryny może uzasadniać różne podejścia.

Ponadto samo wysłanie wiadomości e-mail z potwierdzeniem nie oznacza, że ​​oryginalny użytkownik podał nieprawidłowy adres, który podał. Po nieotrzymaniu wiadomości e-mail z potwierdzeniem mogą po prostu założyć, że aplikacja / witryna jest wadliwa; przynajmniej umożliwiając użytkownikowi natychmiastowe rozpoczęcie korzystania z konta, mogą poprawić swój adres e-mail, szczególnie jeśli jest wyświetlany w odpowiednio oczywistym miejscu.

Konie na kursy.

Wszystkie te są ważne, kompletne i same w sobie systemy weryfikacji e-mail, a dla danej witryny jeden będzie bardziej odpowiedni (lub tak dobry, jak to uzasadnione) niż inne. W wielu przypadkach przydatne może być kilka etapów weryfikacji.

Jeśli tworzysz witrynę internetową dla banku, będziesz chciał mieć pocztę ślimakową lub weryfikację telefoniczną.

Jeśli tworzysz witrynę internetową do konkursu, możesz nie chcieć żadnego z nich - zweryfikuj wiadomości e-mail w trakcie przetwarzania końcowego, a jeśli jeden się nie powiedzie, to źle dla osoby, która do niego weszła - możesz docenić wydajność serwera, biorąc pod uwagę ogromną liczbę osób ( Na przykład w konkursie telewizyjnym), aby upewnić się, że wszyscy zostaną poprawnie zweryfikowani.

Jak daleko należy zrobić weryfikację adresu e-mail?

O ile jest to konieczne i uzasadnione.

I nie ma dalej (KISS)

Widziałem strony, które również chronią przed osobami korzystającymi z tymczasowych stron typu spam, takich jak Mailinator lub MyTrashMail , które omijają wiadomość e-mail z potwierdzeniem. Nie mówię, że powinieneś je odfiltrowywać, po prostu mówię.

Co próbujesz złapać podczas sprawdzania poprawności wiadomości e-mail?

Sprawdzanie poprawności adresów e-mail przez Regex może w najlepszym wypadku zweryfikować, czy adres jest poprawny pod względem składniowym i względnie wiarygodny. Grozi to również (jak już wspomniano wiele razy) możliwym odrzuceniem rzeczywistych adresów możliwych do dostarczenia, jeśli wyrażenie regularne nie jest całkiem poprawne.

Weryfikacja SMTP może ustalić, że adres jest możliwy do dostarczenia, z zastrzeżeniem ograniczeń nałożonych przez szarą listę lub serwery, które są skonfigurowane tak, aby udzielały jak najmniej informacji o swoich użytkownikach. Nie możesz wiedzieć, czy MTA twierdzi, że przyjmuje pocztę tylko pod fałszywym adresem, a potem po prostu rzuciła ją na podłogę w ramach strategii antyspamowej.

Wysłanie wiadomości potwierdzającej jest jednak jedynym sposobem na sprawdzenie, czy adres należy do użytkownika, który go wprowadził. Jeśli wypełniam formularz, mogę dość łatwo powiedzieć, że mój adres e-mail to president@whitehouse.gov. Wyrażenie regularne powie ci, że jest poprawne pod względem składniowym, a SMTP RCPT TO powie ci, że jest to adres dostarczalny, ale na pewno nie jest to mój adres.

Wraz z nadejściem HTML5 do możliwości dodano co najmniej jedno nowe podejście: użycie danych wejściowych typu „ e-mail ”, które pozwalają na sprawdzenie poprawności po stronie klienta. Obecne wersje Firefox, Chrome, Safari i Opera obsługują to (a inne przeglądarki traktują to jak typ = tekst, dzięki czemu można z niego korzystać bez problemów, mimo że oczywiście nie ma się sprawdzania poprawności).

Nie może nigdy (jak już kilkakrotnie podkreślono) zagwarantować sprawny adres, ale może być bardzo korzystny (i ewentualnie zastąpić kontrolę po stronie serwera) w miejscach, w których wystarczy złapać prawdopodobne błędy użytkownika.

Trzy główne poziomy sprawdzania poprawności wiadomości e-mail:

1) sprawdź wyrażenie regularne pod kątem poprawnie sformatowanego adresu e-mail email@email.com

2) sprawdź domenę e-mail z rekordami MX, aby sprawdzić, czy nazwa domeny ma usługę e-mail

3) wysłanie wiadomości e-mail z potwierdzeniem z linkiem lub kodem potwierdzającym

Poziom 1:

W Visual Studio możesz użyć „Walidatora wyrażeń regularnych”. A we właściwości „ValidationExpression” możesz kliknąć przycisk „...”, który ma kreatora do dodania w formacie wyrażeń regularnych dla adresów e-mail.

Poziom 2:

Oto mój kod C # poniżej, aby użyć nslookup do sprawdzenia, czy domena e-mail ma prawidłowe rekordy MX. Działa szybko i dobrze w systemach Windows 2008 R2 i 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

Inną opcją jest użycie pakietu nuget Arsofttools, ale może być powolny w systemie Windows Server 2008 R2, jak zauważyłem, ale działa szybko na Win 7.

Poziom 3:

W celu potwierdzenia adresu e-mail możesz wygenerować adres URL heksadecymalny (używając funkcji szyfrowania) itp. Http://domain.com/validateEmail?code=abcd1234, aby sprawdzić poprawność adresu e-mail, gdy użytkownik go kliknie. Nie ma potrzeby przechowywania tego adresu URL w pamięci.