Alex Miller wrote:
> Моё почтение, уважаемые!
>> По просьбам коллег, излагаю некую идею:
слава тебе, Enter! (c) Leonid Mamchenkov (если ни у кого не сплагиатил)
Коля, тебе отдельное спасибо!
> как сделать отдельные проверки
> не site-wide, как сейчас, а скорее host-specific. Но не согласно неким
> спискам, как сейчас -- а согласно неким признакам.
ну, излагай :)
> Что мы сейчас имеем: у нас есть проверки на этапе конверта, и остальные.
> Проверки на этапе конверта -- в общем-то себя исчерпали.
не совсем. есть еще их комбинации, но они сильно специфичны для каждого
хоста. например, не принимать почту с envelope sender = envelope
recipient, если домен этих адресов локальный, а IP рилея отправителя не
из trusted сети
> Однако, именно
> они дают основную эффективность при борьбе со "злом".
угу
> Как следствие
> исчерпания, появляются проверки извращённые -- как-то: proxycheck,
> greylistsing, всякого рода задержки на этапе приёма,
вот они себя показали неплохо (у меня тут глюк был с 60-секундной
задержкой перед выводом SMTP баннера, я писал о нем в sendmail-conf, так
до меня за ночь ни один вирус не пролез)
> dns-based списки и
> т.д. Они в сучности своей -- достаточно эффективны, но геморройны для
> конечного пользователя, и зачастую являются средствами
> _дополнительными_. Почему не применять эти самые проверки для всех?
> Скажем, greylisting -- он бесит пользователей чрезвычайно, да и мешает
> зачастую даже админу.
>> В чём заключается идея:
> В том, чтобы хосту на этапе конверта насчитывались баллы, назовём их --
> "недоверия". А для каждой из [дополнительных] проверок можно было-бы
> указать пороговое значение недоверия рилею, на котором данная проверка
> применялась-бы.
в качестве дополнительной проверки можно использовать про deny, если
хоть набрал достаточно баллов для этого. например, если хост попал в три
DNSBL или хост попал в два DNSBL, а домен отправителя числится в двух
RFC Ignorant List
> По каким признакам насчитывать балл "недоверия"? Да по любым! Навскидку:
> - отсутствие PTR-записи рилея
несоответствие записей в прямой и реверсной зонах
> - несоответствие PTR-записи доменной части аргумента HELO
> - попадание в DNSBL/RBL/DUL/whatever
...в RFC Ignorant Lists
> - достаточное кол-во цифр в PTR-записи
> - отсутствие/присутствие/кривизна SPF-записи
присутствие записи и вливание почты с допустимого хоста можно оценить в
некое отрицательное количество баллов
> - некие свои базы, например создать самозаполняющуюся базу, в которую
> заносить _сети_, из которых чаще всего шлют вирусы
в записях этих делать TTL, на основе записей генерить DNS зоны для DNSBL.
> - ошибки (левые символы, синтаксис etc) параметров HELO/MAIL FROM/RCPT TO
> ...
а по этим как резали сразу, так можно и резать
> Соответственно, рилей, у которого всё "красиво", будет подвергнут
> минимуму проверок, и как следствие, сэкономит ресурс сервера и ускорит
> доставку.
какому минимуму? он просто не будет подвергнут максимуму проверок. а
какие это проверки я буду для него скипать, если он не наберет
достаточно баллов? разве что greylisting. spamassassin и антивирусы я
скипать не собираюсь
--
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ: 77186900, 32418694 CRV2-RIPE, CRV-UANIC