Комментарии 34
Спасибо за пост! На знал что такое есть… Но гугл как раз все емеилы отправлят в спам… И не знал как с этим бороться =)
У нас настроена только SPF запись, но всем основным мейл-сервисам этого оказалось достаточно
SPF у меня тоже стоит, но даже совместно с DKIM, например, тот же mail.ru так же продолжает помещать сообщения в спам. Зато DKIM дает возможность использовать для рассылок вот это:
habrahabr.ru/blogs/google/101440/
habrahabr.ru/blogs/google/101440/
Ну пока mail.ru нас любит, но DKIM может и настроим от греха подальше.
А какая связь между DKIM и List-Unsubscribe?
А какая связь между DKIM и List-Unsubscribe?
Как я понимаю (и как следует из этого комментария в той теме) гугл не будет принимать отписку в случае отсутствия DKIM:
habrahabr.ru/blogs/google/101440/#comment_3143799
habrahabr.ru/blogs/google/101440/#comment_3143799
Кто-нибудь кроме больших почтовиков это использует? Технология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
Кто-нибудь кроме больших почтовиков это использует?
Ну например тот же 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
Например, довольно распространенный пакет Spamassassin.
вопрос конечно не по теме, но hMail поддерживает интеграцию с Active Directory?
Спасибо за столь краткое описание, побуждает наконец разобраться и сделать.
А чем Сервер DNS: Bind 9.7 лучше стандартного виндового днс сервера?
Я в основном такие штуки кручу на Postfix на юниксах.
Подход примерно тот же.
Касаемо спама — ещё пользуюсь SPF, также помимо DKIM'а — Domainkeys'ами и ещё стараюсь сделать Feedback Loops с многими крупными провайдерами (Yahoo, AOL, Microsoft).
Кстате, Yandex/Мыло.ру/Рамблер FeedbackLoop умеет? или они сразу вносят твой ИП в чёрный список и их ничего не волнует? (а-ля Gmail)
Подход примерно тот же.
Касаемо спама — ещё пользуюсь SPF, также помимо DKIM'а — Domainkeys'ами и ещё стараюсь сделать Feedback Loops с многими крупными провайдерами (Yahoo, AOL, Microsoft).
Кстате, Yandex/Мыло.ру/Рамблер FeedbackLoop умеет? или они сразу вносят твой ИП в чёрный список и их ничего не волнует? (а-ля Gmail)
P.S.: Может статью написать? :)
Простите, а под Feedback Loops подразумеваются callout'ы?
Детали можно посмотреть здесь (на английском): www.returnpath.net/resources/archives/Return%20Path%20Feedback%20Loop%20Set%20Up%20Instructions.pdf
Ох не стал бы я генерировать пары ключей на чужом сервере. Паранойя конечно, но кто помешает им теперь подписывать почту вашим ключом? Или продать ключ кому-то другому?
openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного
openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного
Даа, недавно тоже в дополнение к SPF прикрутил и DK/DKIM…
Думаете, перестала нормальная почта с моего домена сыпаться в спам на гугловских ящиках? Нет.
Думаете, перестала нормальная почта с моего домена сыпаться в спам на гугловских ящиках? Нет.
Хм… может вы уже в списках «не доверенных»? Не факт, что гугл моментально реагирует на изменения и появление SPF/DK/DKIM не сразу сменит статус на «доверенный».
Кстати, можно попробовать проверить, говоря выше в комментариях про List-Unsubscribe как раз говорилось про то, что эта фича работает в гугле только у «доверенных» отправителей. Попробуйте послать емайл с её поддержкой и проверьте, появиться ли ссылка на отписку.
Кстати, можно попробовать проверить, говоря выше в комментариях про List-Unsubscribe как раз говорилось про то, что эта фича работает в гугле только у «доверенных» отправителей. Попробуйте послать емайл с её поддержкой и проверьте, появиться ли ссылка на отписку.
Рекомендую публиковать ASDP записи в днс тоже, это позволит принимающему серверу понять, должно ли ваше письмо подписано или нет. RFC5617
Просто добавляете запись TXT _adsp._domainkey.example.com, значения у записи может быть 3 dkim=unknown, dkim=all, dkim=discardable. Первый вариант это тоже самое что у вас такой записи нету. Второй все письма должны быть подписаны и 3 не подписанные письма не должны приниматься.
Просто добавляете запись TXT _adsp._domainkey.example.com, значения у записи может быть 3 dkim=unknown, dkim=all, dkim=discardable. Первый вариант это тоже самое что у вас такой записи нету. Второй все письма должны быть подписаны и 3 не подписанные письма не должны приниматься.
Добавлю сюда свою проблему с 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
Настроил себе на сервере 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
Я не могу понять, почему всякие чекеры SPF говорят что все Ок.
@ TXT «v=spf1 ip4:77.93.ХХ.ХХ include:amazonses.com ~all»
А отчет от гугла приходит такой:
@ TXT «v=spf1 ip4:77.93.ХХ.ХХ include:amazonses.com ~all»
А отчет от гугла приходит такой:
<dkim>pass</dkim>
<spf>fail</spf>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DKIM — это просто