Фильтрация спама при помощи greylistd+exim

>> Ну если "пшелнах" - это фильтрация, то можно и так сказать...

> Не "пшелнах", а временно не могу принять ваше сообщение, подождите 5-10 минут.

И то не для всех, а только для новых, незнакомых отправителей.

>О каком жестком и нежестком грейлистинге идет речь? Если письмо уже принято по smtp data

можно же ошибку выдать и после передачи письма

> Не "пшелнах", а временно не могу принять ваше сообщение, подождите 5-10 минут.

А как про 5-10 минут сообщается, по какому RFC?

> И то не для всех, а только для новых, незнакомых отправителей.

Да, например новый хост/сеть рассылки gmail...

Ладно, поржали, всем спасибо, я все-таки попробую поработать.

> Когда же вы поймете что грейлистинг и контентные фильтры - совершенно разные технологии.

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

>Да, например новый хост/сеть рассылки gmail...

с gmail vs грейлистинг проблем нет никаких абсолютно

>Ладно, поржали, всем спасибо, я все-таки попробую поработать.

в воскресенье работать? вот уж воистину ногам покоя нет...

> "серых листов" (greylist).

с каких это пор list переводится на русский словом "лист"? Автор, открой словарь, а лучше сразу убей себя.

Мдя... Забавный тред. Проблема грейлистинга в том, что куча недоадминов (коих в этом треде, похоже, достаточно) грейлистят всё подряд. На самом деле, грейлистинг должен применяться как самая последняя мера после предварительных проверок (dnsbl, spf, dial-pool, smtp-dialback и т.д.). Если ваш почтовик настроен правильно (соблюдает RFC, имеет SPF, обратную зону, etc), то вы никогда не столкнётесь с грамотно сконфигурированным грейлистом.

А вообще, нас всех спасёт DKIM. Тот, кто ещё не настроил его на своём серваке - быдлоадмин локалхоста.

>О каком жестком и нежестком грейлистинге идет речь?

Не ленитесь перечитать предыдущие сообщения. Не повторять же специально для Вас то, что написано совсем недавно.

>Если письмо уже >принято по smtp data, то какой может быть вообще >грейлистинг? >Поясните, о чем это вы.

Вы считаете, что после smtp data нельзя ответить "4xx Приходите потом"?

dnsbl ага. Месяц назад какая то замшелая база ожила и почте или значительноё ее части кердык. Очень полезная технология.

>dnsbl ага. Месяц назад какая то замшелая база ожила и почте или >значительноё ее части кердык. Очень полезная технология.

Ага, вылез. Раньше в космос не летали - и зимы были морозные. Впрочем, у Брежнева, кажется, было четыре звезды.

>А вообще, нас всех спасёт DKIM. Тот, кто ещё не настроил его на своём серваке - быдлоадмин локалхоста.

пока DKIM не получит более менее приличного распространения настраивать его не имеет смысла

> dnsbl ага. Месяц назад какая то замшелая база ожила и почте или значительноё ее части кердык. Очень полезная технология.

Опять дваццать-пять. Я же не предлагаю резать, я предлагаю грейлистить. К тому же надо проверять сразу по нескольким rbl'ам и юзать скоринг.

А пример с relays.ordb.org не очень показателен. Ошибки есть везде.

> пока DKIM не получит более менее приличного распространения настраивать его не имеет смысла

Начать надо с подписывания своей почты. Проверку можно прикрутить после распространения технологии.

>пока DKIM не получит более менее приличного распространения >настраивать его не имеет смысла

Пока Linux не получит более менее приличного распространения...

>Начать надо с подписывания своей почты.

зачем облегчать жизнь кому-то? надо пытаться облегчить жизнь себе

а пока:

nbw:[~]$ apt-cache search DKIM exim

nbw:[~]$

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

ну вот настроил ты DKIM что ЗДЕСЬ И СЕЙЧАС спама стало меньше? нет

а что будет через 5 лет может и DKIM, может SenderID может еще что

через пять лет и настроим и статью напишем :)

>зачем облегчать жизнь кому-то? надо пытаться облегчить жизнь себе

Эх, xargs, xargs. "Кому-то" - это и есть ты сам.

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

Да нее... Правильные админы лучше размажут вагон соплей в этом треде о том, какие плохие спамеры и как плох грейлистинг, чем настроят dkim.

>Эх, xargs, xargs. "Кому-то" - это и есть ты сам.

вот случай "я сам" и описан в статье

меня устраивает:

# greylist stats       
Statistics since Thu May 15 15:13:49 2008 (10 days and 4 hours ago)
-------------------------------------------------------------------
244 items, matching 5550 requests, are currently whitelisted
  0 items, matching    0 requests, are currently blacklisted
991 items, matching 1043 requests, are currently greylisted

Of 29376 items that were initially greylisted:
 -   244 (  0.8%) became whitelisted
 - 29132 ( 99.2%) expired from the greylist

>как плох грейлистинг

грейлистинг хорош! альтернативы с эквивалентной эффективностью пока не придумано (как вариант не реализовано)

>>>Бя@@@@@@ть! Понасрали-то. Когда же вы поймете что грейлистинг и контентные фильтры - совершенно разные технологии. Грейлистинг НЕ ФИЛЬТРУЕТ СООБЩЕНИЯ. Ему вообще все равно что там внутри сообщения. Можно сказать он производит фильтрацию МТА на начальной стадии smtp сессии.

да .. как гритца БЛЯЯ .. мне поххрену что там у вас грей лист хрей лист хоть белый лист .. похрену ..

но вот когда ждешь письма а его нету .. и нету .. и после того как по 15 раз посылают .. и МЕГОшароАДМИН почтового сервака мычит там что то про грей лист .. посылаешь его нахх .. и юзаешь ящик на mail.ru вот это дествительно грей лист ..

нахрена эти грей листы если МАЙЛ ру работает быстрее и надежнее ..

поскольку при применении технологии ГрейЛист и тд и тп .. появляетца БОЛЬШАЯ вероятность того, что очень важное письмо НЕДОЙДЕТ, что мне прикажете делать с этим админом ?? я конечно понимаю что тут все 7ми пядей во лбу и каждый бьет себе в затылок пяткой да будет СПАМ (все письма)!!

>На самом деле, грейлистинг должен применяться как самая последняя мера >после предварительных проверок (dnsbl, spf, dial-pool, smtp-dialback и >т.д.)

Ну чего умничаешь? Кто сказал что все пользуються тупо greylist?



smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        #       reject_unknown_client,
        reject_rbl_client openrbl.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client dnsbl.njabl.org,
        reject_rbl_client dnsbl.sorbs.net

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        reject_unknown_sender_domain,
        reject_invalid_hostname,
        check_policy_service inet:127.0.0.1:60000 <- postgrey

>поскольку при применении технологии ГрейЛист и тд и тп .. появляетца БОЛЬШАЯ вероятность того, что очень важное письмо НЕДОЙДЕТ,

с каких пор спам попал в разряд "важные письма"

с каких пор письма отправляемые вирусами стали важными?

> и юзаешь ящик на mail.ru вот это дествительно грей лист ..

И кто сказал что mail.ru не использует подобные технологии? Тот же гугл продъявляет очень жесткие требования к MTA, они так гайки закручивает на этапе соединения ( а не контент фильтрации) , что малейший косяк приводит к тому что месяц точно ты на гугл ничего не отправишь. будут вежливо посылать на http://www.google.com/mail/help/bulk_mail.html

> Тот же гугл продъявляет очень жесткие требования к MTA,

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

>Вот только с гуглем лично у меня проблем у меня в жизни не было, кроме >того что он сташно не любит десяток CC:, а с грейлистерами - >пожалуйста.

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

> Причем здесь грейлист...я говорил про отправку на гугл, а не о приеме.

И я об *отправке* на гугль (все пучком). И на грейлистеров (по-разному).

>> а маилру только через 7 часов

> Какой обязательный пункт RFC это нарушает, кстати (полагаю, такой есть...)

Не обязательный только, а настойчиво рекомендуемый. Я уже цитировал RFC 1123.

>> По умолчанию greylistd должен пропускать письма, а заворачивать, чтобы прислали ещё раз, только подозрительные.

> Это звучит разумно. Но как я понимаю, обычно делают не так?

Делают кто как может. Я вот так именно и делаю.

> говоришь ему .. МНЕ НУЖЕН ВЕСЬ спам все письма .. нет .. опять бычит .. какие то фильмтры рисует ..

Беда в том, что всем не угодишь. Массовый сервер ориентируется на массовые пожелания.

>> Не "пшелнах", а временно не могу принять ваше сообщение, подождите 5-10 минут.

> А как про 5-10 минут сообщается, по какому RFC?

На самом деле, никак. Отдаётся 4xx, а дальше всё зависит от настроек сервера отправителя. Логично ожидать ретрансмит через 30 минут.

> пока DKIM не получит более менее приличного распространения настраивать его не имеет смысла

Пока его не начнут использовать, он не получит распространения... :-)

> С ума сошел? mta может обрабатывать сотню виртуальных доменов, а обратка у него при этом может быть одна.

Может, однако, все его A-записи в DNS должны обратно определяться по ip. Кстати, вопрос обработки доменов - вопрос получения и здесь ему карты в руки - сам фильтрует, а вопрос отправки немного другое дело.

> Нет, конечно. Но на бекбоне гораздо легче блокировать распостранение массовых рассылок. Они ведь, как минимум, неделями идут

Без намеков на любое проявление скепсиса (потому как ничего про глобальные рассылки не ведаю) - неделями что и куда идет? И, главное, почему такое время повторения?

/etc/greylistd/config

# Initial delay before previously unknown triplets are allowed to pass # Default is 1 hour = 600 seconds

# Lifetime of triplets that have not been retried after initial delay # Default is 8 hours = 28800 seconds

Авторы greylistd точно из этой реальности? :)

>Пока его не начнут использовать, он не получит распространения... :-)

если его нет в Debian значит оно либо нечисто в плане патентов/авторских прав (то есть никогда не получит распространения)

либо очень очень сыро

в обоих случаях говорить об установке этого чЮда на боевые сервера рано

а грейлистинг УЖЕ работает, и что самое главное НЕспам под раздачу НЕпопадает

это опечатка, на эту тему уже заведен баг в BTS :)

> Может, однако, все его A-записи в DNS должны обратно определяться по ip.

А это как ? Пример можно ? :-)

>На самом деле, никак. Отдаётся 4xx, а дальше всё зависит от настроек сервера отправителя. Логично ожидать ретрансмит через 30 минут.

Нет в этом ничего логичного. Время зависит исключительно от длины очереди. Если почтовик проходит очередь за сутки, то и повтор будет через сутки.

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

можно подобрать время жизни грейлиста

но имхо в 8 часов на первый повтор чтобы не уложиться это очень криворуко настроенный сервер должен быть

>Может, однако, все его A-записи в DNS должны обратно определяться по ip.

Это невозможно. Собственно прямая и обратная зона вообще никак не связаны. Прямая находится под управлением доменодержателя, а обратная принадлежит владельцу соответствующей подсети.

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

> Вы все усложняете... у спамеров все проще - в 99% случаев они тупо коннектятся своим клиентом на 25 порт почтовика и льют сообщения для локальных пользователей этого сервера.

Не совсем так. Большая часть создает для этого адреса в почтовых системах типа mail.ru и отсылает оттуда.

Хотя видел попытки отослать что-нибудь от имени локальных пользователей моего домена для них же. Даже попытки подобрать для этого стандартные имена, типа sales, office и т.п.

>Без намеков на любое проявление скепсиса (потому как ничего про глобальные рассылки не ведаю) - неделями что и куда идет? И, главное, почему такое время повторения?

в таких вопросах скепсису самое место, поскольку вопросов больше чем ответов.

Неделями идет одно и тоже мусорное письмо. Одни и теже вирусы бегают месяцами.

>Неделями идет одно и тоже мусорное письмо. Одни и теже вирусы бегают месяцами.

то есть ты предлагаешь, чтобы какой-то дядя централизованно анализировал контент ВСЕХ писем?

> если его нет в Debian значит оно либо

либо его просто нет в Debian. :-)

> И еще момент. Со спамассасином сервер ПРИНИМАЕТ все эти 95% спама и потом только определят, что это спам. Грейлистинг позволяет отсечь спам еще до приема тела сообщения.

Это действительно плюс грейлиста, указанный в изначальной статье. Вопрос в другом: в свое время, пока админил, в небольших 3-х доменах на одном сервере (около 5 000 входящих из которых 80% спама) я тупо разрешил реджект начиная с 3-х пойнтов. С одной стороны - агрессивно, с другой стороны - юзерам не надо ничего фильтровать по заголовку - домен в белый лист по первой просьбе локального пользователя попадает, а если что-то не то, то посылающий получает сообщение, что послан, ну и дальше, разборки начинаем почему.

>либо его просто нет в Debian. :-)

если просто нет, то оно там будет в конечном итоге

а вот если его "непросто" нет, то значит это мертвая (==коммерческая) технология, которая не получит распространения до тех пор пока не появится нормальная свободная реализация

> Время зависит исключительно от длины очереди.

Только в какой-то мере.

> Если почтовик проходит очередь за сутки, то и повтор будет через сутки.

Если почтовик проходит очередь за сутки, значит он работает в аварийном режиме. Если это постоянное состояние, следует задуматься об апгрейде сервера, замене ПО и тп. RFC 1123 писали не для того, чтобы оно делалось как придётся.

> Собственно прямая и обратная зона вообще никак не связаны.

Но должна быть сходимость. Должно существовать прямое имя, на которое указывает реверс.

> Прямая находится под управлением доменодержателя, а обратная принадлежит владельцу соответствующей подсети.

Это верно, но, если речь о провайдере, то это одно лицо, если же речь о собственном сервере клиента, то кто мешает сказать провайдеру, что должно быть в реверсе ?

> а вот если его "непросто" нет, то значит это мертвая (==коммерческая) технология, которая не получит > распространения до тех пор пока не появится нормальная свободная реализация

RFC 4871 однако...