Sergey Y. Afonin wrote:
>>но придется отказаться от FEATURE(`mtamark') из состава sendmail по
>>причине того, что сендмылеры выполняют проверку марок в
>>Basic_check_relay, который выполняется после Local_check_relay, из
>>которого мы запускаем Local_check_dialup_relay
>> На самом деле, видимо, оно просто получится независимо ? хак - хаком,
> а FEATURE(`mtamark') уже само по себе, потом. Если включено.
на самом деле в таком случае проще вообще отказаться от
FEATURE(`mtamark'). проверять марку в Local_check_relay и на основании
этого делать или не делать исключение из других проверок в
Local_check_relay. кстати, если марка будет отрицательная (значение
записи - "ноль"), то уже никакие исключения делать не надо :)
> Хотя,
> если дойдет до полного задействования MTA Mark, смысл в этих хаках
> может, вообще, потеряться...
держи карман шире. у тебя какая-то фанатичная вера в марки. все равно
останутся целые сети, вообще никак не промаркированные. или ты будешь
принимать только от тех, у кого марка выставлена в единицу? а что будешь
делать с теми, у кого не будет марки? не единичной ни нулевой?
>>таким образом, нужно реализовать свой hack, посторяющий функциональность
>>mtamark.m4, но проводящий проверку в Local_check_relay. при этом надо
>>реализовать механизм исключений по access_db, который не реализован в
>>mtamark.m4, т. к. до него в Basic_check_relay делается общее исключение
>>по access_db. результат проверки марки нужно сохранить в переменной, а
>>потом проверять ее значение в остальных hack'ах
>> На самом деле, с логикой не очень понятно...
все там понятно
> С одной стороны, может
> потребоваться исключение из проверки хаками по наличию MTA Mark, а,
> с другой, наоборот, блокировка хаками при наличии успешной проверки...
ага, ты имел ввиду логика задачи непонятна? я уж подумал, что логика
реализации
> И хорошо, если оно глобально или так, или так, а вот если вдруг
> захочется где так, а где и наоборот ?...
без проблем на самом деле
> Но, на текущий момент,
> хочется именно изначального варианта - исключение из проверки при
> успешной проверке на MTA...
есть два варианта:
1. первый я описал выше. т. е. надо проверку марок вынести в
Local_check_relay, перед ней сделать исключения для тех, чей рилей
указан в access_db со значениями RELAY и OK (т. к. штатные исключения по
этому признаку делаются в Basic_check_relay) и для SPAMFRIEND'ов. уже
после этого по маркам делать исключение из остальных (может быть не
всех) проверок.
2. проверку по регекспам вынести в Basic_check_relay (divert(8)), чтобы
она проводилась после штатных исключений по access_db. благодаря тому,
что mtamark.m4 реализован так же криво, как dnsbl.m4, в этом случае
можно его не хачить. ибо в случае успешной проверки (марка равна
единице), правило вернет OKSOFAR.
под кривостью mtamark.m4 и dnsbl.m4 я подразумеваю, что они ломают
данные, поступающие к ним. хотя... пара из ${client_name} и
${client_addr} ломается еще перед ними при проверке исключений по
access_db. так что может и хорошо, что mtamark оставляет OKSOFAR после
успешной проверки...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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