Vitalij Dz wrote:
> Еще вопрос:
>> Как этот кусок (?!10\.|127\.|172\.16\.|192\.168\.|195\.149\.96\.)
> заменить преобразовать для использования hosts-private, hosts-relayfrom ?
в начале файла с перечнем адресов хостов и сетей указать
!10.0.0.0/8
!172.16.0.0/12
!192.168.0.0/16
!195.149.96.0/24
> "2. долгий: сделать аналог конструкции DNS_BL для адресов из Received."
> - был бы более актуальным, т.к. имелбы законченный вид в твоей сборке.
> Может это комуто еще пригодилось... Меня частенько выручает...
на самом деле после некоторых раздумий я вообще против внесения в
конфигуратор проверки адресов из Recevied в DNSBL. разве что результат
проверки будет использован в скоринговой системе.
ведь если почтовый сервер небольшой организации имеет какое-нибудь ADSL
подключение с динамическим адресом, то сеть, из которой он получает
адрес, практически наверняка будет залистена со всех мыслимых и
немыслимых DNSBL. в такой ситуации единственным более-менее надежным
способом отправки исходящих писем может быть только отправка через SMTP
сервер провайдера, хостера, компании-партнера, свой сервер на
коллокейшине и т. д.
при этом в Received письма будет четко указан адрес, залистенный в DNSBL.
acl из первого письма треда просто блокирует прием письма с такого сервера.
ну и второй случай - вообще совершенно свежий.
на маршрутизаторе одной из компаний не был заблокирован исходящий SMTP
трафик с некоторых хостов локальной сети. Windows на этих хостах
инфицируется, вирусы начинают рассылать спам мимо почтового сервера
напрямую через маршрутизатор по MX записям доменов получателей. после
того, как я вразумил местных технарей, они закрыли доступ из локальной
сети к внешним SMTP серверам для всех хостов, кроме FreeBSD с exim. и
пока идет процедура делистинга из трех DNSBL, в которые успел попасть
адрес, который используется для NAT'а исходящего трафика и почтового
сервера и хостов из локалки, мне пришлось в mailertable прописать ручные
маршруты на десяток или чуть больше доменов, которые используют те три
DNSBL, через один из своих серверов.
при этом речь идет о маршрузизации абсолютно легетимной почты.
acl из первого письма треда успешно блокирует прием таким образом
смаршрутизированного письма.
т. о. я с одной стороны являюсь противником такой фильтрации, а с другой
- даю возможность тем, кто пользуется моим конфигуратором, на свой страх
и риск фильтровать письма по столь ненадежному критерию.
т. е. я считаю, что инклуда в данном случае вполне достаточно.
> --
> С Уважением,
> Виталий Дзюба (VD8-UANIC)
>>> ----- Original Message ----- From: "Victor Ustugov" <victor на corvax.kiev.ua>
> To: "Vitalij Dz" <exim-conf на mta.org.ua>
> Sent: Monday, January 31, 2011 10:44 AM
> Subject: Re: [exim-conf] NEW ACL
>>>> Vitalij Dz wrote:
>>> Привет Виктор!
>>>> привет
>>>>> Не мог бы ты добавить мой ACL в сборку ?
>>>>>> Выглядит примерно так:
>>>>>> deny set acl_m0 = ${sg {${sg {${sg {$h_Received:}{\n([ \t])}{ } }} \
>>> {.*?\N\[(?!10\.|127\.|172\.16\.|192\.168\.|195\.149\.96\.)\
>>> ((\d+)\.(\d+)\.(\d+)\.(\d+))\]\N+} {\$1|} }} \
>>> {([0-9.|]*).*} {\$1} }
>>> log_message = $dnslist_value $dnslist_text
>>> message = Sender $dnslist_text
>>> dnslists = bl.spamcop.net/<|acl_m0 : \
>>> blackholes.five-ten-sg.com/<|acl_m0
>>>>>> Что это делает я думаю объяснять нет необходимости.
>>> По возможности привести в более приемлемый вид.
>>> Вставляю я это перед check_message_id.
>>>> есть два варианта:
>>>> 1. быстрый: я просто дам возможность включать в m4/configure.m4 свои
>> инкруды в предопределенные места. тогда можно будет включить этот acl в
>> том же виже, в котором он приведен выше.
>>>> 2. долгий: сделать аналог конструкции DNS_BL для адресов из Received.
>>>> хотя идеологически с точки зрения целостности конфигуратора более
>> правильным является второй вариант, я склоняюсь к первому, т. к. я
>> специально в свое время выносил достаточно много фрагментов конфига, в
>> которых производилась работа с контентом (фильтр по полям Subject,
>> Organization, Content-Type и т. д.). ибо с моей точки зрения логичнее
>> проводить данные проверки средствами контент сканера, а не MTA.
>>>> если же рассматривать вариант использования инклудов, то нужно просто
>> согласовать их количество и места включения.
>>>> что касается данного конкретного случая, то я так понял, что устроит
>> включение инклуда в acl_check_data сразу после проверки письма
>> антивирусами?
>>>> как тестовый вариант - я только что вставил в вышеуказанное место в
>> m4/configure.m4 следующую строку:
>>>> sinclude(confSITE_DIR`/configure.acl_smtp_data.m4')
>>>> т. о. можно тот acl из начала письма просто сохранить в файле
>> site/configure.acl_smtp_data.m4
>>>> стОит иметь ввиду, что текст файла будет интерпретирован как код для m4.
>> это чревато ограничениями использования в содержимом файла прямого и
>> обратного апострофа. в данном случае их нет в тексте acl, так что и
>> проблемы нет.
>>>> если же возникнет необходимость использовать прямые или обратные
>> апострофы, нужно предварительно переопределить символы кавычек с помощью
>> changequote на что-то неиспользуемое, лучше даже при переопределении
>> кавычек использовать строки из нескольких символов (до пяти
>> включительно).
>>>> пример:
>> changequote([[, ]])
>>>> в конце файла нужно будет вернуть определие кавычек в исходное состоятие
>> комадной changequote без аргументов.
>>>> пример использования changequote можно посмотреть в нескольких файлах
>> конфигуратора:
>>http://mta.org.ua/exim-4.70-conf/m4/check.sh.m4>>http://mta.org.ua/exim-4.70-conf/m4/fix.sh.m4>>>>>> выбор подкаталога site обусловлен тем, что даный фрагмент конфига будет
>> актуален именно для данной системы.
>>>> выбор имени файла configure.acl_smtp_data.m4 обусловлен тем, что в
>> конфигураторе уже могут использоваться файлы configure.general и
>> configure.smtp_transport_options из подкаталога site.
>>>> также в следующей версии конфигуратора файлы site/retry_rules и
>> site/rewrite_rules будут переименованы в site/configure.retry_rules и
>> site/configure.rewrite_rules соответственно. разница лишь в том, что они
>> включаются в m4/configure.m4 безусловно, а
>> site/configure.acl_smtp_data.m4 будет включен в m4/configure.m4 только
>> если сам файл site/configure.acl_smtp_data.m4 будет существовать.
>>>> будут изменены имена еще трех опциональных инклуд файлов, но они не
>> анонсированы и используются только в очень специфических целях у пары
>> коммерческих клиентов.
>>>> p. s. изменения в m4/configure.m4 я вносил для версии конфигуратора 4.70.
>>>> --
>> Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua>> public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc>> ICQ UIN: 77186900, 371808614 nic-handle: CRV-UANIC
>>>> _______________________________________________
>> exim-conf mailing list
>>exim-conf на mta.org.ua>>http://mta.org.ua/mailman/listinfo/exim-conf>>http://mta.org.ua/exim-conf/>>http://mta.org.ua/exim-conf/m4/README>>rsync://rsync.mta.org.ua/exim-conf/>>> _______________________________________________
> exim-conf mailing list
>exim-conf на mta.org.ua>http://mta.org.ua/mailman/listinfo/exim-conf>http://mta.org.ua/exim-conf/>http://mta.org.ua/exim-conf/m4/README>rsync://rsync.mta.org.ua/exim-conf/
--
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ UIN: 77186900, 371808614 nic-handle: CRV-UANIC