Мне интересно, как далеко люди должны пройти проверку адреса электронной почты. Моя область - это, прежде всего, веб-разработка, но это применимо везде.

Я видел несколько подходов:

• просто проверить, есть ли «@», что очень просто, но, конечно, не так надежно.
• более сложный тест регулярных выражений для стандартных форматов электронной почты
• полное регулярное выражение против RFC 2822 - проблема с этим состоит в том , что часто электронной почты может быть действительным , но это, вероятно , не то , что имел в виду пользователь
• Проверка DNS
• Проверка SMTP

Как многие люди могут знать (но многие не знают), адреса электронной почты могут иметь много странных изменений, которые большинство людей обычно не учитывают (см. RFC 2822 3.4.1 ), но вы должны подумать о целях Ваша проверка: вы просто пытаетесь убедиться, что электронное сообщение может быть отправлено на адрес, или это то, что пользователь, вероятно, хотел ввести (что маловероятно во многих более неясных случаях «действительного») адреса).

Вариант, который я рассмотрел, - просто выдавать предупреждение с более эзотерическим адресом, но при этом разрешать выполнение запроса, но это усложняет форму, и большинство пользователей могут запутаться.

В то время как проверка DNS / проверка SMTP кажутся простыми, я предвижу проблемы, когда DNS-сервер / SMTP-сервер временно недоступен, и пользователь не может где-то зарегистрироваться или SMTP-сервер пользователя не поддерживает требуемые функции.

Как некоторые опытные разработчики могут справиться с этим? Есть ли другие подходы, кроме тех, которые я перечислил?

Изменить: я полностью забыл самое очевидное из всех, отправив подтверждение по электронной почте! Спасибо ответчикам за то, что указал на это. Да, этот довольно надежный, но требует дополнительных хлопот со стороны всех участников. Пользователь должен получить какое-то электронное письмо, а разработчику необходимо запомнить пользовательские данные, прежде чем они будут подтверждены как действительные.

Не существует 100% надежного способа подтверждения действительного адреса электронной почты, кроме отправки электронного письма пользователю и ожидания ответа, как на большинстве форумов.

Я бы пошел с простым правилом проверки "@" и затем отправил бы электронное письмо пользователю, чтобы подтвердить его адрес электронной почты.

Хотя, это мое личное мнение ... Я жду других предложений.

Одно предложение: не отклоняйте адреса с + в них. К сожалению, их часто отклоняют, но это допустимый символ, и пользователи gmail могут использовать address+label@gmail.com для более легкой маркировки и сортировки входящей почты.

В вашем посте кажется, что когда вы говорите «SMTP validation», вы имеете в виду подключение к серверу и попытку RCPT TO проверить, принято ли это. Поскольку вы отличаете его от фактической отправки письма с подтверждением, я предполагаю, что вы хотите сделать это в соответствии с действиями пользователя. Помимо таких проблем, как проблемы с сетью, сбои DNS и т. Д., Этот метод может нанести ущерб «серому» списку. Методы различаются, но, по сути, серый список всегда откладывает первую попытку доставки получателю по соединяющемуся IP. Как я уже сказал, это может варьироваться, некоторые хосты могут отклонять недопустимые адреса с первой попытки и только откладывать действительные адреса, но нет надежного способа сортировки различных реализаций программно.

Единственный способ убедиться, что адрес является действительным и представлен его владельцем, который действительно хочет, чтобы он использовался для вашего приложения, - это отправить электронное письмо с подтверждением. Ну, пока это не фильтруется спам, я думаю =).

Еще один недостаток использования регулярных выражений для проверки электронной почты состоит в том, что почти невозможно отловить все действительные домены верхнего уровня , отклоняя все недействительные.

Например, основное регулярное выражение электронной почты в ответе Джеффа Этвуда:

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

будет принимать любой TLD от двух до четырех символов. Так, например, .spam будет принят, но .museum и .travel (оба действительных TLD) будут отклонены.

Еще одна причина, по которой лучше просто найти @ и отправить электронное письмо с подтверждением.

С международными доменными именами возможно практически все:

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

Если вы хотите сделать какие-либо тесты, вы должны сначала преобразовать его в punycode.

Без punycode все, что вам нужно сделать, это проверить, что там:

• хотя бы один @
• хотя бы один символ в локальной части
• хотя бы одна точка в доменной части
• по крайней мере четыре символа в домене (при условии, что никто не имеет адреса в tld, что tld составляет не менее 2 символов)

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

Лучше всего проверять простые вещи, такие как @ и. в JavaScript, а затем фактически отправьте им подтверждение на их электронную почту. Если они подтвердят свою учетную запись, у вас есть действующий адрес электронной почты. Таким образом, вы точно знаете, что у вас есть рабочий адрес, и вам не нужно быть слишком властным в форме.

Используйте валидатор с открытым исходным кодом, который не дает ложных негативов. Нулевое усилие для вас и надежная проверка для вашего приложения.

Сейчас я сопоставил контрольные примеры от Кэла Хендерсона, Дейва Чайлда, Фила Хаака, Дуга Ловелла и RFC 3696. Всего 158 тестовых адресов.

Я провел все эти тесты со всеми валидаторами, которые смог найти. Сравнение здесь: http://www.dominicsayers.com/isemail

Я постараюсь обновлять эту страницу по мере того, как люди улучшат свои валидаторы. Спасибо Кэлу, Дэйву и Филу за помощь и сотрудничество в составлении этих тестов и конструктивную критику моего собственного валидатора .

Люди должны знать об ошибках в RFC 3696 в частности. Три из канонических примеров на самом деле являются недействительными адресами. И максимальная длина адреса составляет 254 или 256 символов, а не 320.

Принимая во внимание ответы (поскольку я полностью забыл о подтверждающих письмах), мне кажется, что подходящим компромиссом для решения с низким коэффициентом трения будет:

1. Используйте regex, чтобы проверить, что адрес электронной почты выглядит правильно, и дать предупреждение, если он более неясен, но избегайте прямого отклонения.
2. Используйте проверку SMTP, чтобы убедиться, что адрес электронной почты действителен.
3. Если проверка SMTP не проходит, тогда - и только тогда - используйте подтверждение по электронной почте в качестве крайней меры. Подтверждающие электронные письма, кажется, требуют слишком много взаимодействия за пределами вашего приложения, чтобы их можно было считать малыми, но они являются идеальным запасным вариантом.

RegexBuddy предлагает следующие регулярные выражения, связанные с электронной почтой, из своей библиотеки:

Адрес электронной почты (основной)

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

Адрес электронной почты (RFC 2822, упрощенный)

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

Но я склонен согласиться с ответами Питера и СуперДжоя; единственное реальное «тестирование» - это отправка письма с подтверждением.

Я работал в 4 разных компаниях, где на кого-то из службы поддержки кричал кто-то по имени О'Мэлли или О'Брайен или по другому адресу электронной почты с апострофом. Как указывалось ранее, не все регулярные выражения поймают все, но избавят себя от хлопот и примут апостроф без предупреждения.

-
Bmb

Вы можете продолжить проверку электронной почты, чтобы проверить, существует ли почтовый ящик. Эта методика имеет свои недостатки (время разработки, а также возможность попадания в черный список за неправильное использование). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Если вы хотите проверить электронную почту (т.е. убедиться, что пользователь владеет адресом электронной почты), единственное, что вы можете сделать, - это подтверждение по электронной почте. С другой стороны, многие люди имеют выделенные спам-адреса или пользуются такими услугами, как OneWayMail, и если они не хотят давать вам свой фактический адрес электронной почты, они не будут. В общем, вы создаете препятствие для пользователя.

Когда дело доходит до проверки , чтобы гарантировать, что пользователь случайно не введет неправильный адрес электронной почты, это определенно правильная мотивация. Однако, по крайней мере, для HTML-форм (которые являются наиболее распространенным способом сбора адресов электронной почты), вряд ли это правильный инструмент.

Во-первых, вы не сможете распознать опечатки в реальных «словах» адреса электронной почты. У вас нет способа узнать, что back2dso@example.comэто неправильно, исключительно на основе формата.
Но что еще более важно, с точки зрения пользователя, есть только один (или полный набор) адресов электронной почты, которые вы, возможно, захотите ввести. И вы, вероятно, уже ввели это.
Поэтому вместо того, чтобы пытаться проверить адрес, вы должны сосредоточиться на том, чтобы все браузеры распознавали поле электронной почты и тем самым исключали необходимость ввода адреса электронной почты в первую очередь. Конечно, это не относится к ситуации, если вы создаете сайт, на который наверняка попадут пользователи, которые никогда ранее не вводили свой адрес электронной почты в свой браузер. Но я полагаю, что наименьшее из нас находится в таком положении.

Я думаю, это зависит от того, в каком контексте вы используете электронную почту. Более серьезные проекты требуют более строгой проверки, но я думаю, что в большинстве случаев отправка электронного письма на указанный адрес со ссылкой для подтверждения будет гарантировать, что адрес электронной почты будет действительным.

@ Майк - я думаю, что одна из причин, по которой письма с подтверждением отправляются, заключается не только в том, что адрес электронной почты является действительным, но и в том, что он доступен пользователю, который его отправил. Человек может легко вставить опечатку из одной буквы в адрес электронной почты, которая приведет к другому, действительному адресу электронной почты, но это все равно будет ошибкой, поскольку это будет неправильный адрес.

Наиболее полное и точное регулярное выражение, с которым я когда-либо сталкивался при проверке электронной почты, - это документально подтвержденное здесь . Это не для слабонервных; это достаточно сложно, чтобы разбить на части, чтобы людям было легче разбирать (пример кода на Java). Но в тех случаях, когда необходимо пройти весь путь с валидацией, я не думаю, что это станет намного лучше.

В любом случае, я бы предложил вам использовать модульное тестирование, чтобы подтвердить, что ваше выражение охватывает случаи, которые вы считаете важными. Таким образом, по мере того, как вы обдумываете это, вы можете быть уверены, что не разбили какой-то случай, который работал раньше.

Что бы вы ни выбрали, я думаю , что вам нужно заблуждаться на стороне , полагая , что 99% времени, пользователь делает на самом деле знает , что их адрес электронной почты. Как кто-то из Австралии, я все еще время от времени нахожу очень умную проверку электронной почты, которая говорит мне, что у меня не может быть домена .com.au. В первые дни интернета это случалось намного чаще.

Отправка письма с подтверждением в эти дни является приемлемой для пользователей, а также полезна с точки зрения регистрации и проверки предоставленного адреса.

На некоторых сайтах, созданных в местах, где я работал, мы всегда использовали письма с подтверждением. Однако было удивительно, что пользователи неправильно набирали свой адрес электронной почты способами, которые не могли бы сработать, а затем продолжали ждать подтверждения, которое не пришло. Добавление специального кода (или, для части имени домена, проверка DNS) для предупреждения пользователя в этих случаях может быть хорошей идеей.

Общие случаи, которые я видел:

• Сбрасывание буквы на середину доменного имени или несколько других простых опечаток.
• Путаница в TLD (например, добавление .brк .comдомену или удаление .brиз .com.brдомена).
• Добавление www.в начале локальной части адреса электронной почты (я не придумываю это; я видел несколько адресов электронной почты в форме www.username@example.com).

Были еще более странные случаи; такие вещи, как полное доменное имя в качестве локальной части, адреса с двумя @(что-то вроде username@domain.tld@example.com) и так далее.

Конечно, большинство из них все еще были действительными адресами RFC-822, так что технически вы могли бы просто позволить MTA справиться с ними. Тем не менее, предупреждение пользователя о том, что введенный адрес электронной почты, возможно, является поддельным, может быть полезным, особенно если ваша целевая аудитория не очень хорошо знает компьютер.

Все проверки регулярных выражений в мире не помешают кому-либо ввести неправильный или поддельный адрес электронной почты. Это действительно раздражает.

Зависит от цели. Если вы являетесь интернет-провайдером и вам необходимо проверить, что пользователи создают действительные адреса электронной почты, выберите Regex, который проверяет все возможные варианты. Если вы просто хотите отлавливать ошибки пользователя, как насчет следующего шаблона:

[Все символы, без пробелов] @ [буквы и цифры] (. [Буквы и цифры]), где последняя группа появляется хотя бы один раз.

RegEx для этого будет выглядеть примерно так:

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

А затем отправьте подтверждение по электронной почте, чтобы быть уверенным.

@ Яаков (мог бы ответить здесь с некоторым «ответом» здесь)

Я думаю, что одна из причин, по которой письма с подтверждением отправляются, заключается не только в том, что адрес электронной почты является действительным, но и в том, что он доступен пользователю, который его отправил. Человек может легко вставить опечатку из одной буквы в адрес электронной почты, которая приведет к другому, действительному адресу электронной почты, но это все равно будет ошибкой, поскольку это будет неправильный адрес.

Я согласен, но я не уверен, что оно того стоит. Для этого у нас также есть поля подтверждения (снова повторяя ваш адрес электронной почты). Другая ситуация, когда тип сайта может потребовать других подходов.

Кроме того, отправка подтверждения по электронной почте сама по себе не дает указанию исходному пользователю, что введенный адрес неверен. После получения подтверждения по электронной почте они могут просто предположить, что ваше приложение / сайт неисправен; по крайней мере, позволив пользователю немедленно начать использовать свою учетную запись, он может исправить свой адрес электронной почты, особенно если он отображается в достаточно очевидном месте.

Лошади на курсы.

Все они являются действительными, полными системами проверки электронной почты сами по себе, и для данного веб-сайта одна из них будет более подходящей (или настолько хорошей, насколько это гарантировано), чем другие. Во многих случаях несколько этапов проверки могут быть полезны.

Если вы разрабатываете веб-сайт для банка, вам понадобится обычная почта или проверка по телефону поверх всего этого.

Если вы разрабатываете веб-сайт для конкурса, вы, возможно, не захотите ни одного из них - проверьте электронную почту при постобработке, и если один не удастся, это слишком плохо для человека, который его ввел - вы можете оценить производительность сервера, учитывая огромное количество людей ( Например, телевизионный конкурс), чтобы убедиться, что все проходят валидацию правильно.

Как далеко нужно пройти проверку электронной почты?

Насколько это необходимо и гарантировано.

И не дальше (ПОЦЕЛУЙ)

Я видел сайты, которые также защищают от людей, использующих временные одноразовые сайты спама, такие как Mailinator или MyTrashMail , которые обходят подтверждение по электронной почте. Я не говорю, что вы должны их отфильтровывать, я просто говорю.

Что вы пытаетесь поймать при проверке электронной почты?

Проверка правильности адресов электронной почты с помощью регулярных выражений может в лучшем случае подтвердить правильность синтаксического и относительно правдоподобного адреса. Также существует опасность (как уже упоминалось много раз) возможного отклонения фактических, доставляемых адресов, если регулярное выражение не совсем корректно.

Проверка SMTP может определить, что адрес является доставляемым, с учетом ограничений, накладываемых серыми списками или серверами, которые сконфигурированы так, чтобы выдавать как можно меньше информации о своих пользователях. У вас нет возможности узнать, утверждал ли MTA о приеме почты только за поддельный адрес, а затем просто бросил ее на пол в рамках стратегии борьбы со спамом.

Однако отправка подтверждающего сообщения - это единственный способ убедиться, что адрес принадлежит тому пользователю, который его ввел. Если я заполняю вашу форму, я могу легко сказать, что мой адрес электронной почты president@whitehouse.gov. Регулярное выражение скажет вам, что это синтаксически допустимо, SMTP RCPT TO сообщит вам, что это доставляемый адрес, но, черт возьми, это не мой адрес.

С появлением HTML5 к возможностям добавлен по крайней мере один новый подход: использование ввода типа « электронная почта », которое позволяет выполнять проверку на стороне клиента. Текущие версии Firefox, Chrome, Safari и Opera поддерживают это (и другие браузеры просто воспринимают это как type = text, поэтому его можно использовать без проблем, даже если у вас нет проверки, конечно).

Он никогда не может (как указано несколько раз) гарантировать работоспособный адрес, но может оказаться очень полезным (и в конечном итоге заменить проверку на стороне сервера) в тех местах, где вам просто нужно отлавливать возможные ошибки пользователя.

Три основных уровня проверки электронной почты:

1) проверка регулярного выражения для правильно отформатированного адреса электронной почты email@email.com

2) проверка почтового домена по записям MX, чтобы определить, есть ли у доменного имени служба электронной почты

3) отправив подтверждение по электронной почте со ссылкой для подтверждения или кодом

1-й уровень:

В Visual Studio вы можете использовать «Средство проверки регулярных выражений». А в свойстве «ValidationExpression» вы можете нажать кнопку «...», в которой есть мастер для добавления в формате регулярного выражения для адресов электронной почты.

Уровень 2:

Вот мой код C # ниже, чтобы использовать nslookup, чтобы проверить, есть ли в почтовом домене допустимые записи MX. Работает быстро и нормально на Win 2008 R2 и 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

Другой вариант - использовать пакет nuget Arsofttools, но он может быть медленным на Windows Server 2008 R2, как я уже видел, но работает быстро на Win 7.

Уровень 3:

Для подтверждения электронной почты вы можете сгенерировать специальный шестнадцатеричный URL-адрес электронной почты (с использованием функций шифрования) и т. Д. Http://domain.com/validateEmail?code=abcd1234, чтобы проверить адрес электронной почты, когда пользователь нажимает на него. Нет необходимости хранить этот URL в памяти.