Заметки о блокировке или удалении пользователей

[TonyG]

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

1. Когда мне нужно заблокировать пользователя из-за возврата писем (bounce), я не хочу, чтобы ему отправлялось уведомление об этом событии.
2. Я не вижу опции в панели администратора для добавления собственной причины блокировки в существующий список. Я хотел бы добавить «Возврат писем».
3. Я хотел бы установить одну из доступных длительностей блокировки как значение по умолчанию. Мне не хочется выбирать период времени из выпадающего списка для каждого случая.
4. Я хочу уведомить пользователя о причине блокировки, предоставив больше информации, чем одна строка в поле «причина». Есть поле для отправки пользователю письма с примечанием, но это снова отправляет письмо. Мне просто нужно отправить сообщение, так как я знаю, что email не работает.
5. Отправляются ли другим пользователям Discourse письма после того, как пользователь был заблокирован или ограничен в действиях? Для этого конкретного сценария и, возможно, других я не хочу, чтобы этому пользователю отправлялись какие-либо письма, особенно если он подписался на множество уведомлений.
6. Касательно удаления пользователя в этом же сценарии: мы можем просто удалить пользователя, а также «удалить и забанить как адрес электронной почты, так и IP-адрес». Почему эти действия связаны? Мне нравится идея блокировки адреса электронной почты. Блокировать IP-адрес мне может понадобиться редко. Однако блокировка IPv4-адреса неудобна по ряду причин — возможно, с IPv6 это приемлемо, но мы еще не дошли до этого момента. Пока эти концепции не разделены, нельзя ли просто блокировать адрес электронной почты? Если бы я лучше знал внутреннее устройство Discourse, я бы с радостью написал скрипт для очистки определенных элементов из списков блокировок, но я не знаю, где найти эти данные.
7. Для этого сайта активирован MaxMind, и я хотел бы использовать IP-адрес для определения местоположения, чтобы помочь решить, следует ли просто заблокировать пользователя или удалить его. Например, если последний использованный адрес находится далеко от адреса регистрации (плюс другие метрики), я бы удалил аккаунт, так как он просто «пахнет плохо». Однако во всплывающем окне с информацией об IP-адресе не отображается местоположение. Это ошибка, или мне стоит снова проверить MaxMind?
8. Я получаю уведомления о возвратах на адрес postmaster@ — именно так я узнаю, что письма с форума возвращаются. Кто-то может предложить мне изучить функцию Bounce Score для автоматического отключения, чтобы не отправлять письма тем, у кого уже зафиксированы возвраты. У нас нет данных о возвратах для оценки, я не настроил Discourse на опрос POP3 (IMAP??) для получения таких данных. В разделе meta я вижу только форумные истории о том, как это настроить. Есть ли какая-то реальная отдельная документация по этой теме?

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

Надеюсь, это поможет — и спасибо!!!

[twofoursixeight]

@TonyG

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

Думаю, если оставить поле причины заглушения пустым, письмо ему отправлено не будет.

@TonyG

Я не вижу административной опции для добавления произвольной причины заглушения в существующий список. Хотел бы добавить «Отскок писем».

По этому вопросу обратитесь к Custom Predefined Suspension Reasons

• Это основано на моих знаниях о Discourse (может быть неточно, но я стараюсь помочь!)

[TonyG]

2468 — мы очень ценим это!

[Moin]

@Tony G

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

Как вы настроили параметры сайта bounce score, особенно bounce score threshold?

[TonyG]

Я еще не настроил порог оценки возвратов, так как у меня Discourse не проверяет почту на наличие уведомлений о возвратах. Информация в этой теме на meta — лучшее, что я нашел по теме настройки обработки возвратов. В ближайшие несколько дней я буду искать более полную документацию.

Но да, сегодня я установлю очень низкий порог для возвратов.

[Architect]

@twofoursixeight

Я полагаю, что если оставить поле причины молчания пустым, то им не будет отправлено письмо.

Нет, это неверно.

Прежде чем будет возможна блокировка аккаунта, необходимо выбрать или указать причину.

[TonyG]

@Architect

Должна быть указана или записана причина, прежде чем станет возможным заблокировать аккаунт.

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

Итак, с какими проблемами новичка я сталкиваюсь сейчас:

• Мне нужно это сообщение пользователю, но я бы предпочел изменить его текст. Изменение admin/customize/email_templates/system_messages.email_revoked для английского языка не меняет его для всех остальных языков. Или есть функция автоматического перевода для одного или всех системных сообщений?
• Без поиска по admin/customize/email_templates/ сложно найти нужные тексты системных сообщений или уведомлений пользователей для редактирования и понять, какие процессы их вызывают.
• Я не хочу отправлять электронное письмо, когда по определению проблема заключается в том, что пользователь не получает письма.
• Когда я отвечаю на системное сообщение в профиле пользователя, отправляется еще одно электронное письмо. Если мы сможем эффективно блокировать исходящую почту для этого адреса, этого не произойдет. То есть все функции отправки исходящей почты проходят через центральный процесс, который сначала проверяет, не превышен ли порог возвратов? Или я упускаю какую-то функцию «Тихий режим» (Silence), которая блокирует исходящую почту без привязки этого решения к порогу возвратов?
• В идеале, когда пользователь заменяет адрес электронной почты на корректный или нажимает кнопку проверки «мой адрес теперь в порядке», было бы здорово, если бы сервер отправлял тестовое письмо, и в случае успеха сбрасывал бы флаг/счетчик возвратов.
• (Случайно) Существует фиксированное количество значений в admin_js.admin.user.suspend_reasons, и они «жестко» определены, чтобы исключить возможность их кастомизации для других целей. То есть мы можем изменить текст для admin_js.admin.user.suspend_reasons.combative, и есть одно значение admin_js.admin.user.suspend_reasons.custom, но похоже, что мы не можем создать новое admin_js.admin.user.suspend_reasons.bouncing_email.

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

Я подозреваю, что все это описывает очень тонко настроенное поведение, которое, вероятно, не попадет в список приоритетов, но пока не знаю, как другие люди справляются с этим. Спасибо за терпение…

[TonyG]

Просто держу эту тему в актуальном состоянии, сообщая о прогрессе…

Я только что нашёл документацию по настройке обработки возвратов писем:

Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver

Discourse is all about enabling civilized discussion. While plenty of people like a web interface, e-mail is still the “hub” of many people’s online lives. That’s why sending e-mail is so important, and when you’re sending e-mail, you really want to be able to receive it, too. There are several reasons why: If e-mails “bounce” (they can’t be delivered for some reason), you need to know about that. Repeatedly sending e-mails that bounce will get your e-mails flagged as spam. Receiving e-ma…

Configure VERP to handle bouncing e-mails

Setting up bounces handling Discourse uses the Variable envelope return path (VERP) technique to handle bouncing e-mails. To enable VERP, set the “reply by email address” site setting with an email address template that uses the + sign. The default of replies+%{reply_key}@discourse.example.com … works fine. If you are using your own or your company’s email server, then, that’s it Your discourse instance must be able to receive email sent to this address. This should work via POP, bu…

Здесь также крайне полезны изображения:

Bounced emails not being detected

the reply_by_email_address is not used as the from address but the envelope-from, specifically so bounces work Here’s an image that demonstrates how each address is used. The addresses themselves are specific to our hosting, but should be sufficient for an example. notification_email: notifications@hs1.discoursemail.com reply_by_email_address: incoming+%{reply_key}@hs1.discoursemail.com A notification: [image] A replyable message: [image]

Реализация этой функциональности должна решить достаточно проблем, чтобы эффективно обрабатывать возвраты писем. Мне всё ещё нужно продумать, как мы будем эффективно уведомлять многоязычную базу пользователей и быстро возвращать их к работе, когда они устранят проблемы с электронной почтой. То есть, когда они внесут необходимые изменения, им нужно будет уведомить нас или систему, чтобы снять с них блокировки.

[Architect]

@TonyG

Этот сценарий применим не только к возвратам писем. Я могу придумать и другие ситуации, когда нам нужно уведомить пользователя локальным сообщением о том, что мы не можем отправить ему письмо, и предоставить ему сохранённое пользовательское сообщение с инструкциями, что делать.

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

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

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

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

[TonyG]

Мы с вами на одной волне. Разные менеджеры могут по-разному подходить к разным ситуациям. Я сейчас изучаю это программное обеспечение, чтобы понять, что оно делает, как задумано его использование и как его применяют другие.

Основная цель этой инициативы/расследования двоякая: во-первых, проактивно предотвратить злоупотребления; во-вторых, избежать отправки писем, которые не дойдут до адресата, что может привести к тому, что наш сайт будет помечен как источник недоставляемой почты. Это может повлечь за собой временное внесение в чёрные списки RBL, и я хочу избежать такой чепухи.

Хотя трафик на этом сайте невелик, здесь есть пользовательские группы, похожие, но отличные от TL0–4. Пользователей одной группы не следует блокировать, если с их почтой возникнут проблемы. Пользователей другой группы, у которых есть несколько недавних тематических сообщений, также не следует блокировать. Аккаунты без активности или без недавней валидной активности могут быть заблокированы, чтобы привлечь внимание, если владелец когда-нибудь вернётся.

Сама идея блокировать людей, чтобы привлечь их внимание, кажется неуклюжей. И мне на самом деле не так важны адреса электронной почты. Суть в том, что если у нас указан недостоверный адрес, я склонен считать, что такой аккаунт с большей вероятностью может стать источником злоупотреблений. Поэтому я буду заранее блокировать таких пользователей, запрашивать у них ответ, и если от них не последует реакции в течение длительного времени, просто удалять аккаунт. Активный пользователь (TL1?), от которого мы давно не получали вестей, может быть переведён в режим долгосрочной блокировки/проверки.

Поскольку мы уже здесь, всё это также подразумевает, что люди создают аккаунты без действительного адреса электронной почты или меняют его на некорректный. Я изучаю раздел Documentation и планирую создать автоматизацию: блокировать новых пользователей TL0 до тех пор, пока они не просмотрят несколько тем, а затем отправлять им письма. Если от этих конкретных сообщений поступит уведомление о недоставке, переводить таких пользователей в статус на проверку. Таким образом, приветственное письмо будет отправлено только после того, как мы убедимся, что это реальный человек, перемещающийся по сайту, а разрешения будут предоставлены только после подтверждения адреса электронной почты.

[JammyDodger]

Кстати, активировать учетную запись невозможно без предварительной проверки электронной почты (если только администратор не активирует её вручную или вы не используете SSO и не подтверждаете вход через провайдера идентификации).

[Architect]

@Tony G

Всё это также подразумевает, что люди создают аккаунты без действительного адреса электронной почты или меняют его на недействительный.

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

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

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

@Tony G

Хочу создать автоматизацию: замолчать новых пользователей уровня TL0, пока они не просмотрят несколько тем, а затем отправить им письмо. Если от этих конкретных сообщений поступит уведомление о недоставке, перевести их в статус на рассмотрении. Таким образом, приветственное письмо не будет отправлено, пока мы не убедимся, что это человек, перемещающийся по сайту, и разрешения не будут предоставлены, пока мы не убедимся, что они подтвердили свой адрес электронной почты.

Это уже в основном включено в настройках по умолчанию. Хотя пользователи уровня TL0 могут публиковать публичные ответы и темы, они не могут отправлять личные сообщения другим пользователям, пока не будут повышены до базового уровня TL1, что требует прочтения определённого количества материалов, а также предварительной проверки адреса электронной почты.