Если мне не нужны никакие расширенные функции, значит, мне не нужно использовать переменные POSTCONF_smtpd_tls..., верно?
Сайт, конечно же, использует https.
Если мне не нужны никакие расширенные функции, значит, мне не нужно использовать переменные POSTCONF_smtpd_tls..., верно?
Сайт, конечно же, использует https.
Вам не понадобятся указанные выше варианты, но для поддержки шифрования TLS вам всё же потребуется конфигурация TLS из файла samples/mail-receiver.yml, адаптированная под ваше доменное имя.
Если вы используете шаблон Let’s Encrypt для HTTPS, достаточно раскомментировать соответствующие строки из образца и заменить доменное имя.
хм, а есть какие-то идеи, почему это перестало работать недавно и показывает эту ошибку, связанную с сертификатами?
<19>Oct 6 19:18:27 receive-mail[94]: Не удалось выполнить POST-запрос с письмом на https://www..../admin/email/handle_mail:
SSL_connect вернул=1 errno=0 state=SSLv3 read server certificate B:
ошибка проверки сертификата (OpenSSL::SSL::SSLError)
<19>Oct 6 19:18:27 receive-mail[94]: /usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `connect_nonblock'
/usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `ssl_socket_connect'
/usr/local/lib/ruby/2.3.0/net/http.rb:928:in `connect'
/usr/local/lib/ruby/2.3.0/net/http.rb:863:in `do_start'
/usr/local/lib/ruby/2.3.0/net/http.rb:852:in `start'
/usr/local/lib/ruby/2.3.0/net/http.rb:1384:in `request'
/usr/local/lib/ruby/site_ruby/mail_receiver/discourse_mail_receiver.rb:42:in `process'
Итак, ошибка показывает, что письмо получено, но не удаётся проверить сертификат при попытке подключения к вашему экземпляру Discourse. Это говорит о том, что проблема не в чём-то другом, что подключается к вашему почтовому приёмнику, хотя это не обязательно означает, что TLS работает корректно (письмо могло быть доставлено без TLS).
По этой ошибке сложно точно сказать, что происходит, но если вы перейдёте по адресу https://www.... (домен точно так, как он указан в сообщении об ошибке) в браузере, подключится ли он успешно?
Если да, то это, скорее всего, означает, что ваш почтовый приёмник по какой-то причине не доверяет ему.
Если нет, то это может указывать на проблему с настройкой SSL в файле app.yml (например, получен сертификат только для example.com, а не для www.example.com) или на ошибку в URL Discourse в файле mail-receiver.yml (например, используется www.example.com, хотя должно быть просто example.com).
Если вы укажете имя хоста, мы сможем помочь вам эффективнее.
Вы меняли доменное имя своего сайта? Правильно ли настроен сертификат на сайте?
Были ли в последние 90 дней какие-либо другие изменения на сайте?
https://www.programmersforum.rocks
Никаких изменений в домене или чего-либо подобного, сайт работает нормально.
На самом деле логи показывают, что это началось ещё в ноябре прошлого года, но изменений так и не было.
Хорошо, значит, сертификат в полном порядке.
Расскажите подробнее о почтовом сервере, который подключается к вашему форуму. Это обычный контейнер Docker для получения почты?
Я проверил его на //email/testTo:; если вы хотите проверить сами, это способ тестирования.
Как предполагает Ричард, проблема, похоже, не в Discourse, а в почтовом получателе.
Если это началось в прошлом ноябре, то это почти наверняка истечение срока действия корневого сертификата Let’s Encrypt. Вам, скорее всего, достаточно просто обновить образ и пересобрать.
Нет, я думаю, что проблема между получателем письма и Discourse.
Discourse доступен публично, поэтому я мог проверить сертификат Discourse и убедиться, что он в порядке.
Поэтому я подозреваю, что проблема на стороне получателя письма.
Это звучит как вполне вероятная причина!
Согласен, но объяснение Саймона может прояснить проблему с тем, что подключается к получателю почты.
РЕДАКТИРОВАНИЕ: Возможно, проблема возникла в прошлом ноябре, но была замечена только недавно.
…
Алекс уточнил в одном из своих ответов, когда это началось:
Ага, да, обновление исправило ошибку SSL.
Но после этого возвращался ответ 404. Создание нового ключа API решило проблему.