Самостоятельно размещённая функция «Ответ по электронной почте» перестала работать после последнего обновления

Мой форум больше не отвечает на сообщения, отправленные по электронной почте.

Раньше функция «ответ по почте» работала нормально, но, похоже, она перестала работать примерно 29 сентября.

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

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

Лог отклонённых писем пуст или показывает «записи не найдены».

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

Тестовые ответы на уведомления о новых сообщениях форума, отправленные с моего собственного адреса Microsoft или с Gmail, не получают предупреждений о недоставке. Они просто исчезают бесследно. В логе электронной почты форума ничего не появляется.

В логе ошибок форума есть несколько предупреждений (иконка жёлтого восклицательного знака) от 29 сентября: «Email can not be processed: Email::Receiver::BadDestinationAddress Received…», которые кажутся безобидными и не отличаются от предыдущих подобных записей. Думаю, это просто отклонённый спам.

1 октября в логе зафиксирована реальная ошибка:

Message

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” is not a valid MIME type)
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

Backtrace

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

Env

HTTP HOSTS: nzarchitecture.net.nz

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

При проверке на www.mail-tester.com ни один из моих адресов не помечен как спамный или находящийся в чёрном списке, и проблем с общением с людьми с этих адресов не возникало.

Форум использует Mailgun, но, полагаю, это только для рассылки массовых писем, и проблемы с аккаунтом Mailgun или API-ключом не должны влиять на входящие сообщения? Кстати, при входе в аккаунт Mailgun я не вижу никаких очевидных проблем или сообщений об ошибках.

Думаю, API-ключ Mailgun должен быть в порядке, раз форум всё ещё отправляет письма корректно.

Никакие настройки форума не менялись с момента, когда «ответ по почте» работал, и галочка настройки «ответ по почте» всё ещё стоит.

Форум размещён на Digital Ocean. Настройки DNS для домена в панели Digital Ocean не менялись, и MX-записи форума выглядят нормально/не изменились.

После возникновения проблемы форум был обновлён до версии 2.8.0 beta 7 (предположительно с пересборкой в процессе), но улучшений не последовало.

Чего мне не хватает?
Что, скорее всего, пошло не так?
Как заставить функцию «ответ по почте» снова работать?

Похоже, эта ошибка не связана с этим.

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

Затем перейдите в Администрирование — Электронная почта — Отклонённые / Полученные / Отклонённые, чтобы понять, что происходит.

Правильно ли настроен ваш «адрес для ответа по электронной почте»?

Привет, спасибо, Ричард.

Я могу подтвердить, что настройки «включено ручное опрос» и «входящие письма» по-прежнему активны.

Я добавил свой адрес Gmail как пользовательский адрес в категорию «сотрудники», но не вижу способа отправлять сообщения сотрудникам через форум? Все ссылки «Связаться с нами» настроены в текстовых настройках форума как ссылки mailto:, которые ведут на мой личный повседневный адрес электронной почты — при нажатии на одну из них открывается мое почтовое приложение, уже заполненное моим личным прямым адресом электронной почты, что означает, что форум никогда не получит сообщение.

Нет, вам следует настроить что-то вроде staff@nzarchitecture.net.nz в настройках категории, а затем использовать свой Gmail для отправки сообщения на этот адрес.

А, понятно.

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

Ваш почтовый сервер настроен на Digital Ocean.

У вас есть почтовый сервер у них?

Это IP-адрес дроплета, на котором работает почтовый приемник.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

Это изменилось за последние 5 месяцев

Я знаю, что происходит. Это снова та проклятая история с LetsEncrypt, которая 30 сентября сломала половину интернета многие вещи.

Просто пересоберите Docker-контейнер почтового приёмника.

хахахаха, да. я забыл об этом. ЛОЛ

Вам нужно подписаться на тему, которую опубликовал @RGJ.

Это должно решить вашу проблему.

А, понятно. Это звучит многообещающе!
Как мне пересобрать «контейнер Docker для получения почты»? Отличается ли это от пересборки «контейнера Docker менеджера», которая происходит при обновлении форума через панель управления?

Мне просто следовать этой инструкции? Как вручную обновить Discourse и образ Docker до последней версии? - как сделать / администраторы - Discourse Meta

Вам необходимо войти в командную строку вашего сайта.

Это делается не через панель администратора форума.

Привет, я смог пересобрать контейнер почтового приёмника, следуя инструкциям по этой ссылке Прямая доставка входящей почты для самохостинговых сайтов - howto / sysadmin - Discourse Meta

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

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

Входящие сообщения не появляются в логе отклонённой почты, но все они отображаются в логе отклонённой почты с предупреждением [Email::Receiver::BadDestinationAddress], включая мою собственную учётную запись администратора, у которой, как я надеялся, внезапно не должно было появиться неверного адреса назначения.

Вы недавно перестраивали свой почтовый сервер?

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

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

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

Я не знал, что принудительное использование HTTPS обязательно для получения входящих писем.

Возможно, отсутствие принудительного HTTPS также вызывало проблемы с входом через Facebook — недавно Facebook уведомил меня, что мой сайт нарушает их условия использования и был приостановлен. В панели управления разработчиком приложений Facebook не было никаких действий, поэтому я подал апелляцию. Ответ был таким: они не смогли проверить сайт из-за неуказанной ошибки, генерируемой URL моего форума.

Кажется, установка галочки «Принудительный HTTPS» никак не помогла с входом через Facebook. Техническая поддержка Facebook по-прежнему сообщает, что для них главная страница сайта выдает предупреждение о безопасности: «Ваше соединение не защищено
NET::ERR_CERT_COMMON_NAME_INVALID».

В соответствии со страницей ошибки, издателем сертификата указан «R3», что, согласно поиску в Google, связано с Let’s Encrypt — той же организацией, чей истекший сертификат потребовал переустановки Discourse.

Это совпадение? Не говорит ли это о том, что в последней сборке Discourse (2.8.0 beta 7) всё ещё есть проблема с сертификатами? Или это не связанная с этим проблема, касающаяся хостинга/Digital Ocean?

Мои собственные неуклюжие поиски в Google привели меня к проверке моего URL через https://www.whynopadlock.com/, результаты которой навели меня на этот пост от пользователя Let’s Encrypt:

Let’s Encrypt недавно обновила свой промежуточный сертификат с «Let’s Encrypt Authority X3» на «R3».

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

В вашем случае, возможно, вы жестко задавали промежуточный сертификат. Если это так, вам нужно использовать новый промежуточный сертификат, который можно найти на https://letsencrypt.org/certificates: https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

Возможно, текущая версия Discourse ошибочно «жестко задает» промежуточный сертификат?

Являются ли «промежуточные сертификаты» чем-то, что администраторы Discourse теперь обязаны управлять? И если да, то как?

Пожалуйста, сообщите, если я ушел не по теме — я не уверен, связано ли это с той же проблемой или нет.