Имеем RedHat 9 postfix 2.2.1 bind 9.2.1в main.cf
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination,
check_client_access regexp:/etc/postfix/client_checksв /etc/postfix/client_checks есть правило отлавливающее ppp93-33.dsl-pun.eth.net (проверено)
Сама фильтрация тоже работает (фильтр срабатывает)
обратный резолв для 61.11.93.33 работает, nslookup host dig выдает все что надо.
Имеем на выходе спам со следующим заголовком
Received: from ppp93-33.dsl-pun.eth.net (unknown [61.11.93.33])
by my.domain.com (Postfix) with ESMTP id 6C1514DC31;
Wed, 4 May 2005 15:33:08 +0300 (EEST)
Вопрос откуда берется unknown? Где чего крутить в postfix или для named!
>Вопрос откуда берется unknown? Где чего крутить в postfix или для named!
У меня этот ppp93-33.dsl-pun.eth.net _не_ ресолвиться (пробовал из трех разных сетей). Фильтруйте по IP.
D:\>nslookup 61.11.93.33 195.5.51.182
Server: relay.kharkov.ukrtel.net
Address: 195.5.51.182Name: ppp93-33.dsl-pun.eth.net
Address: 61.11.93.33
D:\>nslookup 61.11.93.33 80.77.40.2
Server: uanet.vostok.net
Address: 80.77.40.2Name: ppp93-33.dsl-pun.eth.net
Address: 61.11.93.33
:-)
А теперь сделайте dig|host|gethostbyname|nslookup ppp93-33.dsl-pun.eth.net
smtpd не в chroot'е ?
>smtpd не в chroot'е ?
Да
Но описанный случай не правило а исключение
около половины писем таки фильтруются
>>smtpd не в chroot'е ?
>Да
>Но описанный случай не правило а исключение
>около половины писем таки фильтруютсяГипотезу с chroot'ом я б отработал, чтоб исключить
Затем
1. Отключил nscd если крутится
2. Включил в bind'е query log и посмотрел какие запросы делает постфиксЕдинственно что подозрительно в этом хосте, то что он не резолвится в прямом направлении, но это не должно влиять ....
>Единственно что подозрительно в этом хосте, то что он не резолвится в
>прямом направлении, но это не должно влиять ....
Идите читайте мануал
>>Единственно что подозрительно в этом хосте, то что он не резолвится в
>>прямом направлении, но это не должно влиять ....
>Идите читайте мануалА можно поподробней, не флейма ради, а просто интересно :)
P.S. Вообще судя по функции smtpd_peer_init делает проверку в обе стороны
В документации не встречал
/* Reject the hostname if it does not list the peer address */
>>>Единственно что подозрительно в этом хосте, то что он не резолвится в
>>>прямом направлении, но это не должно влиять ....
>>Идите читайте мануал
>А можно поподробней, не флейма ради, а просто интересно :)
Подробно: если gethostbyaddr() и gethostbyname() не совпадают, postfix ругается в лог и _не_ выполняет name-based проверок соответсвующего класса.
Подумайте сами, что бы было если бы postfix поступал иначе.PS: так ведут себя _все_ MTA
>Идите читайте мануал
Таки да !!!
Выборочно проверил все что отфильтровано имеет и прямой резолв!
Но ЗАЧЕМ такая фишка.?!!Будте так добры ткните котенка носом
Никогда не задумывался на эту тему, был не прав
smtpd_peer_init() изучил :)
>smtpd_peer_init() изучил :)
Поздравляю :)
>>Идите читайте мануал
>Таки да !!!
>Выборочно проверил все что отфильтровано имеет и прямой резолв!
Т.е у вас этот ppp-bla-bla ресолвиться в обе стороны?
Если да, то в чьей вы сети???>Но ЗАЧЕМ такая фишка.?!!
Для порядка :)
>Т.е у вас этот ppp-bla-bla ресолвиться в обе стороны?
>Если да, то в чьей вы сети???
Нет у этого конкретно нет прямогоЯ проверил то что нафильтровалось
:-(Но ppp93-33.dsl-pun.eth.net откудато взялось
Received: from ppp93-33.dsl-pun.eth.net (unknown [61.11.93.33])
А не подскажете где можно на него напасть ?
в smtpd_helo_restrictions?
header_checks?
>Received: from ppp93-33.dsl-pun.eth.net (unknown [61.11.93.33])
>А не подскажете где можно на него напасть ?
>в smtpd_helo_restrictions?
Можно> header_checks?
То же можно, но сначала вы примете письмо полностью.
Если можете себе позволить, то режьте всю 61.11.93.0/24 в check_client_access
>
>Но ppp93-33.dsl-pun.eth.net откудато взялосьЭто он в HELO так представился
>
>Received: from ppp93-33.dsl-pun.eth.net (unknown [61.11.93.33])
>
>А не подскажете где можно на него напасть ?
>в smtpd_helo_restrictions?
> header_checks?check_client_access:
61.11.93.33 REJECT
>>Но ppp93-33.dsl-pun.eth.net откудато взялось
>Это он в HELO так представился
В EHLO если быть точным :)
Большое спасибо!
проробуем helo проверять
:-)
Резать конкретные адреса самый последний способ (IMHO). Тем более сетки. (Сам страдаю так как мои статические IP в dsl пуле Укртелекома)
>Резать конкретные адреса самый последний способ (IMHO). Тем более сетки. (Сам
>страдаю так как мои статические IP в dsl пуле Укртелекома)
Этот блок сдан владельцем в dul.dnsbl.sorbs.net
>Этот блок сдан владельцем в dul.dnsbl.sorbs.net
:-)
А у этих (dnsbl.sorbs.net) чудаков и мой старый адрес засвечен. Проблемы уже нет больше полутора лет. А он у них все равно висит дайте говорят 50$ а иначе будет висеть вечно.
Я конечно понимаю что достали всех в свое время с этого IP. Но я тут причем :-).
Прочуствуйте разницу - в dul свои собственные адреса заносит владелец блока. Т.е. провайдер считает, что клиенты работующие на этих ip должны релеить через него...
>провайдер считает, что клиенты работующие на этих ip должны релеить >него...
Да ну их всех
А не подскажите какая стока парсится в check_client_access ip адрес или unknown ?
>А не подскажите какая стока парсится в check_client_access ip адрес или
>unknown ?
IP
>>Этот блок сдан владельцем в dul.dnsbl.sorbs.net
>:-)
>А у этих (dnsbl.sorbs.net) чудаков и мой старый адрес засвечен. Проблемы уже
>нет больше полутора лет. А он у них все равно висит
>дайте говорят 50$ а иначе будет висеть вечно.
>Я конечно понимаю что достали всех в свое время с этого IP.
>Но я тут причем :-).
dnsbl.sorbs.net и dul.dnsbl.sorbs.net две большие разницы
Первая есть суммирующая в которую входит spam.dnsbl.sorbs.net, от которой все проблемы
Так что использовать dul нужно и это правильно, гораздо правильней чем каждый адрес в access заносить