Yunohost no longer able to receive emails?

Support
,
1

My YunoHost server

Hardware: Digital ocean droplet
YunoHost version: 11.2.11.2
I have access to my server : Through SSH and through web admin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

After a couple years of receiving emails through yunohost with no problem, my yunohost has stopped being able to receive emails.

When I send an email to my address, I get a bounce email with the following information:

<max@mydomain.com>: host mydomain.com[147.182.177.135] said: 554 5.7.1 Service
    unavailable; Client host [185.70.43.19] blocked using cbl.abuseat.org;
    Error: open resolver;
    https://check.spamhaus.org/returnc/pub/147.182.176.17/ (in reply to RCPT TO
    command)

----------------------------------------------
message/delivery-status
----------------------------------------------
Reporting-MTA: dns; mail-4319.protonmail.ch
X-Postfix-Queue-ID: 4VL5yG12jHz4wwdL
X-Postfix-Sender: rfc822; senderaddress@protonmail.com
Arrival-Date: Thu, 18 Apr 2024 18:33:42 +0000 (UTC)

Final-Recipient: rfc822; max@mydomain.com
Original-Recipient: rfc822;max@mydomain.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mydomain.com
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host
    [185.70.43.19] blocked using cbl.abuseat.org; Error: open resolver;
    https://check.spamhaus.org/returnc/pub/147.182.176.17/

----------------------------------------------

This link contains more info about the error https://check.spamhaus.org/returnc/pub/147.182.176.17/, and it says it is an issue with the configuration of the recipient.

I recently installed the Ghost application onto my server, but that’s the only change I’ve made that I can think of that could have caused the issue.

I started to look into it and saw via systemctl status dnsmasq that dnsmasq service was not running, and wondered if this was related.

There was a different process called dnsmasq running (but I guess not hte systemctl, which failed to start by saying "port 53 was already in use).

I tried killing the running dnsmasq process, and restarting the systemctl one – this worked – but still could not receive emails.

I’m just trying things though – I don’t really know what dnsmasq is or how it relates to receiving emails or what the issue could be.

Any help appreciated! I will keep looking too…

2

maybe relevant. this is what the contents of /etc/resolv.conf look like:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 67.207.67.2
nameserver 67.207.67.3
nameserver 127.0.0.1

based on the suggestion of @tituspijean here I tried commenting out the the top two nameserver lines and just keeping nameserver 127.0.0.1 but it quickly gets rewritten.

Similar to op, when I run

sudo chattr -i /etc/resolv.conf

I get the

sudo chattr -i /etc/resolv.conf
chattr: Operation not supported while reading flags on /etc/resolv.conf
3

I would still suggest to try disabling cloudinit before playing with chattr.

If you decide to keep that route, per symbolic link - Why is chattr and lsattr resulting in "Operation not supported while reading flags"? - Super User, is /etc/resolv.conf a symlink?
If so, let’s maybe try sudo rm /etc/resolv.conf then sudo nano /etc/resolv.conf and only put in there the nameserver 127.0.0.1 line. Save and restart dnsmasq.

4

hi @tituspijean , thank you! you were correct, it was a symlink. when I deleted the file and re-created it, now it is staying the same with just

nameserver 127.0.0.1

however, I am still seeing the same bouncing e-mails. does it take some time for the change to propagate?

I’m also trying disabling cloud-init now, via:
touch /etc/cloud/cloud-init.disabled

and then rebooting the server

5

sending emails via an stmp relay (which also worked for a couple years before this) is also now no longer working :confused: from yunohost perspective email is sent, but it never arrives :confused:

6

Hello,

Looks like you are using a DNS resolver shared across multiple customers at Digital Ocean.

The solution from spamhaus is to apply for a personal identifier, as explained here:

There is also a special footnote for Digital Ocean customers.

7

interesting, thanks @fritz2cat . indeed I am using digital ocean as the DNS nameserver for mfowler.info (which I understand to mean digital ocean is the DNS resolver). I wonder why for two years it was not an issue, and now it is an issue…

this also makes me consider to try simply changing what I use as the DNS nameserver for mfowler.info to something else other than digital ocean

1 Like
8

If you use a public resolver (i.e. serving hundreds or thousands VPS or dedicated servers), this resolver will certainly hit the upper limit of “fair use” for a private usage.

Hence the requirement to be authenticated.

9

thanks for the explanation @fritz2cat

I was able to resolve the issue by simply moving my dns records away from digital ocean and instead using a private bind server as my dns resolver for the domain. all fixed now :slight_smile:

strangely, while looking into this I also found that dnsmasq was not running properly on my server. there was a different dnsmasq process that was running as part of the lxc-net package (which I don’t remember installing).

so I ran systemctl mask lxc-net and that fixed that problem, and now the correct dnsmasq is running.

strangely, I don’t understand how my email was working the past two years with both of these issues, and why it stopped working all of a sudden now. I guess installing ghost was not the real problem and just a red herring.

Anyway all is working now! Thank you both for the debugging help.

1 Like