Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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
Шлем письмо по сгенерированному для вас адресу и сразу после этого смотрим в онлайне результат
а в вебе можно пользоваться этим
www.brandonchecketts.com/emailtest.php
Шлем письмо по сгенерированному для вас адресу и сразу после этого смотрим в онлайне результат
— The following addresses had permanent fatal errors — (reason: 552 Database is temporarily down. Please try after some time.
Всё в одном месте. Спасибо.
«example.com. TXT v=spf1 a mx ~all
Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.»
вообще-то не так. Эта запись говорит, что про все остальные адреса отправителей мы ничего сказать не сможем. Если нужна строгая spf, то есть И ТОЛЬКО С НИХ, как вы пишите, то надо в конце -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
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 не будет.
У яндекс такая же «ошибка», а у gmail, о боже, ?all. А когда-то, кстати, был -all — думаете, случайно ошиблись или все-таки о пользователях позаботились?
Суть в том, что это не ошибка. Бывают письма отправленные через релеи ISP, бывают письма отправленные в почтовые списки рассылки, бывают пользователи, которые настроили перенаправления с одного ящика в другой. Например, если Вы поставили -all для своего домена (вроде все правильно), некий администратор поднял корпоративный сервер вместо бывшего ящика на Yandex и сделал у себя реджект писем по SPF Fail (тоже вроде все правильно), некий пользователь сделал редирект старого ящика на Yandex в новый корпоративный ящик (тоже все правильно) — то Ваши письма ему не дойдут. И где-то кому-то что-то придется менять.
Суть в том, что это не ошибка. Бывают письма отправленные через релеи ISP, бывают письма отправленные в почтовые списки рассылки, бывают пользователи, которые настроили перенаправления с одного ящика в другой. Например, если Вы поставили -all для своего домена (вроде все правильно), некий администратор поднял корпоративный сервер вместо бывшего ящика на Yandex и сделал у себя реджект писем по SPF Fail (тоже вроде все правильно), некий пользователь сделал редирект старого ящика на Yandex в новый корпоративный ящик (тоже все правильно) — то Ваши письма ему не дойдут. И где-то кому-то что-то придется менять.
Только если в этом случае. Но опять же, это надо чтобы пользователи стучали по барабану провайдеру, а не наоборот. Какого черта те фильтруют траффик? Как же сетевой нейтралитет?
Очень сложно объяснить *** (любой случайный оператор сотовой связи из трех букв), например, что нехорошо в регионах закрывать почтовые порты, когда они начинают продвигать собственный почтовый клиент для телефонов. Сетевой нейтралитет ни в одном законе не прописан, а пользовательское соглашение у них составлено грамотно.
Но в описанной ситуации, фильтрация трафика провайдером никак не сказывается. Еще чаще бывает ситуация когда просто администратор почтового сервера сделал групповой адрес через алиас, типа
webmaster outsorcer1@gdetomail.com,outsorcer2@pupkin.ru,outsourcer3@bangalore.in
это общепринятая практика, отучить от нее практически невозможно.
Поэтому, прежде чем делать -all в SPF, неплохо бы оценить какой профит Вы с этого будете иметь и каким рискам себя подвергаете. Обычно получается что профита-то особого нет, а риски есть. Из-за этого в свое время и критиковали SPF, что она на принципах альтруизма, жесткая SPF не выгодна тому, кто ее реализует, а от мягкой SPF мало толка.
Но в описанной ситуации, фильтрация трафика провайдером никак не сказывается. Еще чаще бывает ситуация когда просто администратор почтового сервера сделал групповой адрес через алиас, типа
webmaster outsorcer1@gdetomail.com,outsorcer2@pupkin.ru,outsourcer3@bangalore.in
это общепринятая практика, отучить от нее практически невозможно.
Поэтому, прежде чем делать -all в SPF, неплохо бы оценить какой профит Вы с этого будете иметь и каким рискам себя подвергаете. Обычно получается что профита-то особого нет, а риски есть. Из-за этого в свое время и критиковали SPF, что она на принципах альтруизма, жесткая SPF не выгодна тому, кто ее реализует, а от мягкой SPF мало толка.
почему нет упоминания про грейлистинг?
Потому что это ужасная практика задерживающие бизнес-процессы.
Глупости. При корректной настройке задержка составит несколько минут для первого письма от этого отправителя, после чего его адрес будет помещён в белый список. Кроме того лично я активирую грейлистинг только для тех отправителей, которые засветились во всяких RBL-списках (что сводит к нулю задержку для большинства отправителей).
эти несколько минут сильно зависят от настроек времени прогона очереди отправляющего сервера.
А еще некоторые сервера типа гугла пересылают письмо которое не удалось доставить на другой релей и пробует оттуда, потом снова другой и тд. Это тоже надо предусмотреть
и да, я использую грейлистинг, но как и вы не для всех пользователей
А еще некоторые сервера типа гугла пересылают письмо которое не удалось доставить на другой релей и пробует оттуда, потом снова другой и тд. Это тоже надо предусмотреть
и да, я использую грейлистинг, но как и вы не для всех пользователей
Он актуален для принимающей стороны, не для отправляющей.
Честно говоря, этого мало.
Стоит вчитаться ещё в рекомендации от ReturnPath например.
Тут вам и как правильно составлять письма, тут же про whois (а, кстати, многие любят скрывать оригинального владельца домена, чего делать не стоит), ещё вспоминается про Feedback Loop и многое другое.
Собственно документ на сайте ReturnPath.
Ах, да… Стоит особое внимание уделить безопасности вашей базы данных пользователей. Если хоть раз она тю-тю… то будите злостным спамером. увы.
Стоит вчитаться ещё в рекомендации от ReturnPath например.
Тут вам и как правильно составлять письма, тут же про whois (а, кстати, многие любят скрывать оригинального владельца домена, чего делать не стоит), ещё вспоминается про Feedback Loop и многое другое.
Собственно документ на сайте ReturnPath.
Ах, да… Стоит особое внимание уделить безопасности вашей базы данных пользователей. Если хоть раз она тю-тю… то будите злостным спамером. увы.
А DKIM вообще технология живая? В смысле, кто-то кроме гугла проверяет DKIM?
яндекс проверяет
Достаточно кто еще проверяет. Яндекс, Укр.Нет очень положительно к нему относятся.
в том году нам мейлрушники активно советовали вставить DKIM в письма — правда мы и до этого рассылали несколько миллионов в день нормально, но это советовали сами мейлрушники (работали с ними немного) — послушались и сделали.
А еще стоит упомянуть про Precedence: bulk, про Message-ID (в яндексе про него отдельно упомянуто, на сколько помню) ну и конечно, если это рассылка, то надо чтобы была возможность отписки и не пренебрегайте bounce'ами
А если вы в мейл ру вдруг попали в спам (кстати, только у мейла, на сколько я знаю, есть такой чуть чуть полезный сервис postmaster.mail.ru) — то не стесняйтесь писать в саппорт, достаточно оперативно реагируют — на той недели просто извинились и вывели всю рассылку из спама(в течении суток) толком не объяснив, что произошло — типа алгоритм у них сложный и фиг знает :)
А если вы в мейл ру вдруг попали в спам (кстати, только у мейла, на сколько я знаю, есть такой чуть чуть полезный сервис postmaster.mail.ru) — то не стесняйтесь писать в саппорт, достаточно оперативно реагируют — на той недели просто извинились и вывели всю рассылку из спама(в течении суток) толком не объяснив, что произошло — типа алгоритм у них сложный и фиг знает :)
Правила рассылок от mail.ru Как то получили от них письмо с просьбой соблюдать их правила.
С ума сойти, я как раз вчера занимался настройкой smtp и новостной рассылкой, напоролся на все эти возможные подводные камни и как раз сегодня собирался написать точь-в-точь такую же статью на хабр. Чудеса.
У меня на DNS для одного IP прописано несколько PTR записей.
При этом сервисы типа remote.12dt.com/lookup.php отображают только одну рандомную запись
Как в этом случае настраивать Reverse DNS?
При этом сервисы типа remote.12dt.com/lookup.php отображают только одну рандомную запись
Как в этом случае настраивать Reverse DNS?
Лучше настроить только одну PTR запись на каноническое имя сервера, т.е. то имя, которое он сообщает в баннере и команде HELO/EHLO.
То, что записей несколько, не страшно, при условии что все они нормально разрешаются в обе стороны (т.е. имя, указанное в PTR записи разрешается обратно в тот же IP), но получить проблемы в данном случае гораздо более вероятно, чем если будет единственная работающая PTR-запись.
То, что записей несколько, не страшно, при условии что все они нормально разрешаются в обе стороны (т.е. имя, указанное в PTR записи разрешается обратно в тот же IP), но получить проблемы в данном случае гораздо более вероятно, чем если будет единственная работающая PTR-запись.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Больше нет писем в папке Spam: настройка SMTP-сервера