Отсутствуют пробелы в тексте сводки активности в письме

Я только что отправил себе несколько превью-сводок, так как обычно их не получаю.

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

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

Выдержки:

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

Сталкивался ли кто-то ещё с этим или есть идеи, что происходит?

Возможно, это проблема со шрифтом или отображением? Проверили ли вы исходное содержимое?

Хм. Не уверен, как диагностировать проблему с шрифтом или отображением. Письма отображаются одинаково в различных почтовых клиентах и браузерах на Windows и Linux.

Я прикрепил .json к ссылкам на посты на форуме, и в содержимом “topic_slug” или “cooked” ничего странного нет…

Есть ли что-то ещё, что я мог бы проверить в необработанном содержимом?

Вам нужно проверить исходный код письма, а не пост.

Хорошо — я просмотрел исходный код письма, и там, где в HTML-версии отсутствуют пробелы, в текстовой версии они есть. Однако в текстовой версии отсутствуют другие символы пробела. В этом нет никакой логики.

Возможно, это сбой кодировки символов при копировании затронутых тем с устаревшей платформы? РЕДАКТИРОВАНИЕ: Нет. Проблема сохраняется в текущих постах, а также в других письмах — не только в сводке.

Более свежие сводки Discourse с текущими постами не имеют такой проблемы, поэтому я не буду сильно беспокоиться, пока это не продолжится. РЕДАКТИРОВАНИЕ: Проблема продолжается.

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

Не могли бы вы переслать мне одно из этих писем в виде вложения?

РЕДАКТИРОВАНИЕ: готово

Хорошо, вот что я вижу в сыром тексте письма:

[Дезинформация и ложная информация начинают захлестывать цивилизацию][2]

Темная сторона генеративного ИИ заключается в том, что он позволяет производить дезинформацию (из-за конфабуляции) и ложную информацию (т. е. умышленное создание фальшивых новостей для достижения цели) в промышленных масштабах. Рендеринг веб-страниц в стиле авторитетных источников прост, а прогресс в области дипфейков сделает создание видеосторий проще. Помимо «облаков» ложной информации, скрывающих правду, о которых писал Виндж в «Конец радуги» (Rainbow's End) — и я не считаю это решением, — думали ли об этом авторы научной фантастики и как это можно решить?

примечание:

  • to overwhelm :white_check_mark:
  • a paperback :white_check_mark:
  • Renderingof :x:
  • Asidefrom :x:

а в HTML-версии:

<a href="https://forum.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style="text-decoration: none; font-weight: bold; color: #006699;; font-weight:400;line-height:1.3;margin:0;padding:0;text-decoration:none">
<strong>Дезинформация и ложная информация начинают захлестывать цивилизацию</strong>
…
Рендеринг веб-страниц в стиле авторитетных источников прост, а прогресс в области дипфейков сделает создание видеосторий проще. Помимо

примечание:

  • tooverwhelm :x:
  • apaperback :x:
  • Rendering of :white_check_mark:
  • Aside from :white_check_mark:

В самой сырой (т. е. закодированной) форме эти ошибки всё ещё присутствуют:

[Дезинформация и ложная информация начинают захлестывать цивилизацию][2]
            
 Темная сторона = 
генеративного ИИ заключается в том, что он позволяет производить дезинформацию (= 
из-за конфабуляции) и ложную информацию (т. е. умышленное создание фальшив=
ых новостей для достижения цели) в промышленных масштабах.   Рендеринг веб-страниц в т=
ом стиле авторитетных источников прост, а прогресс в области дипф=
ейков сделает создание видеосторий проще.  Помимо «облаков» Винджа = 
ложной информации, скрывающих правду (Конец радуги), которые, по моему мнению, не=
 являются решением, думали ли об этом авторы научной фантастики и как это можно решить?
Кен
                                  <a href=3D"https://foru=
m.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style=
=3D"text-decoration: none; font-weight: bold; color: #006699;; font-weight:=
400;line-height:1.3;margin:0;padding:0;text-decoration:none">
           =
                         <strong>Дезинформация и ложная информация начинают захлестывать цивилизацию</strong>

этих ошибок нет в сыром/обработанном виде:

000000d0: 5265 6e64 6572 696e 6720 6f66 2077 6562  Рендеринг веб
000000e0: 2070 6167 6573 2069 6e20 7468 6520 7374   страниц в ст
000000f0: 796c 6520 6f66 2061 7574 686f 7269 7461  иле авторита
00000100: 7469 7665 2073 6f75 7263 6573 2069 7320  тивных источнико
00000110: 7374 7261 6967 6866 6f72 7761 7264 2c20  в прост, 
00000120: 616e 6420 7072 6f67 7265 7373 2069 6e20  и прогресс в 
00000130: 6465 6570 2066 616b 6573 2077 696c 6c20  области дипфейков
00000140: 6d61 6b65 2076 6964 656f 2073 746f 7279  сделает создание видеосторий
00000150: 2063 6f6d 706c 656d 656e 7473 2065 6173   проще.  Помимо
00000160: 6965 722e 2020 4173 6964 6520 6672 6f6d  от

Не то чтобы я не верил вам :smiley:

Итак… пробелы иногда удаляются из тела письма, будь то текстовая часть или HTML-часть. И не в одних и тех же местах!

Я предполагаю, что эти ошибки могли возникнуть в одном из четырёх мест:

  • в Discourse при генерации письма
  • при передаче письма на сервер отправки электронной почты
  • при передаче письма на промежуточный/конечный сервер
  • при доставке в почтовый ящик пользователя

Наверное, проще всего начать с самого начала.

Можете ли вы настроить Discourse так, чтобы он отправлял письма на локальный MTA, где вы сможете проверить их в очереди до того, как MTA отправит их на ваш «реальный» сервер доставки электронной почты?

Спасибо за анализ, Майкл!

Я не продвинутый администратор почты — у меня стандартная рекомендуемая самостоятельная установка с фактической исходящей почтой через MailerSend.net, и я тщательно настроил DKIM/DMARC и другие параметры до рабочего состояния. Судя по тому, что я читаю, внедрение локального MTA, такого как sendmail или Postfix, — это продвинутое решение, которое в большинстве случаев не рекомендуется… Я немного опасаюсь лезть в настройки и возможного нарушения работающего процесса. :grimacing:

Есть ли какое-то простое в откате, диагностическое решение с использованием MTA, которое я мог бы рассмотреть?

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

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

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


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

Эти повторяющиеся сообщения присутствуют в предпросмотре сгенерированных резюме.

РЕДАКТИРОВАНИЕ 2024-04-26: проблема с повторяющимися резюме была выявлена. В ожидании исправления я смягчил проблему изменением настроек, но, похоже, она не связана с этой темой. В исходящих письмах по-прежнему отсутствуют пробельные символы.


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

Если эти проблемы возникают не у всех, кто использует актуальную ветку tests-passed, на что мне стоит обратить внимание в моей настройке?

Если вы сможете временно отключить TLS между вашим сервером и MailerSend, это позволит вам просматривать фактический трафик в сети и окончательно выяснить, отправляет ли Discourse пробелы или нет.

Если это невозможно, можно попробовать перехватить трафик (MITM), но это более сложный вариант.

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

Таким образом, вы сможете отправлять письма через Discourse любым из этих методов и просматривать письма в очереди Postfix перед их отправкой.

Спасибо, Майкл. Я новичок в «прослушивании трафика», но вот что я обнаружил.

MailerSend требует TLS и порт 587. Поэтому:

  • Я создал альтернативный файл app.yml для отправки на бесплатный аккаунт Mailtrap.io через порт 2525;
  • установил DISCOURSE_SMTP_ENABLE_START_TLS = false;
  • применил изменения командой:
cd /var/discourse
./launcher destroy app
./launcher start app
  • настроил Wireshark для мониторинга удалённого трафика через tcpdump.

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

РЕДАКТИРОВАНИЕ: Мне пришло в голову, что я не до конца использовал возможности тестовой настройки Mailtrap. Позже я отправил несколько зашифрованных превью-резюме в Mailtrap — через порт 587 с включённым TLS — и не обнаружил никаких пропущенных пробелов. Теперь я думаю, что, несмотря на утверждения MailerSend о том, что проблемы присутствуют в полученных запросах, они возможно возникают на их стороне. Не совсем понятно, что именно им стоит проверить, но я планирую обсудить с ними эти выводы.

На всякий случай: я быстро проверил свою настройку и не обнаружил проблем. Возможно, у вас есть тема или плагин, влияющие на вашу конфигурацию. Я поступил следующим образом: зашел на mail-tester.com, чтобы получить временный адрес, затем использовал раздел Администрирование → Электронная почта → Предварительный просмотр сводки, чтобы отправить сводку на этот временный адрес, а затем перешел по ссылке на mail-tester, чтобы просмотреть HTML-версию и версию в обычном тексте. Возможно, стоит попробовать тот же подход, чтобы проверить, есть ли у вас какие-либо отличия.

Спасибо, Эд. Чтобы добраться до mail-tester, мои письма должны были бы пройти через мой релей MailerSend, который я как раз пытался исключить из цепочки. Но ваш комментарий побудил меня вернуться к Mailtrap и провести тесты с шифрованием TLS, поэтому я отредактировал свой предыдущий пост.

Я тоже считаю это вероятным.

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