Кто-нибудь знает о каких-либо исследованиях, проведенных, чтобы показать, сколько электронных писем будет отклонено, если не будет записи ptr для имени баннера SMTP почтового сервера?
Всегда ли выполняется обратная проверка, когда она включена, или она иногда настраивается таким образом, что, если программа для рассылки спама считает письмо «сомнительным», выполняется обратная проверка?
Я бы постарался сделать так, чтобы обратный поиск IP-адреса моего почтового сервера соответствовал имени, которое он использует в разговорах SMTP. Это облегчает жизнь.
У меня нет никаких статистических данных, подтверждающих это, но по моему опыту, время от времени сообщения будут отклоняться некоторые удаленные почтовые программы из-за отсутствия обратного поиска, соответствующего имени хоста, используемому в диалогах SMTP. Вместо того, чтобы иметь дело с этой проблемой, проще сразу настроить обратный поиск. Последние несколько лет я считал наличие последовательного прямого / обратного просмотра обязательным требованием, так что мне не приходилось сталкиваться с проблемой его отсутствия.
Если у вас его не настроили, вы получите пометку законной электронной почты. Это зависит от устройства фильтрации спама в отношении того, как они проводят свои проверки, и нет никаких четких стандартов, так что это удачно или нет. Но в большинстве случаев со счетом спама они будут отбрасывать ваши электронные письма, если у вас нет подходящего прямого и обратного просмотра. Этот сигнал сам по себе часто не получает блоки электронной почты (но не обещает), но некоторые другие незначительные проблемы в электронном письме могут переборщить.
Раньше у нас не было конкретной записи PTR для нашего почтового сервера, и мы получали отказы от craigslist.org и некоторых наших деловых партнеров.
У вас также должна быть конкретная запись A для записи MX. Для некоторых строгих почтовых серверов не разрешены символы * или CNAMES.
Как сказал Эван, лучше всего разрешить запись PTR обратно на IP-адрес вашего сервера.
Однако, если по какой-либо причине это невозможно, PTR должен предложить вам использовать статически назначенный IP-адрес, а не домашнюю (некоммерческую) линию DSL. В рамках своей стратегии борьбы со спамом многие организации используют службы репутации (например, SORBS), которые отслеживают диапазоны IP-адресов на предмет активности ботнетов и поддерживают черные списки диапазонов IP-адресов. Однако вне зависимости от подозрительной активности они обычно включают свои динамические списки пользователей (DUL) в свой черный список. Для создания этих DUL они используют записи PTR и регулярные выражения, специально разработанные для схем именования многих крупных интернет-провайдеров.
Например, PTR вроде cable-66-103-40-69.clarenville.dyn.personainc.net скорее всего будет автоматически занесен в черный список (соответствует "dyn", поэтому он должен быть динамическим). В IETF предпринимаются некоторые попытки стандартизации обратного именования DNS, но с переменным успехом:
http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations
Немного не по теме, еще одним источником информации для черного / белого списка являются Записи SWIP в WHOIS.
Когда вы говорите «название баннера», это несколько вводит в заблуждение. Баннер - это имя на стороне сервера, которая решает, что отклонить. :) Думаю, вы имеете в виду то имя, которое дает отправляющая сторона в команде HELO / EHLO?
Большинство мест просто проверяют синтаксис и отклоняют явно плохой HELO / EHLO, потому что там слишком много сломанного хлама. Но если вы используете законный почтовый сервер, вам нужно просто указать публичное имя хоста вашего собственного почтового сервера в HELO, который вы отправляете. Есть те, кто проверяет. И с тех пор который Имя хоста должно иметь рабочий обратный DNS, чтобы ваше TCP-соединение не было немедленно отклонено многими MTA, по сути, вы должны иметь рабочий обратный DNS для данного имени.
Таким образом, для получения рабочего DNS для имени хоста HELO нет проблем с настройкой, помимо сортировки обратного DNS для общей доступности.