Проверка почтового адреса PHP

PHP и DNS. Проверка почтового адреса

string getmxrr(string hostname, array mxhost, [, array weight])

Эта функция принимает в качестве аргумента имя хоста
hostname
в данном домене и заполняет массив
mxhost
списком почтовых ретрансляторов этого домена. Если указан третий необязательный аргумент weight ,
то функция заполняет его значениями предпочтения, которые возвращает ей почтовый ретранслятор

Обычно когда требуется послать сообщения по адресу username@someserver.com,
необходимо сначала узнать хост почтового ретранслятора для домена someserver.com, а затем получить его ip-адрес.
После этого можно соединяться с хостом для доставки почты.
В домене может быть несколько почтовых ретрансляторов с разными значениями предпочтения, поэтому,
получив список ретрансляторов, имеет смысл устанавливать соединение с тем из них, который имеет максимальное значение предпочтения.

В следующем листинге показан пример кода, с помощью которого можно получить список почтовых ретрансляторов:

Получение списка почтовых ретрансляторов

Проверка существования адреса электронной почты

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

$email_arr = explode ( «@» , $email );
$host = $email_arr [ 1 ];

if (! getmxrr ( $host , $mxhostsarr ))
<
echo «На адрес $email отправка почты невозможна» ;
exit;
>

getmxrr ( $host , $mxhostsarr , $weight );
echo «На $email письма могут отправляться через следующие хосты:
» ;
for ( $i = 0 ; $i count ( $mxhostsarr ); $i ++)
<
echo ( «$mxhostsarr[$i] = $weight[$i]
» );
>

Как проверить адрес электронной почты в PHP

У меня есть эта функция для проверки адресов электронной почты:

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

Самый простой и безопасный способ проверить, правильно ли сформирован адрес электронной почты, — использовать filter_var() :

Кроме того, вы можете проверить, определяет ли домен запись MX :

Но это все еще не гарантирует, что почта существует. Единственный способ узнать это — отправить письмо с подтверждением.

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

Попытка проверить адрес электронной почты с помощью регулярного выражения является «невозможной» задачей. Я хотел бы сказать, что это регулярное выражение, которое вы сделали, бесполезно. Существует три rfc относительно адресов электронной почты и написания регулярных выражений, чтобы поймать неправильные адреса электронной почты и в то же время не имеют ложных срабатываний — это то, что не может сделать смертный. Проверьте этот список для тестов (как неудачных, так и filter_var() регулярного выражения, используемого filter_var() PHP filter_var() .

Даже встроенные функции PHP, почтовые клиенты или серверы не понимают это правильно. В большинстве случаев filter_var — лучший вариант.

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

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

Обратите внимание: filter_var() уже указан только в PHP 5.2. Если вы хотите, чтобы он работал с более ранними версиями PHP, вы могли бы использовать регулярное выражение, используемое в PHP:

PS Замечание о шаблоне регулярного выражения, используемом выше (из источника PHP). Похоже, есть некоторые авторские права на него Майкла Раштона. Как указано: «Не стесняйтесь использовать и распространять этот код, но, пожалуйста, сохраните это уведомление об авторских правах».

Проверка почтового адреса PHP

Эта функция принимает в качестве аргумента имя хоста hostname в данном домене и заполняет массив mxhost списком почтовых ретрансляторов этого домена. Если указан третий необязательный аргумент weight , то функция заполняет его значениями предпочтения, которые возвращает ей почтовый ретранслятор.
Обычно когда требуется послать сообщения по адресу username@someserver.com, необходимо сначала узнать хост почтового ретранслятора для домена someserver.com, а затем получить его ip-адрес.
После этого можно соединяться с хостом для доставки почты.
В домене может быть несколько почтовых ретрансляторов с разными значениями предпочтения, поэтому, получив список ретрансляторов, имеет смысл устанавливать соединение с тем из них, который имеет максимальное значение предпочтения.
В следующем листинге показан пример кода, с помощью которого можно получить список почтовых ретрансляторов:

Получение списка почтовых ретрансляторов

Проверка существования адреса электронной почты

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

А вот так выглядит функция проверки правильности E-Mail’а. Помните, эта функция проверят только существование почтового сервера и синтаксическую правильность адреса. Для полной проверки существования адреса необходимо отправить на него письмо со случайным кодом и попросить получателя письма ввести этот код а форме, на вашем сайте.

Функция возвращает 1, если адрес указан неверно и 0, если все порядке.

Как проверить адрес электронной почты с помощью PHP?

Эта статья содержит различные методы для проверки адреса электронной почты в PHP. Он использует регулярные выражения и встроенную функцию проверки электронной почты. Входная строка берется у пользователя и сопоставляется с предопределенными регулярными выражениями, и если регулярное выражение и входная строка найдены совпадающими, то возвращается значение true и продолжается далее.

Способ 1: проверка электронной почты с использованием регулярного выражения.

ссылка на сайт
brightness_4
код

Объяснение: В приведенном выше примере передача электронной почты определенной пользователем функции email_validation ($ email) , которая использует этот пример и соответствует регулярному выражению с использованием предопределенной функции preg_match () . Эта предопределенная функция сопоставляет весь ввод с регулярным выражением и возвращает True, если найденное совпадение в противном случае возвращает False.

Способ 2: проверка электронной почты с использованием метода filter_var ().

PHP проверка почты и URL

В этой главе показано, как проверить имена, адреса электронной почты и URL адрес.

PHP Проверка имени

В приведенном ниже коде показан простой способ проверить, содержит ли поле Имя: только буквы и пробелы. Если значение поля имени недопустимо, сохраняется сообщение об ошибке:

Функция preg_match() ищет в строке шаблон, возвращая значение true , если шаблон существует, в противном случае false .

PHP Проверка почты

Самый простой и безопасный способ проверить, правильно ли сформирован адрес электронной почты, является использованием функции PHP filter_var() .

В приведенном ниже коде, если адрес электронной почты не сформирован должным образом, сохраняется сообщение об ошибке:

PHP Проверка URL

В приведенном ниже коде, показан способ проверки допустимого синтаксиса URL адреса (это регулярное выражение, также допускает прочерк в URL). Если синтаксис URL адреса не является допустимым, сохраняется сообщение об ошибке:

_|]/i»,$website)) <
$websiteErr = «Invalid URL»;
>

PHP Проверка имени, почты и URL

Теперь сценарий выглядит так:

Пример

Следующий шаг — показать, как предотвратить опорожнение все входные данные поля, когда пользователь отправляет форму.

Проверка существования email, сделай сам на PHP

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

Как осуществляется проверка существования email?

Достаточно просто, есть 2 этапа:

Этап 1: валидация email на наличие ошибок

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

Этап 2: диалог с сервером получателя, для проверки есть такой пользователь или нет.

Приступим сразу ко второму этапу. Что нужно сделать для проверка существования email?

1) определить к какому домену привязана почта

2) определить MX сервера почты

3) соединится с MX сервером

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

Мастер Йода рекомендует:  Паралакс-скроллинг веб-сайта на чистом CSS

Первый пункт – самый простой, выделяем домен почты, при помощи регулярного выражения:

Итак, домен для почты мы нашли. Дальше нужно определить MX сервер для этого почтового адреса/домена.
Определить MX сервер домена можно при помощи встроенной в PHP функции dns_get_record. Ей и воспользуемся:

В результате мы получим массив с ассоциативными массивами, каждый из которых — MX запись домена (их может быть несколько). Выберем любую, и приступим к следующему пункту.

Теперь при помощи socket подключится к MX серверу и провести с ним диалог.

Ну а получение, через функцию:

То есть вам для того, чтобы провелась проверка существования email нужно в цикле провести диалог с сервером для каждого из почтовых адресов.

Ожидайте в ближайшее время сервис «проверка существования email».

Вопрос по php, regex, email, email-val >

У меня есть эта функция для проверки адресов электронной почты:

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

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

Просто хотел убедиться, что у меня не было серьезных проблем в коде, который все 🙂

Смотрите такжеstackoverflow.com/questions/201323/… для получения дополнительной информации о том, как и как не использовать регулярные выражения для проверки адресов электронной почты.

Если это работает, это работает. Вы действительно не можете сделать его лучше, он слишком мал. Единственное, что не хорошо, это стиль. validateEmail было бы как правдиво, так и мимоходом $email не $EMAIL .

Это не сможет подтвердить многие действительные адреса электронной почты. Например, *@example.com или & amp; @ example.com, или я @ [127.0.0.1], или вы @ [ipv6: 08B0: 1123: AAAA :: 1234]

Это не только проверит вашу электронную почту, но и очистит ее от неожиданных символов:

Ответили на это в «верхнем вопросе» о проверке электронной почтыhttps://stackoverflow.com/a/41129750/1848217

For me the right way for checking emails is:

  1. Check that symbol @ exists, and before and after it there are some [email protected] symbols: /^[^@][email protected][^@]+$/
  2. Try to send an email to this address with some «activation code».
  3. When the user «activated» his email address, we will see that all is right.

Of course, you can show some warning or tooltip in front-end when user typed «strange» email to help him to avoid common mistakes, like no dot in domain part or spaces in name without quoting and so on. But you must accept the address «[email protected]» if user really want it.

Also, you must remember that email address standard was and can evolute, so you can’t just type some «standard-valid» regexp once and for all times. And you must remember that some concrete internet servers can fail some details of common standard and in fact work with own «modified standard».

Итак, просто отметьте @, назовите пользователя на веб-интерфейс и отправьте письма с подтверждением на указанный адрес.

@Machavity, но спасибо за сообщение об ошибке в регулярном выражении, я исправил это из /^[^@][email protected][^@+]$/ в /^[^@][email protected][^@]+$/

Подсказки для исправления регулярного выражения, но как это улучшить по сравнению с filter_var метод? Это также не решает проблему принятия плохо отформатированных адресов. Ваше регулярное выражение с радостью примет [email protected] в качестве действительного адреса электронной почты, когда это не так

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

@Mavavity, ну, например, на вашем сервере есть конкретная версия PHP, и вы не можете обновить ее до последней версии. Например, у вас есть php 5.5.15. В 2020 году был расширен стандарт действительных писем. Это будет реализовано в php 7.3.10 в ближайшее время. И там хорошо работающая функция filter_var($email, FILTER_VALIDATE_EMAIL, $newOptions) , Но у вас есть старая функция на сервере, вы не можете обновить в некоторых случаях. И вы потеряете клиентов с некоторыми новыми действительными электронными письмами. Кроме того, еще раз отмечаю, что не все серверы, обслуживающие электронную почту, работают строго в соответствии с общепринятым и современным стандартом адресов электронной почты.

Вы читаете только регулярное выражение или весь ответ? Полностью с тобой не согласен. Просто скажите мне, пожалуйста, по какому RFC серверу gmail.com предполагается, что [email protected] и [email protected] — это один и тот же адрес? Есть много серверов, которые работают не по стандартам или по стандартам FRESH. Но они обслуживают электронные письма своих пользователей. Если вы наберете какое-то регулярное выражение один раз и подтвердите только этим, у вас нет никаких гарантий, что оно останется правильным в будущем, и ваши будущие пользователи не потерпят неудачу с их «новым способом» электронные письма. Итак, моя позиция такая же: главное, если вы хотите подтвердить адрес электронной почты — просто отправьте письмо активации.

В настоящее время, если вы используете форму HTML5 с type=email тогда вы уже на 80% в безопасности, так как браузерные движки имеют свой собственный валидатор. Чтобы дополнить его, добавьте это регулярное выражение в свой preg_match_all() и отрицать это:

Этот ответ может не полностью относиться к PHP, но предложение HTML охватывает «стандарт» пользователь использует только телефон / компьютер. Кроме того, пользователь получает информацию непосредственно в «его» браузер при использовании сайта. Настоящие проверки на стороне сервера этим не покрываются, конечно. Кстати, @Thielicious упомянул об изменении PHP, поэтому его комментарий связан с ИМХО.

Я тоже ненавижу понижения без объяснения причин. Ну, я думаю, он мог бы сказать: проверка электронной почты в браузере (на стороне клиента) совсем не безопасна. Любой может отправить на сервер что угодно, изменив код. Так что это очевидный и самый безопасный способ проверки (опять же) на стороне сервера. Вопрос здесь основан на PHP, поэтому очевидно, что Кэмерон искал решение для сервера, а не для решения клиента.

Не хочешь объяснить свое отрицание? Спасибо

Ты можешь использоватьfilter_var за это.

Если вы хотите проверить, еслиprovided domain from email address допустимо, используйте что-то вроде:

Это удобный способ отфильтровать множество недействительных адресов электронной почты вместе со стандартной проверкой электронной почты, посколькуemail format не значит действительныйemail.

Обратите внимание, что idn_to_ascii() (или его сестра функции idn_to_utf8() ) функцияmay not be доступно в вашей установке PHP, для него требуются расширения PECL intl> 1.0.2 и PECL >

Также имейте в виду, что IPv4 или IPv6 как часть домена в электронной почте (например, [email protected][IPv6:2001:db8::1] ) не может быть проверено, толькоnamed хозяева могут.

Я не думаю, что это будет работать, если часть адреса электронной почты хоста будет иметь IP-адрес в формате IPv6.

Если вы просто ищете фактическое регулярное выражение, которое допускает различные точки, подчеркивания и тире, это выглядит следующим образом: [a-zA-z0-9.-]+\@[a-zA-z0-9.-]+.[a-zA-Z]+ , Это позволит довольно глупо выглядеть как [email protected]_matrix.com быть подтвержденным.

Я думаю, что вам лучше использовать встроенный PHPфильтры — в данном конкретном случае:

Может возвращать true или false, если поставляется с FILTER_VALIDATE_EMAIL пары.

По моему опыту, regex решения имеют слишком много ложных срабатываний и filter_var() решения имеют ложные негативы (особенно со всеми новымиДВ).

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

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

Это метод, который я создал в классе Utility:

Neverbounce утверждает, что их API может проверить до 97% доставки. Конечно, если вы не против передачи своей базы данных контактов.

Самый простой и безопасный способ проверить правильность адреса электронной почты — использовать filter_var() функция:

Кроме того, вы можете проверить, определяет ли домен MX запись:

Но это все еще не гарантирует, что почта существует. Единственный способ узнать это — отправить письмо с подтверждением.

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

Попытка подтвердить адрес электронной почты с помощью регулярных выражений «невозможна». задача. Я бы сказал, что это регулярное выражение бесполезно. Есть три ссылки на адреса электронной почты и написание регулярного выражения для перехвата неправильных адресов электронной почты, и в то же время ложные срабатывания — это то, что смертный не может сделать. Проверять, выписыватьсяэтот список для тестов (как неудачных, так и успешных) регулярных выражений, используемых PHP filter_var() функция.

Мастер Йода рекомендует:  Работа с массивами в Perl

Даже встроенные функции PHP, почтовые клиенты или серверы делают это неправильно. Все еще в большинстве случаев filter_var это лучший вариант.

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

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

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

P.S. A note on the regex pattern used above (from the PHP source). It looks like there is some copyright on it of Майкл Руштон, Как указано: «Не стесняйтесь использовать и распространять этот код. Но, пожалуйста, сохраните это уведомление об авторских правах. & Quot;

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

Нет, слишком много неудачных тестов по этому шаблонуemailtester.pieterhordijk.com/test-pattern/MTAz 🙂

Хороший ответ, но по этой ссылке:haacked.com/archive/2007/08/21/… имя пользователя или локальная часть могут быть в кавычках, но FILTER_VALIDATE_EMAIL не принимает его.

@PeeHaa: Postfix 3.0 поддерживает его почти два года:postfix.org/SMTPUTF8_README.html , и он включен в Ubuntu 16.04 и будет включен, например, в следующую версию Debian. Exim имеет экспериментальную поддержку. Поставщики веб-почты, такие как Gmail, также добавили поддержку для отправки / получения таких электронных писем, хотя вы еще не можете создавать учетные записи Unicode. Широкое использование и поддержка в пределах досягаемости, и filter_var будет отставать довольно долго, даже если они изменят его прямо сейчас (я опубликовал отчет об ошибке).

Этот шаблон чрезвычайно сложен в случае, если вам нужно использовать его с функцией, подобной & quot; preg_match_all & quot; над большой текстовой строкой с электронными письмами внутри. Если у кого-то из вас есть проще, пожалуйста, поделитесь. Я имею в виду, если вы хотите: preg_match_all ($ pattern, $ text_string, $ соответствия); тогда этот сложный шаблон будет перегружать сервер, если вам нужно проанализировать действительно большой текст.

PHP проверка адреса электронной почты, email

Серию валидаторов пополняю функцией проверки введенного email на соответствие формальным требованиям.

По стандарту RFC822

Если есть необходимость соблюсти все требования, которые упомянуты в громоздкой спецификации RFC822, то лучший путь — воспользоваться функцией библиотеки IMAP для PHP:

Вообще-то функция может проверять сразу несколько адресов (записанных в одной строке). И мне не ясна роль параметра $default_host, от которого результат функции не зависит. В итоге, для одного адреса получается вот такой валидатор:

Модуль imap подключается соответствующими манипуляциями в файле php.ini, если он не подключен.

Проверка email в WordPress и Drupal

Так как стандарт RFC, мягко говоря, мало кто соблюдает в силу его «перегруженности», то во многих CMS реализованы свои «облегченные» функции проверки адреса электронной почты.

В WP реализована функция, которая проверяет email и возвращает либо false — если адрес не прошел проверку, либо «подчищенный» валидный email.

Как проверить, существует ли адрес электронной почты без отправки электронной почты?

Кто-нибудь пробовал что-нибудь подобное или у вас работает? Можете ли вы сказать, правильно ли введен клиент / пользователь электронной почты & существует?

Решение

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

Вы можете подключиться к серверу и выполнить команду VRFY. Очень немногие серверы поддерживают эту команду, но она предназначена именно для этого. Если сервер отвечает DSN 2.0.0, пользователь существует.

Вы можете выдать RCPT и посмотреть, отклонено ли письмо.

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

Существует также метод защиты от спама, называемый «серый список», который заставит сервер первоначально отклонить адрес, ожидая, что настоящий SMTP-сервер попытается выполнить повторную доставку через некоторое время. Это испортит попытки проверить адрес.

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

Другие решения

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

Вы можете подключиться к почтовому серверу через telnet, чтобы узнать, существует ли адрес электронной почты. Вот пример тестирования адреса электронной почты для stackoverflow.com :

Строки с префиксом с цифровым кодом являются ответами от SMTP-сервера. Я добавил несколько пустых строк, чтобы сделать его более читабельным.

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

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

В PHP я считаю, что вы можете использовать fsockopen , fwrite а также fread выполнить вышеуказанные шаги программно:

Общий ответ таков, что вы можете не проверьте, существует ли адрес электронной почты, если вы отправите ему электронное письмо: оно может просто попасть в черную дыру.

При этом описанный там метод достаточно эффективен. Используется в производственном коде в ZoneCheck за исключением того, что он использует RSET вместо QUIT.

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

Не совсем ….. Некоторые серверы могут не проверять «rcpt to:»

Это риск для безопасности …..

Если сервер делает, вы можете написать бота для обнаружения каждого адреса на сервере ….

Это не удастся (среди прочих случаев), когда целевой почтовый сервер использует серый список.

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

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

  1. Я уверен, что некоторые SMTP-серверы немедленно сообщат вам, если адрес, который вы им дадите, не существует, но некоторые не будут использоваться в качестве меры конфиденциальности. Они просто примут любые адреса, которые вы им дадите, и молча проигнорируют несуществующие.
  2. Как говорится в статье, если вы будете делать это слишком часто на некоторых серверах, они попадут в черный список.
  3. Для некоторых SMTP-серверов (например, gmail) вам нужно использовать SSL, чтобы что-либо делать.Это верно только при использовании SMTP-сервера Gmail для Отправить Эл. адрес.

«Можете ли вы сказать, правильно ли введен клиент / пользователь электронной почты? & существует?»

На самом деле это две разные вещи. Это может существовать но может быть не правильно.

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

Linux Exp Group

Проверка адресов электронной почты в PHP, правильный путь

Validate an E-Mail Address with PHP, the Right Way
June 1st, 2007 by Douglas Lovell in Webmaster

Документ IETF, RFC 3696, “Application Techniques for Checking and Transformation of Names”, написанный Джоном Кленсином, предлагает некоторые примеры правильных e-mail адресов, которые, тем не менее, отвергаются большинством валидаторов, используемых в PHP-коде.
Адреса: Abc\@def@example.com, customer/department=shipping@example.com и !def!xyz%abc@example.com с точки зрения RFC все являются правильными. Одна из широко распространенных функций проверки, содержащая шаблон:

Мастер Йода рекомендует:  Ошибка в Python-коде поставила под сомнение результаты исследований по химии

все их отвергает.

Это регулярное выражение понимает только включение нижнего подчеркивания и дефиса, цифры и буквы в нижнем регистре. Даже если ввести препроцессинг адресов, в котором все буквы будут приводится к нижнему регистру, это не поможет, так как выражение по прежнему не понимает включение символов /, =, ! и %. Также выражение предполагает, что после последней точки имеется две или три буквы, поэтому такие домены верхнего уровня как .museum также будут отвергнуты.

Попробуем другое выражение:

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

Listing 1 показывает пример из PHP Dev Shed (www.devshed.com/c/a/PHP/Email-Address-Verification-with-PHP/2). Этот код содержит по крайней мере три ошибки. Он не поддерживает валидные символы, такие как %. Во-вторых, он разделяет имя пользователя и доменное имя по символу @. Правильный адрес вроде Abc\@def@example.com обрушит этот код. В-третьих, он не понимает формат DNS-записей для хостов. Хосты с А записью должны иметь возможность принимать почту, при этом не обязательно имея МХ запись.

Одно из более приемлемых решений пришло из блога Дейва Чайлда с ilovejackdaniels.com. Оно показано в Listing 2 (www.ilovejackdaniels.com/php/email-address-validation). Дейв не только любит старое американское виски, но также проделал некоторую домашнюю работу: прочитал RFC 2822, где и нашел правильные диапазоны символов для почтовых адресов. Около 50 человек прокомментировали это решение на сайте, они внесли несколько изменений, которые были добавлены в первоначальный вариант. Однако ошибкой этой коллективной разработки является тот факт, что она не приемлет экранированные символы, такие как \@, в составе имени пользователя. Она отвергнет адреса, содержащие более чем одно вхождение @, поэтому не получится разбивать адрес с использованием разделителя(«@», $email). В этом коде прикладывается масса усилий к тому, чтобы проверить правильность длины каждого компонента, а может быть нужно было использовать функции разрешения доменного имени?

Документы IETF, RFC 1035 “Domain Implementation and Specification”, RFC 2234 “ABNF for Syntax Specifications”, RFC 2821 “Simple Mail Transfer Protocol”, RFC 2822 “Internet Message Format”, в дополнение к представленному ранее RFC 3696, все содержат информацию, касающуюся проверки правильности e-mail адресов. RFC 2822 — развитие RFC 822 “Standard for ARPA Internet Text Messages” и он делает прежний документ неактуальным.

Требования к правильным адресам:

1. Адрес содержит локальную часть и домен, разделенные символом @ (RFC 2822 3.4.1).

2. Локальная часть может содержать символы алфавита, цифры и символы !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `,

, возможно разделенные точкой внутри, но не в начале адреса, не в конце или не рядом с другой разделяющей точкой (RFC 2822 3.2.4).

3. Локальная часть может содержать закавыченные части, несущие внутри кавычек пробелы (RFC 2822 3.2.5).

4. Экранированные части, такие как \@ , хотя этот синтаксис и утратил значение со времени начала действия RFC 822 (RFC 2822 4.4).

5. Максимальная длина локальной части — 64 символа (RFC 2821 4.5.3.1).

6. Доменная часть содержит идентификаторы, разделенные точкой (RFC1035 2.3.1).

7. Части доменного имени между точками начинаются с буквы, за которой следует нуль или более букв, цифр или символов -, заканчивающихся буквой или цифрой (RFC 1035 2.3.1).

8. Максимальная длина части доменного имени между точками 63 символа (RFC 1035 2.3.1).

9. Максимальная длина доменного имени — 255 символов (RFC 2821 4.5.3.1).

10. Доменное имя должно быть разрешаемым с помощью А или МХ DNS-записи (RFC 2821 3.6).

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

Разработка правильного валидатора e-mail адресов

Да, целая куча требований! Хотя большая их часть относится к локальной части имени. Значит имеет смысл вначале разделить строку адреса на локальное и доменное имя. Требования 2-5 касаются локального имени и 6-10 — доменного.

Поскольку адреса Abc\@def@example.com и «Abc@def»@example.com — правильные, разделитель вроде $split = explode(«@», $email) будет работать не всегда. Можно, конечно, заменить их по ходу, типа $cleanat = str_replace(«\\@», «»); но этот хак не отследит патологических случаев вроде Abc\\@example.com. К счастью, такая эскейп-последовательность около @ не поддерживается в доменной части. Таким образом, разделителем должно быть последнее вхождение @. Для поиска последнего вхождения воспользуемся strrpos.

Listing 3 предлагает лучший метод для разделения адреса. strrpos возвращает булев тип, то есть false, если в строке адреса вообще нет @.

Резонно стартовать с более простых проверок, например если требования длины частей не выполнены, нет смысла делать более сложные проверочные операции.

Далее. Локальная часть имеет одну из двух форм. Могут иметься кавычки в начале и в конце, без включения неэкранированных кавычек внутри, к примеру Doug \»Ace\» L.. Вторая форма — (a+(\.a+)*), только валидные символы. Вторая форма более проста, чем первая, с нее и имеет смысл начать. Нет смысла проверять закавыченные формы, если не прошел проверку набор символов. Отдельную проблему представляет \@. Эта форма допускает дублирование слешей для получения слеша в интерпретированном варианте. Поэтому придется допускать \\\\\@ и отвергать \\\\@.

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

Решение — сразу разбить последовательности слешей на пары. str_replace выполнит работу. Listing 5 показывает тест для локальной части.

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

Если проверяются адреса, поступившие как POST данные, следует соблюдать осторожность с вводом, имеющим слеши, одиночные или двойные кавычки. PHP может принять, а может и не принять такие вхождения за эскейп-последовательности, если они имеются в данных POST. Имя требуемого поведения — magic_quotes_gpc, где gpc обозначает get, post, cookie. Вы можете вызвать функцию get_magic_quotes_gpc() и обработать эту ситуацию. Также следует убедиться, что в файле PHP.ini эта «фича» отключена. Две другие установки заведуют подобными событиями в других соответствующих случаях: magic_quotes_runtime и magic_quotes_sybase.

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

Один недостаток внешнего теста в том, что он пропустит локальную часть, содержащую точки где угодно в имени. Требование номер 2 гласит, что точки не должны быть в начале и конце и не могут появляться рядом по двое и больше. Мы могли бы расширить выражение в форму ^(a+(\.a+)+)$, где а эквивалентно (\\\\.|[A-Za-z0-9!#%&`_=\\/$\’*+?^<>|

-]). Но это опять-таки не круто. Лучше где-нибудь вставить простую проверку, как показано в Листинге 6.

С локальной частью закончили. Теперь код выполняет проверку всех требований к локальной части адреса.

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

Код в Listing 7 убеждается в том, что все представленные символы допустимы и что точки не ходят парами. Далее обратимся к DNS для проверки наличия записей А и МХ. А записи будут искаться только в том случае, если поиск МХ ничего не дал. Код из Листинга 4 проверит длину доменной части адреса.

Итак, это хорошо? Вам решать. Осталось тестирование. Листинг 8 содержит ряд каверзных примеров адресов, которые должны преодолеть проверку.

Listing 9 содержит полный функционал для проверки адресов электронной почты. Код не настолько чёток и сжат как многие другие функции. И он несомненно не является однострочным. Однако он прост для чтения и понимания и он корректно пропускает кого следует и кого следует отвергает. Функции выстроены в соответствии с их относительным весом — простые проверки впереди, требующие регулярных выражений и тем более — работы с DNS, соответственно, в конце.

Существует, конечно, некоторая опасность в том, что фактически установившийся стандарт адресов более ограничен в своем формате, чем официальный. Поэтому, если вы хотите обмануть спам-ботов и приведете свои адреса к виду <^c\@**Dog^>@cartoon.com, будьте готовы к тому, что они не пройдут проверку на легитимность в каких-нибудь интернет-магазинах.

Дуглас Ловелл, инженер-программист из IBM Research, редактор сайта iac52.org.

Добавить комментарий