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.
2 Likes
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 Like
Cause of error
1 Like
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 Like
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 Likes
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 Likes
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 - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/
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 Likes
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.
2 Likes
2 posts were merged into an existing topic: Mail-receiver relay access denied
I wanted to add something for the Troubleshooting section.
Mail-Receiver (direct delivery) was working for several domains but not receiving messages from Gmail users. I couldn’t work out why. There was nothing in the logs except a connect/disconnect from Google. Everything looked good and the online tools confirmed DNS was fine.
Eventually I created an SMTP TLS report record in DNS e.g.
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
A few hours later, Google (Gmail) sent a report showing that it had cached an mta-sts policy that did not reflect current MX records. I was concerned that Google was going to hang on to that cached policy for a week because it seemed to have ignored my updated _mta-sts DNS record that should have caused a refresh.
And shortly after that, all my backed-up Gmail began to flow in to Discourse without me doing anything at all. The report helped me understand Google’s perspective on the problem and saved me from scratching my head when messages did begin to flow.
SMTP TLS reports are issued infrequently, so be patient.
2 Likes
Given that the guide says nothing about configuring MTA STS, wouldn’t adding diagnostic steps for that just confuse the 99.999%+ of users who don’t configure it?
2 Likes
In my case, the addition of a single DNS record was enough to shine the light on my problem. Given that the guide already instructs the creation of DNS records for the installation of Mail-Receiver, suggesting an addition record in the Troubleshooting section as a last resort doesn’t seem like a stretch. However, I see that your post has two ‘likes’ and mine has none, so that might be the end of it.
1 Like
That is good news, this seems like good info to add to guide especially since Gmail is a common sender.
The guide instructs on the creation of DNS records to make mail-receiver work, not to configure MTA STS. So a user following the guide will never have the problem you had. Hence there’s no need to complicate the guide with additional, unnecessary steps.
1 Like
In general is the mail-receiver able to process gmail sent mail to new topics?
This seems like a major problem, but not if the cause of this is an isolated incident.
I’ve come to the conclusion that Matt is right. My installation specifically had to cope with MTA-STS because its domain’s regular mail is handled by Mail In a Box https://mailinabox.email/ which insists on a strict MTA-STS policy and Gmail enforces that policy. By default, the policy could conflict with configuration for Mail-Receiver. Most domains will not have a policy. If a domain does have a policy it will be visible at
https://mydomain.com/.well-known/mta-sts.txt
My working policy looks like this…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
I am hoping to upgrade "mode: none" to “mode: enforce” after a little more work.
2 Likes
Could someone please remind me – when we rebuild Discourse at the command line, does it automatically rebuild the mail-receiver container, or do we need to do that separately? Thanks.
It does not; it rebuilds just when you tell it to. You don’t need to rebuild the mail receiver often.
2 Likes
It definitely helped me:)