Comments 29
Есть хороший сервис для проверки всего этого и не только:
HELO Greeting
Reverse DNS
DNSBL (RBL)
SPF
Domain Keys
SPAMAssassin Content Checks
BATV (Bounce Address Tag Validation)
Greylisting
URIBL


Просто шлем любое письмо на адрес и через несколько минут получаем отлуп, в котором будет ссылка, перейдя по которой получим результаты теста.
Иногда не очень удобно вылавливать боунсы у себя на сервере особенно если обработку входящей еще не настроил нормально :)
а в вебе можно пользоваться этим
www.brandonchecketts.com/emailtest.php

Шлем письмо по сгенерированному для вас адресу и сразу после этого смотрим в онлайне результат
Это на сайте или ответ на мыло?
Сейчас проверил и то и другое, сайт нормально работает, на письмо отлуп получил через 8 минут.
«example.com. TXT v=spf1 a mx ~all

Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.»

вообще-то не так. Эта запись говорит, что про все остальные адреса отправителей мы ничего сказать не сможем. Если нужна строгая spf, то есть И ТОЛЬКО С НИХ, как вы пишите, то надо в конце -all
Частая ошибка, даже у mail.ru присутствует софт-фейл, которая позволяет миллионам спамеров рассылать от их имени.
v=spf1 ip4:94.100.176.0/20 ip4:217.69.128.0/20 ip4:128.140.168.0/21 ip4:195.218.168.66 ip4:188.93.58.0/24 ~all
Не совсем ошибка. Есть куча провайдеров, которые перекрывают 25 порт у себя и позволяют отправлять почту только через свой релей. Так вот, при -all сервер выдаст однозначный фейл при отправке через релей такого прова. ~all в этом плане более мягок и не выдаст жесткого fail, но и pass не будет.
Настроить авторизацию, которая будет пропускать у релея без проблем?
У нас например стоит -all, а все клиенты авторизируются, кто не может, проходит по IP авторизацию. И никого из них нет в SPF, да и не должно быть.
У яндекс такая же «ошибка», а у gmail, о боже, ?all. А когда-то, кстати, был -all — думаете, случайно ошиблись или все-таки о пользователях позаботились?

Суть в том, что это не ошибка. Бывают письма отправленные через релеи ISP, бывают письма отправленные в почтовые списки рассылки, бывают пользователи, которые настроили перенаправления с одного ящика в другой. Например, если Вы поставили -all для своего домена (вроде все правильно), некий администратор поднял корпоративный сервер вместо бывшего ящика на Yandex и сделал у себя реджект писем по SPF Fail (тоже вроде все правильно), некий пользователь сделал редирект старого ящика на Yandex в новый корпоративный ящик (тоже все правильно) — то Ваши письма ему не дойдут. И где-то кому-то что-то придется менять.
Только если в этом случае. Но опять же, это надо чтобы пользователи стучали по барабану провайдеру, а не наоборот. Какого черта те фильтруют траффик? Как же сетевой нейтралитет?
Очень сложно объяснить *** (любой случайный оператор сотовой связи из трех букв), например, что нехорошо в регионах закрывать почтовые порты, когда они начинают продвигать собственный почтовый клиент для телефонов. Сетевой нейтралитет ни в одном законе не прописан, а пользовательское соглашение у них составлено грамотно.

Но в описанной ситуации, фильтрация трафика провайдером никак не сказывается. Еще чаще бывает ситуация когда просто администратор почтового сервера сделал групповой адрес через алиас, типа
webmaster outsorcer1@gdetomail.com,outsorcer2@pupkin.ru,outsourcer3@bangalore.in
это общепринятая практика, отучить от нее практически невозможно.

Поэтому, прежде чем делать -all в SPF, неплохо бы оценить какой профит Вы с этого будете иметь и каким рискам себя подвергаете. Обычно получается что профита-то особого нет, а риски есть. Из-за этого в свое время и критиковали SPF, что она на принципах альтруизма, жесткая SPF не выгодна тому, кто ее реализует, а от мягкой SPF мало толка.
Как я уже говорил, у нас Авторизация стоит для пользователей + порт 587 и 465, их никто не фильтрует и не закрывает. 25 порт авторизацию не принимает в принципе.
Потому что это ужасная практика задерживающие бизнес-процессы.
Глупости. При корректной настройке задержка составит несколько минут для первого письма от этого отправителя, после чего его адрес будет помещён в белый список. Кроме того лично я активирую грейлистинг только для тех отправителей, которые засветились во всяких RBL-списках (что сводит к нулю задержку для большинства отправителей).
эти несколько минут сильно зависят от настроек времени прогона очереди отправляющего сервера.
А еще некоторые сервера типа гугла пересылают письмо которое не удалось доставить на другой релей и пробует оттуда, потом снова другой и тд. Это тоже надо предусмотреть

и да, я использую грейлистинг, но как и вы не для всех пользователей
Он актуален для принимающей стороны, не для отправляющей.
Честно говоря, этого мало.
Стоит вчитаться ещё в рекомендации от ReturnPath например.
Тут вам и как правильно составлять письма, тут же про whois (а, кстати, многие любят скрывать оригинального владельца домена, чего делать не стоит), ещё вспоминается про Feedback Loop и многое другое.

Собственно документ на сайте ReturnPath.

Ах, да… Стоит особое внимание уделить безопасности вашей базы данных пользователей. Если хоть раз она тю-тю… то будите злостным спамером. увы.
А DKIM вообще технология живая? В смысле, кто-то кроме гугла проверяет DKIM?
Достаточно кто еще проверяет. Яндекс, Укр.Нет очень положительно к нему относятся.
в том году нам мейлрушники активно советовали вставить DKIM в письма — правда мы и до этого рассылали несколько миллионов в день нормально, но это советовали сами мейлрушники (работали с ними немного) — послушались и сделали.
А еще стоит упомянуть про Precedence: bulk, про Message-ID (в яндексе про него отдельно упомянуто, на сколько помню) ну и конечно, если это рассылка, то надо чтобы была возможность отписки и не пренебрегайте bounce'ами

А если вы в мейл ру вдруг попали в спам (кстати, только у мейла, на сколько я знаю, есть такой чуть чуть полезный сервис postmaster.mail.ru) — то не стесняйтесь писать в саппорт, достаточно оперативно реагируют — на той недели просто извинились и вывели всю рассылку из спама(в течении суток) толком не объяснив, что произошло — типа алгоритм у них сложный и фиг знает :)
С ума сойти, я как раз вчера занимался настройкой smtp и новостной рассылкой, напоролся на все эти возможные подводные камни и как раз сегодня собирался написать точь-в-точь такую же статью на хабр. Чудеса.
У меня на DNS для одного IP прописано несколько PTR записей.
При этом сервисы типа remote.12dt.com/lookup.php отображают только одну рандомную запись
Как в этом случае настраивать Reverse DNS?
Лучше настроить только одну PTR запись на каноническое имя сервера, т.е. то имя, которое он сообщает в баннере и команде HELO/EHLO.

То, что записей несколько, не страшно, при условии что все они нормально разрешаются в обе стороны (т.е. имя, указанное в PTR записи разрешается обратно в тот же IP), но получить проблемы в данном случае гораздо более вероятно, чем если будет единственная работающая PTR-запись.
Only those users with full accounts are able to leave comments. Log in, please.