Комментарии 10
Как можно не знать получателя? Он же заявку на рассылку оставил и свой ящик подтвердил. /sarcasm
На самом деле, без всякого сарказма, чаще всего пользователь допускает ошибки в когда оставляет адрес в форме, получается undex.ru и тому подобное) а если форма рукописная, то беда совсем.
Хотя и сарказм конечно понятен, базы рассылок, часто никуда не годятся, но надеюсь, что закон о рекламе, коллегами всё-таки соблюдается в той или иной мере
Регулярка для проверки валидности адреса сломается на национальных доменах в национальных кодировках. Так же, есть куча доменов верхнего уровня длиннее четырёх букв.
И вообще, хватит проверять валидность адреса электронной почты регулярками. Единственное, что можно проверить, это присутствие знака '@'.
Есть же email-validator.
Большинство подобных валидаторов обладают как минимум одним фатальным недостатком - они проверяют теоретическую возможность отправки, а это (как правило) совсем не то что нужно.
Что же нужно? Нужно убедиться что потенциальный получатель действительно может получить, прочитать и понять письмо.
Единственный способ это сделать - собственно, отправить соответствующее письмо с просьбой его подтвердить нужным способом - ответить на него, пройти по ссылке, отправить SMS или позвонить на хотлайн (да, бывает и такое).
До этого, разумеется, нужно проверить существование домена, наличие MX или IP адреса - но не более.
Проверки доступен ли сервер (HELO/EHLO), ответа на RCPT TO и любые другие которые не отправляют писем - недостаточны - во-первых, сервер может быть недоступен в данный конкретный момент времени (даже если это Гугль или Microsoft), во-вторых, он вполне может отбить письмо и после отправки тела через DATA, причём не просто отбить а даже сказать "нет такого ящика" (для корпоративных серверов вполне себе реалистичный сценарий, если там пара прокси по дороге).
Если сразу отправить не удалось - можно сказать про это пользователю и предложить подождать, а через некоторое время - и повторить. Если письмо отбито после DATA - об этом тоже можно сказать и попросить разобраться или изменить email, или повторить позже.
В любом случае результат валидации нужно сообщить пользователю - либо сказать "всё ок", либо дать максимум информации если что-то пошло не так (включая ответ его почтовика - сильно помогает с разборками).
Что же до самого адреса (до @) - как уже выше заметили, не надо его проверять, он может быть любым - включая "A & Б сидели на трубе!"@почта.где-то.там и без ограничения по длине в 16-20 символов. Сервисы же которые выпендриваются и даже "+" не разрешают в адресе вообще должны гореть в аду, не говоря уже о тех которые отказываются принимать вполне себе символьные имена которые по их мнению "неправильные" или "невозможные" (вспоминается eBay - они не разрешали email независимо от домена если в нём была подстрока "ebay", причём служба поддержки отморозилась в духе "у вас не может быть такого email").
Не обязательно наличие MX-записи для получения почты. Читаем почтовые RFC.
Вы хотите сказать, что бывает, когда почта работает на сервере, на котором нет MX-записи? Если да, можете пожалуйста привести пример подобного адреса, интересно проверить. И можете пожалуйста скинуть ссылку на RFC?
Конечно бывает. RFC 5321 раздел 5.1:
.... If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Верификация e-mail по протоколу smtp. Узнаем, что почта есть и ждёт писем при помощи python