Больше нет писем в папке Spam: настройка SMTP-сервера

[Angel2S2]

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


Просто шлем любое письмо на адрес и через несколько минут получаем отлуп, в котором будет ссылка, перейдя по которой получим результаты теста.

[yakubovsky]

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

Шлем письмо по сгенерированному для вас адресу и сразу после этого смотрим в онлайне результат

[Anton_Shevtsov]

— The following addresses had permanent fatal errors — (reason: 552 Database is temporarily down. Please try after some time.

[Angel2S2]

Это на сайте или ответ на мыло?
Сейчас проверил и то и другое, сайт нормально работает, на письмо отлуп получил через 8 минут.

[Anton_Shevtsov]

ответ на мыло) все утро пробую… один хост из 5 пробился, остальные отлуп…

[nkuznetsov]

Всё в одном месте. Спасибо.

[habarator]

«example.com. TXT v=spf1 a mx ~all

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

вообще-то не так. Эта запись говорит, что про все остальные адреса отправителей мы ничего сказать не сможем. Если нужна строгая spf, то есть И ТОЛЬКО С НИХ, как вы пишите, то надо в конце -all

[equand]

Частая ошибка, даже у 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

[xforce]

Не совсем ошибка. Есть куча провайдеров, которые перекрывают 25 порт у себя и позволяют отправлять почту только через свой релей. Так вот, при -all сервер выдаст однозначный фейл при отправке через релей такого прова. ~all в этом плане более мягок и не выдаст жесткого fail, но и pass не будет.

[equand]

Настроить авторизацию, которая будет пропускать у релея без проблем?
У нас например стоит -all, а все клиенты авторизируются, кто не может, проходит по IP авторизацию. И никого из них нет в SPF, да и не должно быть.

[z3apa3a]

У яндекс такая же «ошибка», а у gmail, о боже, ?all. А когда-то, кстати, был -all — думаете, случайно ошиблись или все-таки о пользователях позаботились?

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

[equand]

Только если в этом случае. Но опять же, это надо чтобы пользователи стучали по барабану провайдеру, а не наоборот. Какого черта те фильтруют траффик? Как же сетевой нейтралитет?

[z3apa3a]

Очень сложно объяснить *** (любой случайный оператор сотовой связи из трех букв), например, что нехорошо в регионах закрывать почтовые порты, когда они начинают продвигать собственный почтовый клиент для телефонов. Сетевой нейтралитет ни в одном законе не прописан, а пользовательское соглашение у них составлено грамотно.

Но в описанной ситуации, фильтрация трафика провайдером никак не сказывается. Еще чаще бывает ситуация когда просто администратор почтового сервера сделал групповой адрес через алиас, типа
webmaster [e-mail],[e-mail],[e-mail]
это общепринятая практика, отучить от нее практически невозможно.

Поэтому, прежде чем делать -all в SPF, неплохо бы оценить какой профит Вы с этого будете иметь и каким рискам себя подвергаете. Обычно получается что профита-то особого нет, а риски есть. Из-за этого в свое время и критиковали SPF, что она на принципах альтруизма, жесткая SPF не выгодна тому, кто ее реализует, а от мягкой SPF мало толка.

[equand]

Как я уже говорил, у нас Авторизация стоит для пользователей + порт 587 и 465, их никто не фильтрует и не закрывает. 25 порт авторизацию не принимает в принципе.

[smartlight]

почему нет упоминания про грейлистинг?

[equand]

Потому что это ужасная практика задерживающие бизнес-процессы.

[powerman]

Глупости. При корректной настройке задержка составит несколько минут для первого письма от этого отправителя, после чего его адрес будет помещён в белый список. Кроме того лично я активирую грейлистинг только для тех отправителей, которые засветились во всяких RBL-списках (что сводит к нулю задержку для большинства отправителей).

[netmaniac]

эти несколько минут сильно зависят от настроек времени прогона очереди отправляющего сервера.
А еще некоторые сервера типа гугла пересылают письмо которое не удалось доставить на другой релей и пробует оттуда, потом снова другой и тд. Это тоже надо предусмотреть

и да, я использую грейлистинг, но как и вы не для всех пользователей

[jean]

Он актуален для принимающей стороны, не для отправляющей.

[Andrey_Zentavr]

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

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

Ах, да… Стоит особое внимание уделить безопасности вашей базы данных пользователей. Если хоть раз она тю-тю… то будите злостным спамером. увы.

[powerman]

А DKIM вообще технология живая? В смысле, кто-то кроме гугла проверяет DKIM?

[rednaxi]

яндекс проверяет

[QuickStudio]

Достаточно кто еще проверяет. Яндекс, Укр.Нет очень положительно к нему относятся.

[nmike]

в том году нам мейлрушники активно советовали вставить DKIM в письма — правда мы и до этого рассылали несколько миллионов в день нормально, но это советовали сами мейлрушники (работали с ними немного) — послушались и сделали.

[nmike]

А еще стоит упомянуть про Precedence: bulk, про Message-ID (в яндексе про него отдельно упомянуто, на сколько помню) ну и конечно, если это рассылка, то надо чтобы была возможность отписки и не пренебрегайте bounce'ами

А если вы в мейл ру вдруг попали в спам (кстати, только у мейла, на сколько я знаю, есть такой чуть чуть полезный сервис postmaster.mail.ru) — то не стесняйтесь писать в саппорт, достаточно оперативно реагируют — на той недели просто извинились и вывели всю рассылку из спама(в течении суток) толком не объяснив, что произошло — типа алгоритм у них сложный и фиг знает :)

[mihass]

Правила рассылок от mail.ru Как то получили от них письмо с просьбой соблюдать их правила.

[artch]

С ума сойти, я как раз вчера занимался настройкой smtp и новостной рассылкой, напоролся на все эти возможные подводные камни и как раз сегодня собирался написать точь-в-точь такую же статью на хабр. Чудеса.

[melmaxnvk]

У меня на DNS для одного IP прописано несколько PTR записей.
При этом сервисы типа remote.12dt.com/lookup.php отображают только одну рандомную запись
Как в этом случае настраивать Reverse DNS?

[z3apa3a]

Лучше настроить только одну PTR запись на каноническое имя сервера, т.е. то имя, которое он сообщает в баннере и команде HELO/EHLO.

То, что записей несколько, не страшно, при условии что все они нормально разрешаются в обе стороны (т.е. имя, указанное в PTR записи разрешается обратно в тот же IP), но получить проблемы в данном случае гораздо более вероятно, чем если будет единственная работающая PTR-запись.