Ads
Comments 32
0
Спасибо за пост! На знал что такое есть… Но гугл как раз все емеилы отправлят в спам… И не знал как с этим бороться =)
+2
У нас настроена только SPF запись, но всем основным мейл-сервисам этого оказалось достаточно
0
SPF у меня тоже стоит, но даже совместно с DKIM, например, тот же mail.ru так же продолжает помещать сообщения в спам. Зато DKIM дает возможность использовать для рассылок вот это:
habrahabr.ru/blogs/google/101440/
0
Ну пока mail.ru нас любит, но DKIM может и настроим от греха подальше.

А какая связь между DKIM и List-Unsubscribe?

0
Если верить документации гугла, то нужно чтобы он просто считал тебя добросовестным отправителем. Возможно гугл не будет считать тебя таковым без DKIM, но прямой связи нет
0
Да, я тоже не нашел в хелпе гугла про List-Unsubscribe прямого упоминания об этом. Хотя там действительно указано, что SPF и DKIM повышают «репутацию» отправителя. В любом случае SPF+DKIM — это лучше, чем их отсутствие )))
+1
Кто-нибудь кроме больших почтовиков это использует? Технология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
0
Кто-нибудь кроме больших почтовиков это использует?


Ну например тот же hMailServer проверяет DKIM на входе и в случае её не валидности выставляет вес сообщению для оценки на спам. Тут скорее всё зависит от того, как админ настраивающий почту относиться к этому вопросу. Например ведь можно ставить подозрение на спам для писем, у которых нет DKIM, SPF и т.д. (не дотаточный для лока письма) и еще сильнее увеличивать подозрение в случае невалидных этих записей.

<blockquoteТехнология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
Хм… в случае релея письмо будет не подписано и не будет содержать DKIM и соответственно принимающая сторона не будет проверять его наличие (т.е. будет dkim=netrual, а не dkim=fail). В случае SPF например и строгого соответствия это вызовет spf=fail или spf=softfail что в любом случае хуже). Просто в случае релея, как я понимаю, мы останемся на уровне «не использование DKIM», а не привнесем доп.проблем как в случае с SPF. Поправьте меня, если я ошибаюсь )))

Да и… релеи — это скорее случай частной отсылки писем (т.е. лично человеком), а DKIM по моему будет больше полезен массовой, автоматизированной, рассылке. Где шанс быть отнесенным в спам намного выше. Так же не стоит забывать о фишинге, против чего DKIM тоже вполне хорошо себя проявляет. Тот же гугл писал в своём блоге:
gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html
0
Например, довольно распространенный пакет Spamassassin.
0
вопрос конечно не по теме, но hMail поддерживает интеграцию с Active Directory?
0
Не, даже не так.
Да, hMail поддерживает интеграцию с AD.
Да, использовали в этом варианте, остались довольны.
0
Спасибо за столь краткое описание, побуждает наконец разобраться и сделать.
-1
А чем Сервер DNS: Bind 9.7 лучше стандартного виндового днс сервера?
+1
Тем, что он присутствует в Win 2008 WebServer ))) К сожалению стандартный виндовый поставляется только со Standart и выше, а так бы конечно использовал его.
0
Я в основном такие штуки кручу на Postfix на юниксах.
Подход примерно тот же.
Касаемо спама — ещё пользуюсь SPF, также помимо DKIM'а — Domainkeys'ами и ещё стараюсь сделать Feedback Loops с многими крупными провайдерами (Yahoo, AOL, Microsoft).

Кстате, Yandex/Мыло.ру/Рамблер FeedbackLoop умеет? или они сразу вносят твой ИП в чёрный список и их ничего не волнует? (а-ля Gmail)
0
Поддерживаю. Думаю было бы интересно в итоге собрать воедино все что касается антиспама со стороны отправления почты (SPF, DKIM, DomainKeys… etc.)
+2
Ох не стал бы я генерировать пары ключей на чужом сервере. Паранойя конечно, но кто помешает им теперь подписывать почту вашим ключом? Или продать ключ кому-то другому?
openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного
0
Да, первоначально я так и делал. Пожалуй включу это в статью.
0
Даа, недавно тоже в дополнение к SPF прикрутил и DK/DKIM…
Думаете, перестала нормальная почта с моего домена сыпаться в спам на гугловских ящиках? Нет.
0
Хм… может вы уже в списках «не доверенных»? Не факт, что гугл моментально реагирует на изменения и появление SPF/DK/DKIM не сразу сменит статус на «доверенный».

Кстати, можно попробовать проверить, говоря выше в комментариях про List-Unsubscribe как раз говорилось про то, что эта фича работает в гугле только у «доверенных» отправителей. Попробуйте послать емайл с её поддержкой и проверьте, появиться ли ссылка на отписку.
+2
Рекомендую публиковать ASDP записи в днс тоже, это позволит принимающему серверу понять, должно ли ваше письмо подписано или нет. RFC5617
Просто добавляете запись TXT _adsp._domainkey.example.com, значения у записи может быть 3 dkim=unknown, dkim=all, dkim=discardable. Первый вариант это тоже самое что у вас такой записи нету. Второй все письма должны быть подписаны и 3 не подписанные письма не должны приниматься.
0
discardable как правильно подписывать, если есть dkim=all то dkim=discardable уже не может быть? Или надо как то через запятую прописать?
0
Добавлю сюда свою проблему с dkim и ее решение. Может кто найдет через поиск и поможет решить такую же проблему.

Настроил себе на сервере dkim чрез dkim-milter (dkim-filter) для postfix. Проверил — все работает, gmail в заголовках показывает dkim=pass. Радости было много, но как выяснилось не надолго.

Через время (месяц) обнаруживаю, что некоторые письма не проходят проверку dkim и в заголовках того же gmail красуется
dkim=neutral (body hash did not verify)

Это значит что хеш подписи не сходится с текушим хешем тела письма. Эта ситуаци происходит когда, что-то изменило тело письма после совершения подписи по dkim. В моем случае после фильтра dkim-milter, что-то меняло тело письма.

Ситуаций, когда что-то меняет тело может быть много, в инете достаточно много такий кейсов когда избранные письма не проходят dkim проверку.
Мой же случай оказался в том, что тело некоторых писем состовлялось из файлов, которые были с EOL (End Of Line) в формате windows, т.е. \r\n и по всей видимости постфикс после дким фильтра менял формат EOL на Unix, т.е. — \n
0
Я не могу понять, почему всякие чекеры SPF говорят что все Ок.
@ TXT «v=spf1 ip4:77.93.ХХ.ХХ include:amazonses.com ~all»
А отчет от гугла приходит такой:

<dkim>pass</dkim>
<spf>fail</spf>
Only those users with full accounts are able to leave comments.  , please.