Имеем postfix 2.2.1
На входе имеем почту с адреса A.B.C.D от пользователя frend@from.china
Проверка по check_client_access для адреса A.B.C.D дает положительный результат так как оттуда едет и куча спама :-(

Подскажите что надо прикрутить чтобы почта от frend@from.china с адреса A.B.C.D не футболилась?

Все пока режется строчкой в main.cf

smtpd_recipient_restrictions=
            permit_mynetworks,
            reject_unauth_destination,
            check_client_access regexp:/etc/postfix/client_checks,
            check_helo_access regexp:/etc/postfix/helo_checks

• Как разрешить хождение определенной почты в Postfix c 'плохо...,unk, 20:04 , 11-Май-05
  • Как разрешить хождение определенной почты в Postfix c 'плохо...,Balu, 20:17 , 11-Май-05
    • Как разрешить хождение определенной почты в Postfix c 'плохо...,unk, 13:33 , 12-Май-05
      • Как разрешить хождение определенной почты в Postfix c 'плохо...,Balu, 14:46 , 12-Май-05
        • Как разрешить хождение определенной почты в Postfix c 'плохо...,unk, 14:56 , 12-Май-05
          • Как разрешить хождение определенной почты в Postfix c 'плохо...,Balu, 15:41 , 12-Май-05
            • Как разрешить хождение определенной почты в Postfix c 'плохо...,unk, 15:57 , 12-Май-05
              • Как разрешить хождение определенной почты в Postfix c 'плохо...,Balu, 16:48 , 12-Май-05
                • Как разрешить хождение определенной почты в Postfix c 'плохо...,unk, 17:03 , 12-Май-05

>Имеем postfix 2.2.1
обновляемся до 2.2.3

>smtpd_recipient_restrictions=
>permit_mynetworks,
>reject_unauth_destination,
check_client_access hash:/etc/postfix/client_whitelist,
в client_whitelist пишем 1.2.3.4 dunno или ok
либо в client_checks добавляем "/^fqdn$/ dunno или ok"
>check_client_access regexp:/etc/postfix/client_checks,
>check_helo_access regexp:/etc/postfix/helo_checks
при необходимости делаем так же для helo.

Нифига не понял
что дает ?

>либо в client_checks добавляем "/^fqdn$/ dunno или ok"

Мне надо отрубать всю почту для 1.2.3.5 за исключением почты от frend@from.china Но чтобы разрешение действовало  c 1.2.3.5 :-)

P.S.
Кстати в check_client_access парсится не IP а слово unknown в случае если адрес не резолвится :-)

>Мне надо отрубать всю почту для 1.2.3.5 за исключением почты от frend@from.china
>Но чтобы разрешение действовало  c 1.2.3.5 :-)
Пардон стормозил :)
Смотрите в эту сторону:
main.cf:
smtpd_restriction_classes = frends
frends = check_sender_access hash:/etc/postfix/frend_mail, reject
smtpd_recipient_restrictions = permit_mynetworks,
   reject_unauth_destination,
   check_client_access hash:/etc/postfix/frend_ip regexp:/etc/postfix/client_checks,
   ...

frend_mail:
frend@from.china  ok

frend_ip:
1.2.3.5  frends

>  Кстати в check_client_access парсится не IP а слово unknown в случае если
> адрес не резолвится :-)
Неправда. Там будет и "unknown" и ip клиента.

>Смотрите в эту сторону:
>main.cf:
  Спасибо будем пробовать

>>  Кстати в check_client_access парсится не IP а слово unknown в случае если
>> адрес не резолвится :-)
>Неправда. Там будет и "unknown" и ip клиента.

я в качестве экперимента поставил в clients_checks последним следущее правило

/(.*)/ PREPEND X-My-Watch:-$1-

В результате получил следующую бодягу в теле письма

X-My-Watch:-unknown -
Received: from 61.237.150.52 (unknown [61.237.150.52])
by my.domain.com (Postfix) with SMTP id C82504DC36

Из чего я и сделал этот вывод :-)

Хотя в самом начале я в clients_checks пробовал комбинацию (гипотеза надо проверить)

/^ *[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} *$/ REDIRECT trash@my.domain.com

И тоже получил срабатывание помоему на фсе :-)
Из чего можно сделать вывод что и IP там тоже присутсвует всегда :-) даже если есть резолв но наверное в другой строке строке. (сегодня проверю)

>Из чего можно сделать вывод что и IP там тоже присутсвует всегда
>:-) даже если есть резолв но наверное в другой строке строке.
>(сегодня проверю)
К чему такие странные эксперементы? Или вы не верите документации?

>>Из чего можно сделать вывод что и IP там тоже присутсвует всегда
>>:-) даже если есть резолв но наверное в другой строке строке.
>>(сегодня проверю)
>К чему такие странные эксперементы? Или вы не верите документации?

  Я там (в dоc что шла с rpm'om постфикса) не нашел конкретного места где говорится что передается на разбор в smtpd_client_restrictions. Я задал здесь вопрос что передается туда в случае неправильного резолва Вы ответили что IP. А как оказывается что всегда передается и IP и результат резолва. В принципе я просто хотел разделатся с почтой от неизвестных хостов. То есть вроде достаточно былобы опции reject_unknown_client
но мне не нужен reject мне нужен redirect :-) (с понеделника в отстойник попало уже 5 полезных писем)

(Я понимаю что самый правильный способ посмотреть в исходники :-) но c С я последний раз общался лет 12 назад и то с борландом под дос).

  Далее сейчас например во весь рост встает необходимость разобратся с приоритетами при разборе и влияние на него положений опций в main.cf

Вот и приходится извращатся :-)

>  Я там (в dоc что шла с rpm'om постфикса) не
>нашел конкретного места где говорится что передается на разбор в smtpd_client_restrictions.
Плохо искали?
Search the specified access database for the client hostname, parent domains, client IP address, or networks...
Т.е. для some.host.tld порядок будет таким:
1) some.host.tld
2) host.tld
3) tld
4) 1.2.3.4
5) 1.2.3
6) 1.2
7) 1

>Я задал здесь вопрос что передается туда в случае неправильного резолва
>Вы ответили что IP. А как оказывается что всегда передается и
Да, ответил, да unknown(отсутсвие A или не совпадение gethostbyXXX) передается, но не закладывайтесь на это не документированно и Винема планирует вынести эту фичу после того как добавит check_*_ptr_access

>  Далее сейчас например во весь рост встает необходимость разобратся с
>приоритетами при разборе и влияние на него положений опций в main.cf
Не знаю, что за дока в вашем rpm, но на postfix.org все это описано.

>Плохо искали?

  Скорее не понял :-) но смотрел много раз! честно - man 5 postconf.

>Search the specified access database for the client hostname, parent

>Т.е. для some.host.tld порядок будет таким:
>1) some.host.tld
>2) host.tld
>3) tld
>4) 1.2.3.4
>5) 1.2.3
>6) 1.2
>7) 1

А вот этого примерчика очень не хватает :-)

>Да, ответил, да unknown(отсутсвие A или не совпадение gethostbyXXX) передается, но не
>закладывайтесь на это не документированно и Винема планирует вынести эту фичу
>после того как добавит check_*_ptr_access

Постараюсь не забыть :-)

>>  Далее сейчас например во весь рост встает необходимость разобратся с
>>приоритетами при разборе и влияние на него положений опций в main.cf
>Не знаю, что за дока в вашем rpm, но на postfix.org все
>это описано.

Да точно такая же как и на http://www.postfix.org/documentation.html
Доходит тока туговато :(

А Вы к разработке postfix имеете какоето отношение?

>>Search the specified access database for the client hostname, parent
>>Т.е. для some.host.tld порядок будет таким:
>>1) some.host.tld
>>2) host.tld
>>3) tld
>>4) 1.2.3.4
>>5) 1.2.3
>>6) 1.2
>>7) 1
>А вот этого примерчика очень не хватает :-)
На всякий случай: во всех запросах postfix выигрывает первый найденный, т.е. для этого примера если сработал "host.tld", то пункты 3-7 выполняться не будут.

>Постараюсь не забыть :-)
Если все-таки хотите это использовать не забудьте предусмотреть ситуацию когда слово "unknown" содержется в валидном имени хоста

>А Вы к разработке postfix имеете какоето отношение?
Нет, не дорос. AFAIR из "наших" кроме mjt ни кто не "засветился" на этом поприще, хотя приватных патчей я видел много.