Использование записей MX для проверки адресов электронной почты

Question

Сценарий:
У меня есть форма контакта в моем веб-приложении, оно получает много спама.
Я проверяю формат адресов электронной почты свободно, т.е. ^.+@.+\..+$
Я использую службу фильтрации спама (defensio), но возвращенные оценки спама перекрываются действительными сообщениями. При пороговом значении 0,4 некоторое количество спама проходит, а некоторые вопросы клиентов ошибочно добавляются в журнал и выводится сообщение об ошибке.

Все спам-сообщения используют поддельные адреса электронной почты, например, [e-mail]

Выделенный сервер PHP5 Linux в США, mysql, ведение журнала только спама, отправка сообщений, не содержащих спам (не сохраняется).

Предложение: использовать PHP checkdnsrr(preg_replace(/^.+?@/, '', $_POST['email']), 'MX') чтобы проверить, разрешен ли почтовый домен к действительному адресу, войдите в файл, затем перенаправьте с ошибкой для сообщений, которые не разрешаются, перейдите к службе фильтрации спама, как и раньше, для адресов, которые разрешаются в соответствии с checkdnsrr(),

Я прочитал (и я сам скептически отношусь к этому), что вы никогда не должны оставлять этот тип проверки для удаленного поиска, но почему?

Помимо проблем с подключением, где у меня все равно будут большие проблемы, чем в форме контакта, собирается ли checkdnsrr встречать ложные срабатывания / отрицания?
Будут ли некоторые типы адресов, которые не будут разрешены? адреса правительства? IP адреса электронной почты?
Нужно ли мне экранировать имя хоста, которое я передаю checkdnsrr()?

Решение: комбинация всех трех ответов (если бы я мог принять более одного в качестве составного ответа).

Я использую:

$email_domain = preg_replace('/^.+?@/', '', $email).'.';
if(!checkdnsrr($email_domain, 'MX') && !checkdnsrr($email_domain, 'A')){
   //validation error
}

Весь спам регистрируется и вращается. С целью обновления до очереди заданий на более поздний срок.

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

http://en.wikipedia.org/wiki/Fqdn и

RFC2821
The lookup first attempts to locate an MX record associated with the name.
If a CNAME record is found instead, the resulting name is processed as if 
it were the initial name.
If no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host.  If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present.  If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.

Огромное спасибо всем (особенно ZoogieZork за отзыв об отказе A)

Answer 1

Я не вижу вреда в поиске MX с checkdnsrr() и я также не вижу, как могут появиться ложные срабатывания. Вам не нужно экранировать имя хоста, на самом деле вы можете использовать эту технику и продвинуться немного дальше, поговорив с MTA и проверив, существует ли пользователь на данном хосте (однако эта техника может и, вероятно, даст вам некоторую ложь позитивы у некоторых хозяев).

Answer 2

Поиск DNS иногда может быть медленным, в зависимости от сетевого трафика и загруженности, поэтому об этом следует знать.

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

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

У меня появилась привычка добавлять дополнительное поле к моим формам, которое скрыто с помощью CSS. Если оно заполнено, я предполагаю, что оно отправлено спам-ботом. Я также обязательно использую имя типа "url" или "website_url", которое выглядит как допустимое имя поля для спам-бота. Добавьте для поля метку с надписью "Не заполняйте это поле", чтобы, если чей-то браузер не отображал его правильно, он знал, что не следует заполнять поле спама. Пока это работает очень хорошо для меня.

Answer 3

function mxrecordValidate($email){
        list($user, $domain) = explode('@', $email);
        $arr= dns_get_record($domain,DNS_MX);
        if($arr[0]['host']==$domain&&!empty($arr[0]['target'])){
                return $arr[0]['target'];
        }
}
$email= '[e-mail]';

if(mxrecordValidate($email)) {
        echo('This MX records exists; I will accept this email as valid.');
}
else {
        echo('No MX record exists;  Invalid email.');
}

Answer 4

//The Code *https://davidwalsh.name/php-email-validator*  
function domain_exists($email, $record = 'MX'){
    list($user, $domain) = split('@', $email);
    return checkdnsrr($domain, $record);
}

if(domain_exists('[e-mail]')) {
    echo('This MX records exists; I will accept this email as valid.');
} else {
    echo('No MX record exists;  Invalid email.');
}

Answer 5

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

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

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

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

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

Вальтер