Как это сделать, чтобы создать новое определение контейнера в этой директории!?
Запустив команды, показанные сразу после этого текста. Строго говоря, вы создаете файл не в этой директории, а в поддиректории containers, так же как и app.yml.
3 лайка
Спасибо, сначала они, казалось, не работали, но теперь я добрался до текстового редактора с помощью:
Похоже, есть проблема с этим: при запуске
./launcher logs mail-receiver
сообщается discourse_base_url=https://discourse.example.com, а не указанный домен, установленный в текстовом редакторе.
Попытался пересобрать/перезапустить загрузочный образ mail-receiver, но домен так и не изменился на правильный.
1 лайк
У меня возникла небольшая проблема, мне нужен совет!
root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.
starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver
затем…
root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 4400 root 13u IPv4 24419 0t0 TCP *:smtp (LISTEN)
master 4400 root 14u IPv6 24420 0t0 TCP *:smtp (LISTEN)
Я также пробовал…
root@JEN /var/discourse # netstat -nlp | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 4400/master
tcp6 0 0 :::25 :::* LISTEN 4400/master
и…
root@JEN /var/discourse # ps j 4400
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 4400 4400 4400 ? -1 Ss 0 0:02 /usr/lib/postfix/sbin/master -w
В интернете я нашёл инструкции остановить контейнер и убить процесс (процесс 4400?).
Безопасно ли это, и исправит ли это проблему?
Нужно ли мне (или стоит ли, или не стоит) изменить порт 25 на другой в файле mail-receiver.yml?
1 лайк
Возможно, вы установили postfix и вам нужно его удалить?
Вы не можете изменить порт. Вам нужно остановить процесс, который его использует. Просто убив его, не поможет, потому что после перезагрузки начнется гонка, чтобы увидеть, какой процесс запустится первым.
3 лайка
Я тоже так подумал. Не могу представить, как это туда попало, но я попробую удалить. В противном случае я могу просто использовать Gmail, который, кажется, работает отлично.
2 лайка
Я только что перенёс свой форум в новую среду и, как следствие, переустановил mail-receiver. Похоже, это более новая версия, чем та, что была у меня ранее. Конфигурационный файл YML немного изменился: DISCOURSE_BASE_URL заменил DISCOURSE_MAIL_ENDPOINT. Содержимое файла YML отражает это изменение, но инструкции в начале этой ветки требуют обновления.
Кроме того, при получении отклонённого или возвращённого письма я получаю следующие ошибки…
Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Валидные сообщения, похоже, обрабатываются корректно. Предыдущая версия mail-receiver не выдавала этих ошибок, насколько я мог судить по последним файлам логов. Я провёл небольшое исследование и наткнулся на эту статью: https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/
Добавление следующего в файл mail-receiver.yml, похоже, решило проблему для меня:
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
4 лайка
Опубликовал этот пост, чтобы сообщить, что мы добавили поддержку DMARC в mail-receiver через образ discourse/mail-receiver:with-dmarc. Для получения дополнительных сведений обратитесь к первоначальному сообщению по ссылке Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver.
3 лайка
2 сообщения были объединены с существующей темой: Отказ в доступе к ретранслятору почтового получателя
Я хотел добавить что-то в раздел «Устранение неполадок».
Почтовый получатель (прямая доставка) работал для нескольких доменов, но не принимал сообщения от пользователей Gmail. Я не мог понять почему. В логах не было ничего, кроме соединения/разрыва соединения с Google. Всё выглядело хорошо, и онлайн-инструменты подтвердили, что DNS настроен правильно.
В конце концов я создал в DNS запись SMTP TLS-отчёта, например:
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
Через несколько часов Google (Gmail) прислал отчёт, в котором указывалось, что у него закэширована политика mta-sts, не отражающая текущие MX-записи. Я беспокоился, что Google будет хранить этот закэшированный политику в течение недели, поскольку, казалось, он игнорирует моё обновлённую DNS-запись _mta-sts, которая должна была вызвать обновление.
И вскоре после этого все мои резервные копии писем из Gmail начали поступать в Discourse без каких-либо моих действий. Отчёт помог мне понять точку зрения Google на проблему и избавил от необходимости гадать, когда сообщения наконец начнут поступать.
Отчёты SMTP TLS выдаются редко, поэтому наберитесь терпения.
3 лайка
Учитывая, что в руководстве ничего не сказано о настройке MTA STS, не добавит ли включение диагностических шагов для этого путаницу 99,999%+ пользователей, которые не настраивают его?
2 лайка
В моём случае добавление одной записи DNS хватило, чтобы пролить свет на проблему. Поскольку руководство уже предписывает создание записей DNS для установки Mail-Receiver, предложение добавить ещё одну запись в разделе «Устранение неполадок» в качестве последнего средства не кажется натяжкой. Однако я вижу, что у вашего поста два «лайка», а у моего — ни одного, так что, возможно, на этом всё.
1 лайк
Это хорошие новости. Это, безусловно, стоит добавить в руководство, особенно учитывая, что Gmail — распространённый отправитель.
Руководство описывает создание DNS-записей для обеспечения работы mail-receiver, а не для настройки MTA STS. Поэтому пользователь, следуя руководству, никогда не столкнётся с проблемой, с которой столкнулись вы. Следовательно, нет необходимости усложнять руководство дополнительными и ненужными шагами.
1 лайк
В целом, способен ли mail-receiver обрабатывать письма от Gmail для создания новых тем?
Это кажется серьёзной проблемой, но не в том случае, если причина этого — изолированный инцидент.
Я пришёл к выводу, что Мэтт прав. В моём случае установка должна была учитывать MTA-STS, так как обычная почта для домена обрабатывается сервисом Mail In a Box https://mailinabox.email/, который требует строгой политики MTA-STS, и Gmail принудительно применяет эту политику. По умолчанию такая политика может конфликтовать с конфигурацией для получателя почты. У большинства доменов такой политики нет. Если у домена есть политика, её можно увидеть по адресу:
https://mydomain.com/.well-known/mta-sts.txt
Моя рабочая политика выглядит так…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
Я надеюсь после небольшой доработки обновить параметр “mode: none” до “mode: enforce”.
2 лайка
Не могли бы вы напомнить мне — когда мы пересобираем Discourse через командную строку, контейнер mail-receiver пересобирается автоматически, или это нужно делать отдельно? Спасибо.
Нет, перестраивает только тогда, когда вы ему скажете. Перестраивать почтовый получатель часто не нужно.
2 лайка
Мне это точно помогло 
1 лайк