How is this done to create a new container definition in that directory!?
By running the commands shown immediately following that text. Strictly speaking you aren’t creating the file in that directory but inside the containers subdirectory, same as app.yml.
3개의 좋아요
Thanks, at first those didn’t seem to be working but now have gotten to the text editor with:
There seems to be a problem with this, when running
./launcher logs mail-receiver
reports discourse_base_url=https://discourse.example.com, instead of specified domain set in text editor.
Tried rebuilding/relaunching bootstrap of mail-receiver but hasn’t changed to correct domain.
1개의 좋아요
I’m having a little trouble I could use some advice!
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
then…
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)
I also tried…
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
and…
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
I’m finding instructions online to stop the container and kill the process (process 4400?)
Is this safe, and will it correct the problem?
Do I need to (or should I, or should I not) change port 25 to a different port in the mail-receiver.yml file?
1개의 좋아요
Maybe you installed postfix and need to remove it?
You can’t change the port. You need to stop whatever is using it. Just killing it won’t work because when your reboot it’ll be a race to see which process starts first.
3개의 좋아요
That’s what I was thinking too. I can’t imagine how it got on there, but I’ll try removing it. Otherwise I can just use gmail which seems to be working just fine.
2개의 좋아요
I’ve just moved my forum to a new environment and as a result re-installed the mail-receiver. It looks like it’s a newer version than I previously had installed. The YML config has changed a little with DISCOURSE_BASE_URL replacing DISCOURSE_MAIL_ENDPOINT. The YML file contents reflect the change but the instructions at the top of this thread need updating.
Also when receiving an email that is bounced/rejected I’m getting the following errors…
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
Valid messages seem to be handled correctly. The previous version of mail-receiver didn’t give these errors as far as I could see from recent log files. I did a little research and came across - smtp socket: malformed response on a FIPS 140-2 system
Adding the following to the mail-receiver.yml file seems to fix the problem for me:
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
4개의 좋아요
Dropping a post here to note that we’ve added DMARC support to the mail-receiver via an image discourse/mail-receiver:with-dmarc. Please refer to Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver in the OP for more details.
3개의 좋아요
2개의 게시물이 기존 주제 Mail-receiver relay access denied에 병합되었습니다.
문제 해결(Troubleshooting) 섹션에 추가할 내용을 하나 더 올리려고 합니다.
메일 수신기(직접 전달)는 여러 도메인에서 정상적으로 작동했지만, Gmail 사용자로부터 메시지를 받지 못했습니다. 그 이유를 알 수 없었습니다. 로그에는 구글과의 연결/연결 해제 기록만 있을 뿐, 다른 것은 아무것도 없었습니다. 모든 설정은 정상적으로 보였고, 온라인 도구를 통해 DNS도 문제없음을 확인했습니다.
결국 DNS에 SMTP TLS 리포트 레코드를 생성했습니다. 예를 들어 다음과 같습니다.
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
몇 시간 후, 구글(Gmail)에서 보고서를 보내왔습니다. 보고서에는 현재 MX 레코드를 반영하지 않는 mta-sts 정책을 캐시하고 있다는 내용이 담겨 있었습니다. 업데이트된 _mta-sts DNS 레코드가 새로고침을 유발해야 했는데도 구글이 이를 무시한 것으로 보아, 그 캐시된 정책을 일주일 동안 유지할까 봐 우려되었습니다.
그리고 얼마 지나지 않아, 제가 아무 조치도 취하지 않았는데 백업되어 있던 Gmail 메시지가 모두 Discourse로 흘러들어오기 시작했습니다. 이 보고서는 구글이 문제를 어떻게 보고 있는지 이해하는 데 도움이 되었고, 메시지가 실제로 도착하기 시작했을 때 머리를 쥐어짜며 고민할 필요를 줄여주었습니다.
SMTP TLS 리포트는 드물게 발급되므로, 인내심을 가져야 합니다.
3개의 좋아요
가이드에 MTA STS 구성에 대한 내용이 전혀 없는데, MTA STS를 구성하지 않는 99.999% 이상의 사용자를 혼란스럽게 할 수 있는 진단 단계를 추가하는 것은 어떨까요?
2개의 좋아요
제 경우, DNS 레코드를 하나만 추가하는 것으로도 문제를 파악하는 데 충분했습니다. 가이드에 이미 Mail-Receiver 설치 시 DNS 레코드 생성을 안내하고 있으므로, 문제 해결(Troubleshooting) 섹션에서 마지막 수단으로 추가 레코드 생성을 제안하는 것은 무리가 아니라고 생각합니다. 다만, 질문자님의 게시물에는 '좋아요’가 2개 있고 제 게시물에는 하나도 없어서, 이 정도로 마무리되는 것 같습니다.
1개의 좋아요
좋은 소식입니다. Gmail은 매우 일반적인 발신자이므로, 가이드에 이 정보를 추가하는 것이 특히 유용할 것 같습니다.
가이드는 MTA STS를 설정하기 위한 것이 아니라 mail-receiver가 작동하도록 하기 위해 DNS 레코드를 생성하는 방법을 안내합니다. 따라서 가이드를 따르는 사용자는 질문자님이 겪은 문제를 겪지 않게 됩니다. 따라서 불필요한 추가 단계로 가이드를 복잡하게 만들 필요가 없습니다.
1개의 좋아요
일반적으로 메일 수신기가 Gmail로 전송된 메일을 새 주제로 처리할 수 있나요?
이것은 심각한 문제처럼 보이지만, 그 원인이 고립된 사건이라면 그렇지 않을 수도 있습니다.
마트가 옳다는 결론에 도달했습니다. 제 설치 환경은 특히 MTA-STS를 처리해야 했는데, 해당 도메인의 일반 메일은 Mail In a Box https://mailinabox.email/ 이 처리하고 있기 때문입니다. 이 서비스는 엄격한 MTA-STS 정책을 고수하며, Gmail은 그 정책을 강제 적용합니다. 기본적으로 이 정책은 Mail-Receiver 설정과 충돌할 수 있습니다. 대부분의 도메인에는 정책이 없을 것입니다. 만약 도메인에 정책이 있다면 다음 경로에서 확인할 수 있습니다.
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를 재빌드할 때, 메일 리시버 컨테이너도 자동으로 재빌드되나요, 아니면 별도로 해야 하나요? 감사합니다.
그렇지 않습니다. 사용자가 지시할 때만 다시 빌드합니다. 메일 수신기를 자주 다시 빌드할 필요는 없습니다.
2개의 좋아요
저한테는 정말 도움이 됐어요 
1개의 좋아요