Сценарий:
У меня есть контактная форма на моем веб-приложении, она получает много спама.
Я проверяю формат адресов электронной почты loosely i.e. ^[email protected]+\..+$
Я использую службу фильтрации спама (defensio), но полученные спам-ответы перекрываются с действительными сообщениями. На пороге 0,4 происходит спам, и некоторые вопросы клиента ошибочно попадают в журнал и отображается ошибка.Использование записей MX для проверки адресов электронной почты
Все спам-сообщения используют поддельные адреса электронной почты, например. [email protected]
Выделенный сервер PHP5 Linux в США, mysql, только регистрация спама, отправка сообщений о нежелательной почте (не сохраняется).
Предложение: Использование РНР checkdnsrr(preg_replace(/^[email protected]/, '', $_POST['email']), 'MX')
проверить домен электронной почты разрешается в действительный адрес, в файл журнала, а затем перенаправлять с ошибкой для сообщений, которые не решают, перейдите к службе фильтра спама, как и прежде адресов которые разрешают в соответствии с checkdnsrr()
.
Я прочитал (и я скептически отношусь к этому самому), что вы никогда не должны оставлять этот тип проверки до удаленных поисков, но почему?
Помимо проблем с подключением, в любом случае, у меня будут большие проблемы, чем контактная форма, проведет checkdnsrr, чтобы встретить ложные срабатывания/негативы?
Будут ли какие-то типы адресов, которые не будут разрешать? gov адреса? ip адресов электронной почты?
Нужно ли мне избегать имени хоста i pass to checkdnsrr()?
Комбинация всех трех ответов (желательно, чтобы я мог принять более одного в качестве составного ответа).
Я использую:
$email_domain = preg_replace('/^[email protected]/', '', $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 для наконечника Рекордное запасного варианта)
+1 .. Я никогда не слышал о проверке действительного электронной почты, проверяя записи MX .. вот хорошая идея, я думаю. – Earlz
Имейте в виду, чтобы проверить запись A, если запись MX не указана, как определено в RFC 5321. Это редко, но некоторые домены не имеют записи MX (по разным причинам). Дополнительная информация: http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A – ZoogieZork
Приветствия Зорка, именно такого рода ошибок, о которых я беспокоился. –