Проблема. Прошу помощи. Из-за того что местный провайдер электронной почты внезапно иниицировал смену пароля авторизации на сервере в ящики моей организации (у нас 13 ящ… (read more)
Проблема. Прошу помощи. Из-за того что местный провайдер электронной почты внезапно иниицировал смену пароля авторизации на сервере в ящики моей организации (у нас 13 ящиков установленных на 50 компьютерах пользователям и все через протокол POP3), то во сразу после того как он это сделал появились:
1. проблема, очень сильно раздражающая: сразу же все почтовые клиенты потеряв доступ к серверу пытаются бесконечно обращаться со старыми реквизитами для авторизации на сервере и каждых 10-60 секунд (мне кажется что 10-30), появляется ошибка о которой описано в предмете вопроса. То есть на момент того как я (администратор) приду к пользователю и введу новый пароль у него на экране появляется и накапливается десятки-а может и сотни окон (если я буду идти часами пока включен компьютер), и тем самым слабые старые компьютеры полностью зависают и я вынужден сначала завершать процесс в диспетчере задач. То есть непонятно такое странное поведение и на мой взгляд некорректное. Достаточно было бы одного окна о том что авторизация невозможна.
2. Проблема очень серьёзная и поэтому я обращаюсь за помощью к вам. Вытекает из п.1, а именно из за сотен запросов на сервер с попыткой авторизации неверными учетными данными (старыми), пока я ещё не успел их ввести пользователям, провайдер блокирует наш IP адрес всей организации и добавляет его в Черный список (с его слов), якобы что у них установлено такое "Правило блокировки: 10 неудачных попыток входа в течении минуты - заносят в Черный список." При этом ошибка авторизации появляется с новой силой. Проблема в том, что в ходе диалога, провайдер якобы утверждает что наш IP адрес они добавлен у себя в исключения, и его блокировка осуществятся не будет. Но фактически ничего не поменялось ДАЖЕ после внесения мною новых учетных данных во всех 50 компьютеров организации почтовые клиенты (для POP3/SMTP обоих протоколов в хранилище паролей). То есть я имею ввиду что ошибка теперь уже несколько дней появляется случайным образом У ВСЕХ почти пользователей различных ящиков организации например от 1 до 10 раз в течение дня, как будто бы почтовые клиенты пытаются также авторизироватся с неверными устаревшими реквизитами и мы снова попадаем у них в черный список - блокировка - ошибка. Кажется что это выглядит так моя теория. Я предполагаю что виноваты могут быть кроме провайдера конкретные сборки моих почтовых клиентов (а это ESR последней версии). Дело в том что год назад я их всем устанавливал следующим образом:
- Установка и полная настройка один раз у себя эталонного клиента с настройками которые я считаю необходимыми каждому.
- Установка у клиента (пользователя) чистой ESR с официального сайта (год назад версия была не той что сегодня)
- Редактирование prefs.js в части замены всех включений от чужого ящика на требуемый в данном месте адрес почты, замена сервера, замена mail.identity.id1.fullName и так далее, то есть полностью проработан вручную файл на каждом отдельном ПК.
- Удалял файл logins.json зная что в нём 100% находится пароль от старого ящика.
Это всё что я делал для смены реквизитов и таким образом преднастроенный заранее и развёрнутый по этой инструкции профиль, работали везде несколько лет до тех пор пока провайдер не решил сменить нам пароли.
На сегодня я понимаю что в профиле пользователя находящемся в Roaming\Thunderbird есть ещё много файлов/папок которые необходимо было удалить прежде чем развёртывать у чужих пользователей с отличающимся адресом почты/сервера.
Таким образом моё предположение и вопрос: где я мог упустить и забыть , в каких файлах могут храниться якобы "старые" учетные данные из за которой появляется ошибка у нас. Если вы подскажете я их удалю и например заново авторизируюсь вручную на каждом ПК и тем самым оставлю в хранилище только новые реквизиты.
Я предполагаю что могут иметь значения следующие файлы:
folderCache.json
folderTree.json
session.json
parent.lock
pkcs11.txt
cert9.db
key4.db
logins.json
times.json
Поправьте если я не прав, имеет ли вобще смысл удалять их, авторизироваться заново. Или же я что то упускаю и есть другие файлы, базы данных откуда может исходить старая авторизация и как следствие появление у нас ошибки из за попадания в черный список провайдера. Если окажется что с моими клиентами всё в порядке то вопроса к вам нет, а он будет только к провайдеру.
На фото представлены 1-десятки наложенных окон друг на друга во время измененного пароля; 2-иногда появляющаяся ошибка после ввода правильных реквизитов к ящику (у всех появляется почти)