[vadblm]

помогает fix от ms для сброса TCP стека »

или защита centos срабатывает ? »

Похоже, фаер на центосе настроен лимитировать количество соединений с хоста. Это легко проверить, сделав листинг правил iptables -nvL -t filter.

[batyaPS]

это может быть причиной если на ПК пропатчен TCP на 100 соединений?

проблема в том, что на части ПК всё работает и почту можно хоть каждую секунду запрашивать, а на части нет.

проверил на проблемных ПК полуоткрытые соединения, всё стандартно 10 соединений

[vadblm]

это может быть причиной если на ПК пропатчен TCP на 100 соединений? »

Что вы имеете ввиду под этим? Установлен максимум в 100 одновременных соединений на данном конкретном хосте? Да, может, если из-за лимита на хосте соединения принудительно преждевременно закрываются, а новые открывать сервер своими правилами запрещает. Но зачем гадать, если можно проверить. Включить в фаере логирование (если ещё не включено) правил DROP, попытаться воспроизвести ситуацию, одновременно смотря лог.

[batyaPS]

vadblm,
проблема в том что доступа к серверу не имею
а патч проверил, нет его, т.е. кол-во соединений 10.

для эксперимента накатил данный патч на рабочей системе, почта так же продолжает работать,
т.е. дело не в этом.
может кеш какой сидит в реестре? и его сброс помогает.

[vadblm]

проблема в том что доступа к серверу не имею »

Обратитесь к тому, кто имеет. Если между вами и сервером есть ещё какой-нибудь фаервол, обратитесь также и к его администратору. Словом, обращайтесь с проблемой к админу, а не на форум, админ вам сразу даст инфу — есть ли ограничения и какие, а мы тут можем до второго пришествия гадать.

[batyaPS]

Обратитесь к тому, кто имеет. Если между вами и сервером есть ещё какой-нибудь фаервол, обратитесь также и к его администратору. Словом, обращайтесь с проблемой к админу, а не на форум, админ вам сразу даст инфу — есть ли ограничения и какие, а мы тут можем до второго пришествия гадать. »

не тот случай, проблемы мои так как часть ПК почту получают, значит косяк локальный.

[vadblm]

не тот случай »

Как вы можете быть в этом уверены, не видя логов с сервера/фаервола? Чтобы такое заключение сделать, нужно сначала убедиться, что действительно пакеты не доходят до сервера, а не дропаются им (или фаером по пути) по какой-то причине.

часть ПК почту получают, значит косяк локальный. »

Вовсе не обязательно, на "везучей" части ПК м.б. меньше соединений устанавливается, что позволяет не превышать лимит.

Во всяком случае, проблему надо рассматривать со всех сторон, хотя бы для того, чтобы исключить часть возможных причин. У вас что-то личное, раз вы не хотите привлечь к решению проблемы админа почтовика? Это ж его работа.

Ну можно пойти и сложным путём, поднять в локалке сниффер (WireShark например) и смотреть, что происходит с пакетами.

[batyaPS]

Как вы можете быть в этом уверены, не видя логов с сервера/фаервола? Чтобы такое заключение сделать, нужно сначала убедиться, что действительно пакеты не доходят до сервера, а не дропаются им (или фаером по пути) по какой-то причине. »

я то не уверен, это как говорится проблемы индейцев.

Во всяком случае, проблему надо рассматривать со всех сторон, хотя бы для того, чтобы исключить часть возможных причин. У вас что-то личное, раз вы не хотите привлечь к решению проблемы админа почтовика? Это ж его работа. »

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

мне бы хотя бы подсказать где может крытся такая проблема на стороне пК, есть полный реестр до фикса и после, но изменений столько что всё перепроверять не реально.

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

[batyaPS]

вот нарезал из полного реестра ветку TCP до и после фикса
может какие изменённые параметры покажутся подозрительными ?