Улучшенная обработка отклонения писем

Внести вклад Функция
1

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

Например, письма, отправленные с адресов mac.com на наш адрес поддержки, часто отклоняются из-за отсутствия тела сообщения (Email::Receiver::NoBodyDetectedError). При этом в этих письмах часто действительно есть текст, поэтому, возможно, проблема в парсинге.

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

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

В противном случае, если мы не хотим пропускать входящие письма в службу поддержки, нам придётся постоянно опрашивать список отклонённых писем в бэкенде Discourse. Это утомительно и излишне.

2 лайка
2

Я думаю, лучше сосредоточиться на конкретном примере. Вы сказали, что отклонение происходит «часто» — заметили ли вы какие-либо закономерности в содержимом писем? Если бы это была постоянная проблема, я бы ожидал, что все письма с mac.com будут отклоняться.

2 лайка
3

Что ж… «часто» в смысле «достаточно часто, чтобы это начинало раздражать». Наша главная забота заключается в том, чтобы пользователи не злились из-за кажущегося отсутствия реакции со стороны нашей службы поддержки.

Я искал закономерности в тех случаях, которые мне удалось заметить. Сначала я думал, что проблема может быть в том, как mac.com обрабатывает электронную почту, но позже выяснил, что у нас есть около 30 пользователей с адресами mac.com, у которых никаких проблем не возникает.

Также я предполагал, что если у mac.com есть веб-клиент для почты, то он может обрабатывать HTML-письма нестандартным образом. Но я даже не уверен, что у mac.com вообще есть такой веб-клиент.

Мне казалось, что я всё понял, когда осознал, что в последнем инциденте речь шла о письме, в теле которого были только цитируемые строки, но последующие тесты показали, что Discourse корректно обрабатывает такие письма.

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

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

2 лайка
4

Адреса электронной почты Mac.com на самом деле являются аккаунтами iCloud.com. Apple перевела аккаунты Mac.com и me.com на iCloud пять или шесть лет назад.

5

Спасибо за уточнение. То есть, если возникают проблемы с электронной почтой на адресах mac.com, это должно затрагивать и адреса me.com, а также другие адреса iCloud.

6

Никакой чёткой закономерности нет. Есть 21 случай, когда причина отклонения не совсем ясна или кажется ошибочной.

  • 1 раз: «Email can not be processed: Body is too similar to what you recently posted»
  • 8 раз: «Email can not be processed: Email::Receiver::BadDestinationAddress» — эти случаи довольно загадочны; почему адреса считаются некорректными?
  • 3 раза: «Email can not be processed: Email::Receiver::NoBodyDetectedError» — в двух случаях текст сообщения выглядит нормально; в одном просто указано «no body»
  • 1 раз: «Email can not be processed: Email::Receiver::TooShortPost»
  • 6 раз: «Email can not be processed»
  • 1 раз: «Email can not be processed: Sorry, new users can only put one image in a post.»
  • 1 раз: «Uncaught Error: Syntax error, unrecognized expression: #xxxxxx-email:product at company dot com»

Несколько из этих случаев касались легитимных попыток коммуникации со стороны клиентов. Остается неясным, попало ли письмо об отклонении, отправленное Discourse, в папку «Спам» у отправителя или было просто проигнорировано.

7

Они отправили на адрес, который вы не обрабатываете, например, на support.

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

8

Я проверил несколько таких случаев (Email::Receiver::BadDestinationAddress), и многие из них, похоже, являются легитимными ответами от клиентов, где получатель указан в формате: replies+longidentifier@discourse.site.com. Уведомительное письмо, которое Discourse отправляет отправителю, предполагает, что письмо было отправлено с адреса, отличного от того, который связан с соответствующей темой, — это, вероятно, объяснение. Однако в таких случаях я всё же хотел бы, чтобы сотрудники получали уведомление.

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

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

1 лайк
9

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

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

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

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

Кроме того, хотя Discourse и отправляет отправителю письмо об отклонении с потенциально полезной информацией, я считаю, что такие письма иногда попадают в папку «Спам», что ещё больше путает затронутых клиентов.

1 лайк
10

Это доставляет неудобства. Я думаю, что способ решить часть этих проблем может быть описан здесь: IMAP support for group inboxes.

Однако я не уверен, как решить проблему ответов из неправильного почтового ящика. (И черт возьми, я ненавижу контактные формы — независимо от того, с какой стороны от них я нахожусь!)

1 лайк
11

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

Если бы мы разрешили ответы на такие письма с других адресов, это открыло бы возможность злоупотреблений через email, когда кто-то выдаёт себя за другого пользователя. Мы иногда сталкиваемся с такой проблемой в наших собственных сообщениях поддержки здесь, на meta.

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

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

2 лайка
12

Да, как я уже говорил, имеет смысл отклонять такие сообщения. Но я всё же хотел бы получать уведомления, когда это происходит.

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

1 лайк
13

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

14

Я тоже не знаю, поэтому и разместил это как запрос на добавление новой функции.

Да, понятно. Но переходить на эту страницу и нажимать «Обновить» каждые несколько минут кажется довольно неэффективным.

Плагин подошел бы, но я не понимаю, почему эту функцию нельзя просто добавить в сам Discourse. Для меня это кажется очевидным решением. Discourse уже отправляет различные уведомления администраторам и сотрудникам сайта. Сделайте настройку (уведомление об отклонении письма) отключенной по умолчанию — это, думаю, подойдет многим сайтам.

3 лайка
15

Эм, да. Извините. :man_shrugging:

1 лайк
16

Ещё один пример: клиент отправил письмо на адрес поддержки, чтобы сообщить о проблеме с покупкой. Discourse отклонил его письмо: [Email::Receiver::InactiveUserError].

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

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

Существует ли какая-то техническая причина, по которой администраторы не могут получать уведомления об отклонении писем?

2 лайка
17

Если ответ по электронной почте слишком короткий (например, «OK»), это приводит к отправке пользователю ошибочного сообщения об ошибке, о котором я сообщил здесь: Wrong Error Message for too short replies for Reply-by-Email

Кроме того, такие отклонения не регистрируются в разделе /admin/email/rejected. Было бы хорошо, если бы они где-то регистрировались.

1 лайк