JcK

Рейтинг
0
Регистрация
09.06.2009
Andris:

Ужас. Ваш совет очень вреден, очень. Про NAT слышали что-нибудь?

А причем тут NAT??? При соединении через NAT светиться будет внешний IP. Если Вы в MX публичных доменов прописываете внутренние IP, и для внешних не прописываете PTR, что ж...

Andris:

Аналогично. MX'ы не обязаны быть отдающими почту.

Да, не обязаны, но практически на всех серьезных почтовых системах сервера занимаются одновременно и приемом, и отправкой.

Andris:

Воспользовавшись данными рецептами, люди рискуют потерять важную переписку.

Ага, спамерскую...

1. Тех клиентов, которые нам важны и которые не могут настроить свои почтовые системы - сами внесем по IP в белый список или поможем с настройкой.

2. Остальные смогут прислать, только правильно настроив сервера и DNS.

Итого:

1. При любых условиях ограничение спама будет либо пропускать его кучей, либо забирать вместе с ним еще и рабочие письма. Указанная мной конфигурация рубит спам очень хорошо и не теряет рабочей почты.

2. В такой конфигурации письма не теряются, так как почтовому серверу отправителя дается ответ с причиной отказа в приеме письма. Соответственно, этот ответ, обычно - зависит от настроек почтового сервера отправителя, указывается и самому отправителю в ответе собственного сервера, почему он не смог доставить его письмо. Так что человек всегда будет знать что его письмо не доставлено и причину этого. А дальше либо пинать своих админов, либо связываться с нами.

3. С Вашей позицией такие антиспамерские технологии, как, например, SPF, вообще запретить надо - это же не обязательно прописывать у себя в DNS почтового домена ссылки на корректные почтовые адреса, чтобы почта с этого домена проходила всем, кто блокирует по данной технологии.

4. Пока, из тех решений что мы внедряли и тех что видели, по качеству фильтрации - это один из лучших вариантов. Альтернативным близким вариантом отсеивания масс-рассылок с бот-сетей и т.п. систем является блокировка по блеклистам динамических адресов, но эти листы достаточно не полные и не так хорошо обновляются, как хотелось бы.

5. Кроме того, данное решение, как обрубающее левые соединения еще на этапе отправки, а не фильтрующее уже полученные письма, хорошо подходит, если ограничен трафик/объем хранилищ.

И вообще, имхо, это все оффтоп.

Я высказала, что хотела по сабжу и по сути переписки.

Данный пост написан по сути Вашего неверного высказывания. Это при блокировке системой фильтрации после приема письма рабочая почта может "затеряться" вместе со спамом. В указанной мною системе письмо либо будет получено, либо сервер отправителя получит корректную ошибку/отказ, которую сервер отправителя вернет постмастеру и отправителю; последующая фильтрация не нужна, только антивирусная проверка и обработка скриптов/приложений согласно политикам безопасности хозяев почтового сервера.

А вообще, самый идеальный вариант - работа почтового сервера только на уровне белых списков: отправителя знаем - письмо прошло, не знаем - отказ в приеме.

По поводу заруливания спама, вот алгоритм, рубящий как было сказано на предыдущей странице:

- устанавливается входящая smtp-сессия

- получаем HELO/EHLO

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

- проверяем по DNSBL - если есть, сообщение с указанием куда обратиться и терминэйт

- проверяем что IP и EHLO соответствует PTR, если нет - ругаемся в чем дело и обрыв

- получаем MAIL FROM, смотрим MX для домена из адреса, если IP не соответствует - ругаемся и посылаем.

В принципе, проверку PTR можно отключить, так как про PTR-записи админы почтовиков небольших контор даже не слышали, а RFC считают непонятным ругательством как и RTFM, но с ней надежнее.

Теперь, что касается тех, у кого зависли домены. Учитывая, что 3fn действительно был реселлером - проблем практически нет. Если домен не важен - регистрируем новый, если важен - смотрим по whois регистратора и оставляем там заявку на код авторизации для трансфера, потом переносим на другого регистратора и все дела. Мои домены были зарегистрированы на publicdomainregistry.com. Утром там на суппорте был написан запрос на код авторизации для трансфера с указанием мыла, соответствующего администратору/владельцу домена по хуизу - вечером коды прислали на мыло без лишних вопросов. Так что единственная проблема - затраты на трансфер и поддержку у другого регистратора (когда доменов много - сумма получается неплохая, хотя, если они важны, оно того стоит).

По поводу спама вообще все просто: свой грамотно настроенные почтовый сервер с проверкой входящей почты по IP, MX, PTR (рубится вся почта, что идет с ботов и криво настроенных учениками на коленке почтовиков), а также DNSBL, что бы обрубить спам с официальных почтовых спам-серверов.

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

По поводу 3fn, жалко... Очень удобная была организация для белого хостинга в рамках качества суппорта и оплаты... Приходится решать вопрос с переездом.