Общий форум

Несколько ошибок в день - это разумный критерий.

Можно попросить пользователя при логине изменить почту или спросить о снятии блокировки.

Понял, нужно будет посмотреть во что это выливается. Очень не хочется ковырять ядро moodle...

Я бы не стал так делать: это костыль и кустарщина, поскольку мы портим данные и провоцируем обработку ошибок при отправке, вместо постановки дополнительного признака.

Хорошую реализацию я вижу так:

• Плагин "локал" со своим справочником.
• Альтернатива - работающий со специальным кастомным полем в поле профиля. Плюсы этого варианта: не нужно создавать и поддерживать отдельный справочник, можно выгрузить список пользователей с этим флагом стандартными средствами. Минусы: дополнительные действия пользователя при установке плагина (что всегда недостаток), возможность изменить флаг ручным редактированием или импортом.
  
• Регистрируем своего обработчика входящих сообщений. Пока не доводилось детально разбираться с этой подсистемой, документация тут: https://docs.moodle.org/dev/Inbound_message_API
• Логируем получение отлупов с привязкой к учетным записям, с которыми связаны эти адреса и указанием кода ошибки.
  
• По расписанию сканируем логи ошибок за период (например, за сутки или за месяц) и принимаем решение о блокировке. Тут все не так очевидно: если сканировать за сутки, мы не увидим людей с неправильными адресами, но которые не подписаны на курсы с активным трафиком в форумы, если сканировать за месяц - повышается вероятность ложных срабатываний и придется принимать специальные меры, чтобы адреса, для которых проблема снята (например, временно не работал smtp-сервер получателя, но теперь работает) не продолжали блокироваться по ранее добавленным событиям.
• Помечаем адрес, как требующий валидации. Сама валидация может включать одну или несколько мер из перечисленных:
• Просто помечать адрес, как неподтврержденный. Это просто, но не эффективно: во-первых, такие учетные записи могут быть автоматически удалены, если не отключить автоудаление неподтвержденных учетных записей. Во-вторых, будет затруднительно отделить их от вновьзарегистрированных. В-третьих, это не позволит нам автоматически отследить, если проблема исправится сама (пользователь почистил свой ящик и т.п.)
  
• Перенаправлять пользователя на самописную форму подтверждения адреса при авторизации. Вариант более трудоемкий, но и более акурантый, позволяет сообщить пользователю, что же с ним произошло и дать инструкцию, как с этим справится.
• Предоставить администратору список проблемных пользователей для обзвона и ручного управления. Этот вариант только на первый взгляд кажется излишним, в коммерческом обучении он очень востребован. В обучении с постоянным контингентом (студенты, школьники, сотрудники) - еще более востребован, если задуматься.
• Проверять, включены ли альтернативные способы доставки оповещений для пользователя (внутренние сообщения, смс, jabber, соцсети и пр.) и отправлять уведомление туда. Можно при этом отключать уведомления с почты и включать на альтернативные способы, можно просто отправить уведомления о том, что надо проверить работу почтового ящика.
  
• С некоторой периодичностью отправлять на адрес контрольное письмо и при отсутствии отлупа, снимать признак блокировки.
• Вместо логирования можно сделать просто счетчики, которые обнулять при разблокировке. Например, раз в неделю всех разблокировать и накапливать ошибки по-новой. Можно сделать еще счетчик разблокировок, чтобы обнаруживать тех, у кого проблема системная. Возможно, эта конструкция будет удобнее конструкции с логами, сканерами ошибок и роботом для монитринга, сохраняется ли ошибка: просто раз в неделю всех разблокировать, у кого больше 2-х разблокировок уже через месяц, у кого больше 5 - через 3 месяца и т.д.