[Sysadmins] postfix header_checks

[Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
в main.cf прописано:
header_checks = pcre:/etc/postfix/header_checks
mime_header_checks = pcre:/etc/postfix/header_checks

соответственно в /etc/postfix/header_checks:
/^Received:.*\.altlinux\.org/    OK
/^Received:.*\d{1,3}-\d{1,3}[-\.]\d{1,3}-\d{1,3}/  REJECT Please use ISP relay
/^Received:.*dsl\.dynamic\d{1,}\.ttnet\.net\.tr/   REJECT Please use ISP relay

но в логах постфикса наблюдаеться:
# grep -i reject /var/log/mail/all | grep altlinux
Apr 21 02:03:49 main postfix/cleanup[7741]: 5C1B981ECE6A: reject: header 
Received: from cdm-75-109-220-134.asbnva.dh.suddenlink.net??
(cdm-75-109-220-134.asbnva.dh.suddenlink.net [75.109.220.134])??by 
mail.yandex.ru with HTTP; Tue, 21 Apr 2009 03:03:30 +0400 from 
lists.altlinux.org[194.107.17.17]; from=<devel-bounces@lists.altlinux.org> 
to=<kde@kde.kiev.ua> proto=ESMTP helo=<lists.altlinux.org>: 5.7.1 Please use 
ISP relay
Apr 21 07:02:03 main postfix/cleanup[32310]: A5C418209E3D: reject: header 
Received: from ?192.168.1.200? (ppp91-122-143-226.pppoe.avangarddsl.ru??
[91.122.143.226])??by mx.google.com with ESMTPS id 
d13sm11027840fka.20.2009.04.20.15.02.34??(version=TLSv1/SSLv3 cipher=RC4-MD5) 
from lists.altlinux.org[194.107.17.17]; 
from=<devel-distro-bounces@lists.altlinux.org> to=<kde@kde.kiev.ua> 
proto=ESMTP helo=<lists.altlinux.org>: 5.7.1 Please use ISP relay

помогите пожалуста  найти причину.

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Afanasov Dmitry]

2009/4/23, Denis Kuznetsov <kde@kde.kiev.ua>:
> Доброго времени суток!
>  в main.cf прописано:
>  header_checks = pcre:/etc/postfix/header_checks
>  mime_header_checks = pcre:/etc/postfix/header_checks
>
>  соответственно в /etc/postfix/header_checks:
>  /^Received:.*\.altlinux\.org/    OK
мне вот интересно, а эти шаблоны переводу строк учитывают? в Received
же не всегда в одну строку укладывают.
-- 
С уважением
Афанасов Дмитрий

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Thursday 23 April 2009 20:07:38 Afanasov Dmitry wrote:
> 2009/4/23, Denis Kuznetsov <kde@kde.kiev.ua>:
> > Доброго времени суток!
> >  в main.cf прописано:
> >  header_checks = pcre:/etc/postfix/header_checks
> >  mime_header_checks = pcre:/etc/postfix/header_checks
> >
> >  соответственно в /etc/postfix/header_checks:
> >  /^Received:.*\.altlinux\.org/    OK
>
> мне вот интересно, а эти шаблоны переводу строк учитывают? в Received
> же не всегда в одну строку укладывают.

я бы сказал что обычно не в одну строку но Received: from $hostname идет в 
одну строку, и по заголовку "Received: from lists.altlinux.org" встречаеться 
обычно раньше чем то что обычно попадает под Reject. Или постфикс тоже, как и 
принято админами читает Received снизу в вверх ? 

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Sergey]

On Четверг 23 апреля 2009, Denis Kuznetsov wrote:

> соответственно в /etc/postfix/header_checks:
> /^Received:.*\.altlinux\.org/    OK
> /^Received:.*\d{1,3}-\d{1,3}[-\.]\d{1,3}-\d{1,3}/  REJECT Please use ISP relay
> /^Received:.*dsl\.dynamic\d{1,}\.ttnet\.net\.tr/   REJECT Please use ISP relay
 
А почему Received, а не hostname на этапе connect ? Тут ведь письмо получено
уже, соответственно трафик...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Thursday 23 April 2009 23:10:11 Sergey wrote:
> On Четверг 23 апреля 2009, Denis Kuznetsov wrote:
> > соответственно в /etc/postfix/header_checks:
> > /^Received:.*\.altlinux\.org/    OK
> > /^Received:.*\d{1,3}-\d{1,3}[-\.]\d{1,3}-\d{1,3}/  REJECT Please use ISP
> > relay /^Received:.*dsl\.dynamic\d{1,}\.ttnet\.net\.tr/   REJECT Please
> > use ISP relay
>
> А почему Received, а не hostname на этапе connect ? Тут ведь письмо
> получено уже, соответственно трафик...

на этапе connect достаточно:
smtpd_helo_restrictions =
    [....]
    reject_unknown_helo_hostname
    reject_invalid_helo_hostname
    reject_non_fqdn_helo_hostname

но иногда этого не хватает для полноценной фильтрации спама.

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Vladimir V. Kamarzin]

>>>>> On 23 Apr 2009 at 20:49 "DK" == Denis Kuznetsov writes:

DK> Доброго времени суток!
DK> в main.cf прописано:
DK> header_checks = pcre:/etc/postfix/header_checks
DK> mime_header_checks = pcre:/etc/postfix/header_checks

DK> соответственно в /etc/postfix/header_checks:
DK> /^Received:.*\.altlinux\.org/    OK
DK> /^Received:.*\d{1,3}-\d{1,3}[-\.]\d{1,3}-\d{1,3}/  REJECT Please use ISP relay
DK> /^Received:.*dsl\.dynamic\d{1,}\.ttnet\.net\.tr/   REJECT Please use ISP relay

       Each  message  header  or  message  body line is compared against a list of patterns.  When a
       match is found the corresponding action is executed, and the matching process is repeated for
       the next message header or message body line.

Как уже сказали, используйте check_client_access

-- 
vvk

Postfix page on f.i: http://freesource.info/wiki/Dokumentacija/Postfix

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] postfix header_checks

[Sergey]

On Friday 24 April 2009, Denis Kuznetsov wrote:

> > А почему Received, а не hostname на этапе connect ? Тут ведь письмо
> > получено уже, соответственно трафик...
> 
> на этапе connect достаточно:
> smtpd_helo_restrictions =
>     [....]
>     reject_unknown_helo_hostname
>     reject_invalid_helo_hostname
>     reject_non_fqdn_helo_hostname
> 
> но иногда этого не хватает для полноценной фильтрации спама.

Я не про это. Я про то, что информация о хосте отправителя уже есть
на этапе установления соединения. Зачем ждать data, чтобы проверить
Received ?

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Sysadmins] postfix header_checks

[Владимир]

Sergey пишет:
> On Friday 24 April 2009, Denis Kuznetsov wrote:
>
>   
>>> А почему Received, а не hostname на этапе connect ? Тут ведь письмо
>>> получено уже, соответственно трафик...
>>>       
>> на этапе connect достаточно:
>> smtpd_helo_restrictions =
>>     [....]
>>     reject_unknown_helo_hostname
>>     reject_invalid_helo_hostname
>>     reject_non_fqdn_helo_hostname
>>
>> но иногда этого не хватает для полноценной фильтрации спама.
>>     
>
> Я не про это. Я про то, что информация о хосте отправителя уже есть
> на этапе установления соединения. Зачем ждать data, чтобы проверить
> Received ?
>
>   
Это "теория", а если внимательно читать логи, то можно видеть, что и 
спамеры, и множество
законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе 
установления соединения.
Так что есть нужда в дополнениях к, во многом теоретическим, restrictions.

Вот только не уверен, что header_checks это именно то, что надо.
Но если вдруг окажется эффективным, хотелось бы услышать об этом.

-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix header_checks

[Max Ivanov]

> Это "теория", а если внимательно читать логи, то можно видеть, что и
> спамеры, и множество
> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе
> установления соединения.

Как они это делают?

Re: [Sysadmins] postfix header_checks

[Владимир]

Max Ivanov пишет:
>> Это "теория", а если внимательно читать логи, то можно видеть, что и
>> спамеры, и множество
>> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
>> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе
>> установления соединения.
>>     
>
> Как они это делают?
>   

Если коротко, то "непроизвольно".
Но, чтобы раскопать, как это получается, пришлось повозиться.

1. Диалог helo предполагает, что отправитель и получатель, либо находятся
в одной сети, либо разделены "обычным" маршрутизатором, либо разделены
"обычным" nat. А вот через посредника proxy диалог без нарушений 
протокола проблематичен.
Или это не так?

2. Широко распространенные cisco firewolls только теоретически являются 
"обычными" пакетными фильтрами.
Для повышения защищенности, на отдельных этапах соединения они срываются 
на  проксирование.
Или это не так?

3. Посмотрите в журнале, как поступают письма, например, от yandex.ru (у 
меня стойкое ощущение,
что их web клиенты сидят за циской). Вы увидите, что диалог "поцокан 
проксей", а информация о helo_hostname вовсе отсутсвует. Хотя письма 
принимаются.
Или это не так?

Вопрос, что лучше, не принимать писем от всех клиентов сидящих за 
цисками, или оставлять дырку для спамеров. Судя по всему, разработчики 
postfix из двух зол выбрали меньшее. Камень не в циску, а в админов, 
которые прячут smtp клиентов за цисками.


-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Friday 24 April 2009 08:20:36 Vladimir V. Kamarzin wrote:
> >>>>> On 23 Apr 2009 at 20:49 "DK" == Denis Kuznetsov writes:
>
> DK> Доброго времени суток!
> DK> в main.cf прописано:
> DK> header_checks = pcre:/etc/postfix/header_checks
> DK> mime_header_checks = pcre:/etc/postfix/header_checks
>
> DK> соответственно в /etc/postfix/header_checks:
> DK> /^Received:.*\.altlinux\.org/    OK
> DK> /^Received:.*\d{1,3}-\d{1,3}[-\.]\d{1,3}-\d{1,3}/  REJECT Please use
> ISP relay DK> /^Received:.*dsl\.dynamic\d{1,}\.ttnet\.net\.tr/   REJECT
> Please use ISP relay
>
>        Each  message  header  or  message  body line is compared against a
> list of patterns.  When a match is found the corresponding action is
> executed, and the matching process is repeated for the next message header
> or message body line.
>
> Как уже сказали, используйте check_client_access

Я так понимаю Вы имели ввиду нечто вида:
smtpd_recipient_restrictions =
    ....
    check_client_access pcre:/etc/postfix/access_client_pcre,
    ....

Попробовал, работает. Посмотрим насколько эффективно это будет работать.

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Friday 24 April 2009 11:53:59 Владимир wrote:
> Max Ivanov пишет:
> >> Это "теория", а если внимательно читать логи, то можно видеть, что и
> >> спамеры, и множество
> >> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
> >> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе
> >> установления соединения.
> >
> > Как они это делают?
>
> Если коротко, то "непроизвольно".
> Но, чтобы раскопать, как это получается, пришлось повозиться.
>
> 1. Диалог helo предполагает, что отправитель и получатель, либо находятся
> в одной сети, либо разделены "обычным" маршрутизатором, либо разделены
> "обычным" nat. А вот через посредника proxy диалог без нарушений
> протокола проблематичен.
> Или это не так?
>
> 2. Широко распространенные cisco firewolls только теоретически являются
> "обычными" пакетными фильтрами.
> Для повышения защищенности, на отдельных этапах соединения они срываются
> на  проксирование.
> Или это не так?
>
> 3. Посмотрите в журнале, как поступают письма, например, от yandex.ru (у
> меня стойкое ощущение,
> что их web клиенты сидят за циской). Вы увидите, что диалог "поцокан
> проксей", а информация о helo_hostname вовсе отсутсвует. Хотя письма
> принимаются.
> Или это не так?
>
> Вопрос, что лучше, не принимать писем от всех клиентов сидящих за
> цисками, или оставлять дырку для спамеров. Судя по всему, разработчики
> postfix из двух зол выбрали меньшее. Камень не в циску, а в админов,
> которые прячут smtp клиентов за цисками.


Именно по этой причине меня и смущает:
check_client_access pcre:/etc/postfix/access_client_pcre

и в добавку к нему таки полезен header_checks на предмет Received.
-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Владимир]

Denis Kuznetsov пишет:
>> Как уже сказали, используйте check_client_access
>>     
>
> Я так понимаю Вы имели ввиду нечто вида:
> smtpd_recipient_restrictions =
>     ....
>     check_client_access pcre:/etc/postfix/access_client_pcre,
>     ....
>
> Попробовал, работает. Посмотрим насколько эффективно это будет работать.
>
>   

Шутите? Либо это не работает, либо опечатка в тексте.

check_client_access принимает в качестве аргумента IP address
Для pcre используется check_helo_access (в качестве аргумента fqdn)

check_helo_access имеет смысл перед reject_unknown_helo_hostname  для 
снижения нагрузки

-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix header_checks

[Vladimir V. Kamarzin]

>>>>> On 24 Apr 2009 at 15:22 "f" == fmfm  writes:

>>> Как уже сказали, используйте check_client_access
>>>
>>
>> Я так понимаю Вы имели ввиду нечто вида:
>> smtpd_recipient_restrictions =
>>     ....
>>     check_client_access pcre:/etc/postfix/access_client_pcre,
>>     ....
>>
>> Попробовал, работает. Посмотрим насколько эффективно это будет работать.
>>
>>
f> Шутите? Либо это не работает, либо опечатка в тексте.

Вам стоит перечитать документацию.

f> check_client_access принимает в качестве аргумента IP address

       check_client_access type:table
              Search the specified access database for the client hostname, parent  domains,  client
              IP  address,  or  networks  obtained  by  stripping  least significant octets. See the
              access(5) manual page for details.


-- 
vvk

Postfix page on f.i: http://freesource.info/wiki/Dokumentacija/Postfix

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] postfix header_checks

[Vladimir V. Kamarzin]

>>>>> On 24 Apr 2009 at 14:53 "f" == fmfm  writes:

f> 1. Диалог helo предполагает, что отправитель и получатель, либо находятся
f> в одной сети, либо разделены "обычным" маршрутизатором, либо разделены
f> "обычным" nat. А вот через посредника proxy диалог без нарушений
f> протокола проблематичен.
f> Или это не так?

Это не так. почитайте RFC 5321 уже.

-- 
vvk

Postfix page on f.i: http://freesource.info/wiki/Dokumentacija/Postfix

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Friday 24 April 2009 13:57:08 Vladimir V. Kamarzin wrote:
> >>>>> On 24 Apr 2009 at 15:22 "f" == fmfm  writes:
> >>>
> >>> Как уже сказали, используйте check_client_access
> >>
> >> Я так понимаю Вы имели ввиду нечто вида:
> >> smtpd_recipient_restrictions =
> >>     ....
> >>     check_client_access pcre:/etc/postfix/access_client_pcre,
> >>     ....
> >>
> >> Попробовал, работает. Посмотрим насколько эффективно это будет работать.
>
> f> Шутите? Либо это не работает, либо опечатка в тексте.
>
> Вам стоит перечитать документацию.
>
> f> check_client_access принимает в качестве аргумента IP address
>
>        check_client_access type:table
>               Search the specified access database for the client hostname,
> parent  domains,  client IP  address,  or  networks  obtained  by 
> stripping  least significant octets. See the access(5) manual page for
> details.

никак не шучу. именно работает, сам был удивлен.

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Friday 24 April 2009 12:22:40 Владимир wrote:
> Denis Kuznetsov пишет:
> >> Как уже сказали, используйте check_client_access
> >
> > Я так понимаю Вы имели ввиду нечто вида:
> > smtpd_recipient_restrictions =
> >     ....
> >     check_client_access pcre:/etc/postfix/access_client_pcre,
> >     ....
> >
> > Попробовал, работает. Посмотрим насколько эффективно это будет работать.
>
> Шутите? Либо это не работает, либо опечатка в тексте.
>
> check_client_access принимает в качестве аргумента IP address
до сегодня и я так думал.
> Для pcre используется check_helo_access (в качестве аргумента fqdn)
>
> check_helo_access имеет смысл перед reject_unknown_helo_hostname  для
> снижения нагрузки

дык это что, получаеться недокументированая фича?


-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!
On Friday 24 April 2009 14:19:05 Denis Kuznetsov wrote:
> Доброго времени суток!
>
> On Friday 24 April 2009 12:22:40 Владимир wrote:
> > Denis Kuznetsov пишет:
> > >> Как уже сказали, используйте check_client_access
> > >
> > > Я так понимаю Вы имели ввиду нечто вида:
> > > smtpd_recipient_restrictions =
> > >     ....
> > >     check_client_access pcre:/etc/postfix/access_client_pcre,
> > >     ....
> > >
> > > Попробовал, работает. Посмотрим насколько эффективно это будет
> > > работать.
> >
> > Шутите? Либо это не работает, либо опечатка в тексте.
> >
> > check_client_access принимает в качестве аргумента IP address
>
> до сегодня и я так думал.
>
> > Для pcre используется check_helo_access (в качестве аргумента fqdn)
> >
> > check_helo_access имеет смысл перед reject_unknown_helo_hostname  для
> > снижения нагрузки
>
> дык это что, получаеться недокументированая фича?

Сорри, таки фича документирована в man 5 access. 

-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Владимир]

Vladimir V. Kamarzin пишет:
>>>>>> On 24 Apr 2009 at 15:22 "f" == fmfm  writes:
>>>>>>             
>
>   
>>>> Как уже сказали, используйте check_client_access
>>>>
>>>>         
>>> Я так понимаю Вы имели ввиду нечто вида:
>>> smtpd_recipient_restrictions =
>>>     ....
>>>     check_client_access pcre:/etc/postfix/access_client_pcre,
>>>     ....
>>>
>>> Попробовал, работает. Посмотрим насколько эффективно это будет работать.
>>>
>>>
>>>       
> f> Шутите? Либо это не работает, либо опечатка в тексте.
>
> Вам стоит перечитать документацию.
>
> f> check_client_access принимает в качестве аргумента IP address
>
>        check_client_access type:table
>               Search the specified access database for the client hostname, parent  domains,  client
>               IP  address,  or  networks  obtained  by  stripping  least significant octets. See the
>               access(5) manual page for details.
>
>
>   
Прочтите внимательней, или, в огороде бузина, а в Киеве дядька.

Одно дело, список всех возможных аргументов в таблицах access
Второе дело, конкретная проверка check_client_access, где берется IP 
адрес клиента,
сравнивается с первым полем таблицы и, если нет совпадения или оно не 
похожее на IP (диапазон IP),
строка игнорируется.

Иначе, Вам стоит перечитать документацию, не ограничиваясь одной цитатой 
не к месту
(и полезно проверять на практике, правильно ли воспринято написанное).


-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix header_checks

[Denis Kuznetsov]

Доброго времени суток!

>
> Иначе, Вам стоит перечитать документацию, не ограничиваясь одной цитатой
> не к месту
> (и полезно проверять на практике, правильно ли воспринято написанное).
Да, согласен, еще полезно выспатся перед курением манов (это касательно меня).
Недосмотрел, было так-же и: 
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname,
    check_client_access pcre:/etc/postfix/access_client_pcre

поэтому просто снес лишнюю строку из smtpd_recipient_restrictions как 
результат ничего не поменялось, све работает.

ЗЫ: сорри за дезинформацию. (/me ущел спать).
-- 
Denis Kuznetsov
	mailto: kde@kde.kiev.ua
	jabber: denis.e.kuznetsov@gmail.com

Re: [Sysadmins] postfix header_checks

[Sergey]

On Friday 24 April 2009, Владимир wrote:

> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе 
> установления соединения.
 
При чём тут helo ? Речь об анализе IP-адреса SMTP-отправителя. Опять
же, если смотреть все Received, срежется куча нормальной почты, которая
идёт от клиентов через сервера провайдеров. Проверять надо именно того,
кто пытается доставить на сервер.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Sysadmins] postfix header_checks

[Max Ivanov]

>> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
>> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе
>> установления соединения.
>
> При чём тут helo ? Речь об анализе IP-адреса SMTP-отправителя. Опять
> же, если смотреть все Received, срежется куча нормальной почты, которая
> идёт от клиентов через сервера провайдеров. Проверять надо именно того,
> кто пытается доставить на сервер.

Именно. Неважно за какими nat кто сидит, какие smtp proxy  по пути
появились. Коннект на 25 порт приходит с какого-то определнного
адреса, при коннекте передается HELO имя. Если адрес резолвится в это
же самое имя, то это хороший признак, если нет, а также если адрес
резолвится в домен третьего и более уровня со словами dhcp,
dsl,nat,pool, то это плохой признак.

Re: [Sysadmins] postfix header_checks

[Владимир]

Max Ivanov пишет:
>>> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
>>> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на этапе
>>> установления соединения.
>>>       
>> При чём тут helo ? Речь об анализе IP-адреса SMTP-отправителя. Опять
>> же, если смотреть все Received, срежется куча нормальной почты, которая
>> идёт от клиентов через сервера провайдеров. Проверять надо именно того,
>> кто пытается доставить на сервер.
>>     
>
> Именно. Неважно за какими nat кто сидит, какие smtp proxy  по пути
> появились. Коннект на 25 порт приходит с какого-то определнного
> адреса, при коннекте передается HELO имя. 

Об этом и речь. Если smtp client сидит за проксирующем сетевым устройством,
то поле helo_hostname не передается.

(просмотрите журнал на наличие записей с подстрокой 
client=unknown[IP_address])

Извиняюсь, сейчас нет времени продолжать.

> Если адрес резолвится в это
> же самое имя, то это хороший признак, если нет, а также если адрес
> резолвится в домен третьего и более уровня со словами dhcp,
> dsl,nat,pool, то это плохой признак.
>   


-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix header_checks

[Sergey]

On Monday 27 April 2009, Владимир wrote:

> Об этом и речь. Если smtp client сидит за проксирующем сетевым устройством,
> то поле helo_hostname не передается.
> 
> (просмотрите журнал на наличие записей с подстрокой 
> client=unknown[IP_address])

Это неверная информация. Читайте RFC2821. Например, на тему address literal
и helo вообще.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Sysadmins] postfix header_checks

[Anton Kvashin]

Владимир пишет:
> Max Ivanov пишет:
>>>> законных отправителей (@mail.ru @yandex.ru @gmail.com) легко обходят
>>>> smtpd_helo_restrictions, скрывая информацию о хосте отправителя на 
>>>> этапе
>>>> установления соединения.
>>>>       
>>> При чём тут helo ? Речь об анализе IP-адреса SMTP-отправителя. Опять
>>> же, если смотреть все Received, срежется куча нормальной почты, которая
>>> идёт от клиентов через сервера провайдеров. Проверять надо именно того,
>>> кто пытается доставить на сервер.
>>>     
>>
>> Именно. Неважно за какими nat кто сидит, какие smtp proxy  по пути
>> появились. Коннект на 25 порт приходит с какого-то определнного
>> адреса, при коннекте передается HELO имя. 
> 
> Об этом и речь. Если smtp client сидит за проксирующем сетевым устройством,
> то поле helo_hostname не передается.

Смысл прокси, если есть нарушение протокола?

Прокси можно организовать на MTA, который отдаст в helo/ehlo то, что 
пожелает администратор (PTR, все дела). Возможно нарушив SPF.

PIX скрывает баннер SMTP-сервера, ответ на приветствие, при подключении 
к нему. Само подключение с защищаемого сервера идет валидным (что от 
него и требуется).

-- 
Anton Kvashin

Re: [Sysadmins] postfix header_checks

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Sergey wrote:
 >> В то же время на второй машине обнаруживается блокирование её сетевой
 >> картой свича к которому она подключена. Фактически все машины,
 >> подключенные к этому свичу из сети выпадают. Если выдернуть шнур этой
 >> машины, то свич начинает нормально работать.

 > А tcpdump что-нибудь показывает ? Если свич управляемый, то состояние
 > порта тоже посмотреть не плохо (трафик, ошибки и т.п.). Может что-то
 > прояснится.

Какой там tcpdump? Там интерфейс уже не реагирует ни на какие команды. 
Любой запрос к сети уходит в глубокий ступор примерно на минуту.
Такое подозрение, что это аппаратная проблема. Толи контроллер сети 
перегревается. Однако ранее это не замечалось и начало воспроизводиться 
примерно после обновления ядра до 2.6.30-std-def-alt11. Откатил до 
2.6.30-std-def-alt10 и уже сутки работает.

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [Sysadmins] Странные проблемы с сетью

[Roman Savochenko]

Sergey wrote:
  >> В то же время на второй машине обнаруживается блокирование её сетевой
  >> картой свича к которому она подключена. Фактически все машины,
  >> подключенные к этому свичу из сети выпадают. Если выдернуть шнур этой
  >> машины, то свич начинает нормально работать.

  > А tcpdump что-нибудь показывает ? Если свич управляемый, то состояние
  > порта тоже посмотреть не плохо (трафик, ошибки и т.п.). Может что-то
  > прояснится.

Какой там tcpdump? Там интерфейс уже не реагирует ни на какие команды. 
Любой запрос к сети уходит в глубокий ступор примерно на минуту.
Такое подозрение, что это аппаратная проблема. Толи контроллер сети 
перегревается. Однако ранее это не замечалось и начало воспроизводиться 
примерно после обновления ядра до 2.6.30-std-def-alt11. Откатил до 
2.6.30-std-def-alt10 и уже сутки работает.

P.S. Прошу прощения за предыдущее сообщение с другой темой. Подписку 
только восстановил, а отвечаю с архива.

С уважением, Роман

Re: [Sysadmins] postfix header_checks

[Andrii Dobrovol`s`kii]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

Roman Savochenko пишет:
> Sergey wrote:
>>> В то же время на второй машине обнаруживается блокирование её сетевой
>>> картой свича к которому она подключена. Фактически все машины,
>>> подключенные к этому свичу из сети выпадают. Если выдернуть шнур этой
>>> машины, то свич начинает нормально работать.
> 
>> А tcpdump что-нибудь показывает ? Если свич управляемый, то состояние
>> порта тоже посмотреть не плохо (трафик, ошибки и т.п.). Может что-то
>> прояснится.
> 
> Какой там tcpdump? Там интерфейс уже не реагирует ни на какие команды.
> Любой запрос к сети уходит в глубокий ступор примерно на минуту.
> Такое подозрение, что это аппаратная проблема. Толи контроллер сети
> перегревается. Однако ранее это не замечалось и начало воспроизводиться
> примерно после обновления ядра до 2.6.30-std-def-alt11. Откатил до
> 2.6.30-std-def-alt10 и уже сутки работает.
> 
> С уважением, Роман
> 
Ну так вешайте багу... Не тяните.
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************************************************************


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]