Здорово всем!
Пастернака не читал ... ;-) Но имею вопрос.
Вить, ты вот нам, тёмным, лучше объясни рекомендованную логику и
рекомендованные значения этих начисленных баллов, сколько нам там их
ставить? Вот эти цифры, что там стоят, это дефолтные значения или как?
Какие это баллы, много их или мало надо, чтобы секир-башка письму
сделать? Они как-то соотносятся со spamassassin'овскими баллами? Если
туплю - извини, год тяжело начался.
Victor Ustugov пишет:
> Victor Ustugov wrote:
>>>>>баллы для опционального greylisting'а и опционального reject'а будут
>>>указываться во втором параметре "действие". туда же добавится
>>>возможность делать паузу.
>>>>>>т. е. теперь полный перечень действий следующий:
>>>2. действие в случае попадания рилея отправителя в DNSBL
>>> warn - выводить в лог файл предупреждение
>>> reject - отвергать сообщение
>>> deny - синоним reject
>>> drop - обрыв соединения
>>> defer - возврат временной ошибки
>>> greylist:xx - добавление xx баллов к счетчику опционального greylisting'а
>>> reject:yy - добавление yy баллов к счетчику опционального reject'а
>>> delay:zz - задержка на zz секунд перед продолжением обработки сообщения
>>>>>>при этом значения "warn", "greylist:xx", "reject:yy", "delay:zz" можно
>>>указывать через пробел для одного dnsbl'я
>>>>>>все вышеописанное (включая новую фишку опционального reject'а)
>>реализовано и выложено в рипозитарий
>>>>пример описнаия DNSBL'ей приведен в начале файла соответствующей feature:
>>http://mta.org.ua/exim-4.60-conf/features/dnsbl.m4>>>>пока недостатком реализации является необходимость ручного включения
>>механизма опционального reject'а, если данная функциональность будет
>>использована при проверке хоста рилея отправителя в DNSBL'ях или в
>>будущем (ближайшем) опциональный reject будет использован по другим
>>критериям
>>>>влючается опциональный reject прописыванием в site/conf:
>>define(`confOPTIONAL_REJECT', `YES')
>>>>предварительные тесты нововведений я провел. если будут проблемы -
>>пишите. сегодня сам буду переводить подшефные хосты на новую схему
>>работы с DNSBL'ями
>>> проверка домена отправителя в RFC Ignorant List'ах переделана в духе
> последних разработок в области DNSBL'ей.
>> по аналогии с конструкцией DNS_BL создана конструкция RFC_IGNORANT_LIST,
> принимающая следующие параметры:
>> 1. имя зоны
> 2. действие в случае попадания рилея отправителя в DNSBL
> reject - отвергать сообщение
> deny - синоним reject
> drop - обрыв соединения
> defer - возврат временной ошибки
> warn - выводить в лог файл предупреждение
> greylist:xx - добавление xx баллов к счетчику опционального
> greylisting'а
> greylisting:xx - синоним greylist:xx
> reject:yy - добавление yy баллов к счетчику опционального
> reject'а
> deny:yy - синоним reject:yy
> delay:zz - задержка на zz секунд перед продолжением
> обработки сообщения
> pause:zz - синоним delay:zz
> значения "warn", "greylist:xx", "reject:yy", "delay:zz" можно указывать
> через пробел
> 3. действие в случае defer'а от резолвера
> pass - принять сообщение
> defer - вернуть клиенту 4xx
> 4. сообщение отправителю:
> пустое значение - формируется умолчательное сообщение отправителю
> (пока не работает)
> текст - данный текст возвращается отправителю как текст
> сообщения об ошибке
>> примеры:
>> RFC_IGNORANT_LIST(`abuse.rfc-ignorant.org',
> `warn greylist:10 reject:8', `pass',
> `MX of domain does not have a working abuse address')
>> RFC_IGNORANT_LIST(`postmaster.rfc-ignorant.org',
> `warn greylist:10 reject:8', `pass',
> `MX of domain does not have a working postmaster address')
>> RFC_IGNORANT_LIST(`dsn.rfc-ignorant.org',
> `warn greylist:10 reject:8', `pass',
> `MX of domain do not accept bounces. This violates RFC 821/2505/2821')
>> RFC_IGNORANT_LIST(`bogusmx.rfc-ignorant.org',
> `warn greylist:10 reject:8', `pass',`')
>>> для упрощения перехода к новой схеме работы с RFC Ignorant List'ами
> acls/check_rfc_ignorant.m4 переделан таким образом, чтобы из него просто
> вызывалась конструкция RFC_IGNORANT_LIST
>
--
SY
Nikolai