Closed hydazz closed 1 year ago
however I searched the spamhaus database with the IPs and none of them are listed.
I noticed in the past, that some IP addresses are only listed for a very short time.
changing ENABLE_DNSBL to 0 has no affect
That's the way to go. Did you restart the container afterwards (docker-compose down/up
)?
You can also set LOG_LEVEL=debug
to get more output on start and verify, if ENABLE_DNSBL
is enabled or not.
I noticed in the past, that some IP addresses are only listed for a very short time.
i thought that this was the case, however I checked the blacklist right after the email was rejected, and it said there were no issues
Did you restart the container afterwards (docker-compose down/up)?
I use unraid, which recreates the container when you update the template, note that the logs above were generated with 'ENABLE_DNSBL=0' - and the container had definitely been recreated.
I have deleted the mail-state folder and disabled it to see if it fixes the issue. I will have to monitor the logs to see if emails are still being rejected. i don't see any reason that changing the value of ENABLE_DNSBL
requires recreating the mail-state folder
I also sorta want to use DNSBL...
i don't see any reason that changing the value of ENABLE_DNSBL requires recreating the mail-state folder
Why do you think, that deleting the mail-state folder is required?
What does grep DNS /etc/dms-settings
return inside the container?
changing
ENABLE_DNSBL
to0
has no affect
According to tests, that should prevent such a block from zen.spamhaus.org
as it would no longer be included in Postfix main.cf
settings smtpd_recipient_restrictions
, postscreen_dnsbl_action
, postscreen_dnsbl_sites
:
And you can see that the ENV is configured to apply those changes (and is disabled by default):
note that the logs above were generated with 'ENABLE_DNSBL=0' - and the container had definitely been recreated.
That seems unlikely given the above?
Next time you encounter this issue, docker exec -it <dms container name> <command>
(or whatever unraid supports to access a shell in the container). Where <command>
is the grep suggestion from @casperklein and other commands check the mentioned Postfix settings postconf <setting>
.
For reference feature was originally added via this PR (Dec 2021, Released in v10.5.0
March 2022).
(everything used to work but something changed, when? I don't know)
What version are you running? Did you update roughly around when the issue started happening?
thanks for the suggestions, @polarathene
changing ENABLE_DNSBL to 0 has no affect
after investigating with grep DNS /etc/dms-settings
changes only apply when the container is recreated, not restarted. when I opened mailserver.env
ENABLE_DNSBL
was set to 0
and as the last time I modified the file was a while ago, I assumed that the container would have been recreated by then (I tinker with docker a lot).
For reference feature was originally added via https://github.com/docker-mailserver/docker-mailserver/pull/2342 (Dec 2021, Released in v10.5.0 March 2022).
When this feature was introduced I enabled it and had no delivery problems (that were bought to my attention by clients trying to email me). I've been running v11.1.0 since it was released and don't believe its causing this issue. (this container has no control over spamhaus, which is the culprit here).
One of our clients have said that when they try send attachments they receive the following:
The following message to <signs@domain.com.au> was undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 554-'5.7.1 Service unavailable: Client host [139.138.45.76] blocked using zen.spamhaus.org'
Sending attachments is definitely unrelated to the spamhaus IP blocklist, however they have stated that this has been the case for a week or so. we receive some emails, and some get blocked by spamhaus.
Just now, as I was writing this, I had been monitoring the logs and another email had been rejected by spamhaus (I had re-enabled it)
Jul 30 12:24:46 mail postfix/postscreen[5042]: CONNECT from [104.223.127.45]:45844 to [192.168.1.2]:25
Jul 30 12:24:46 mail postfix/dnsblog[5046]: addr 104.223.127.45 listed by domain zen.spamhaus.org as 127.255.255.254
Jul 30 12:24:46 mail postfix/dnsblog[5045]: addr 104.223.127.45 listed by domain list.dnswl.org as 127.0.0.255
... (imap client logs in)
Jul 30 12:24:52 mail postfix/postscreen[5042]: DNSBL rank 3 for [104.223.127.45]:45844
Jul 30 12:24:52 mail postfix/tlsproxy[5069]: CONNECT from [104.223.127.45]:45844
Jul 30 12:24:53 mail postfix/tlsproxy[5069]: Anonymous TLS connection established from [104.223.127.45]:45844: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jul 30 12:24:53 mail postfix/postscreen[5042]: NOQUEUE: reject: RCPT from [104.223.127.45]:45844: 550 5.7.1 Service unavailable; client [104.223.127.45] blocked using zen.spamhaus.org; from=<karlie@seowebmasternet.co>, to=<info@domain.com.au>, proto=ESMTP, helo=<reptile.seowebmasternet.co>
Jul 30 12:24:54 mail postfix/postscreen[5042]: DISCONNECT [104.223.127.45]:45844
and literally, the second the email was rejected I checked the IP here and it said 104.223.127.45 has no issues
. Now this is a spam email, and info@domain.com.au
is not an actual user that exists. but that is not the reason it was rejected.
so I'm lost... I receive 50+ spam emails per day and the easy way, of just disabling it is not optimal for me. i also want to track down the issue present
Just now, as I was writing this, I had been monitoring the logs and another email had been rejected by spamhaus (I had re-enabled it)
Perhaps you should focus on what few emails are not being blocked? Do those which are not blocked qualify for being checked against the DNSBL? Otherwise it sounds like anything that is checked is being blocked. Perhaps the request is failing somewhere along the way and to be safe choosing to reject?
I receive 50+ spam emails per day and the easy way, of just disabling it is not optimal for me.
There's an active PR wanting to add a new restriction, the author stated it was helpful for reducing spam. Might be worth seeing how well that works for you?
In the PR comment that I linked, I reference the check_client_access
restriction which is an allowlist that could be used to bypass the DNSBL if you have certain client details where that's acceptable? (example shown here)
check_client_access
could likewise be used with ENABLE_DNSBL=1
if the majority of spam received would not match your any of the allowed clients.
I have the latest docker-container and I use "ENABLE_DNSBL=0" but it just keepa running after recreating the docker
I dsiabled the service manually temporary using the config inside the container..
I have the latest docker-container and I use "ENABLE_DNSBL=0" but it just keepa running after recreating the docker
How did you ensure, the container was really recreated? I bet it was not.
Instead of "recreating" it, you might try to completely destroy and create the container.
yes, I am sure:
docker-compose up -d --force-recreate
And grep DNS /etc/dms-settings
confirms, ENABLE_DNSBL
is 0
+ Mails are still rejected due DNS BL entrys?
You could also confirm that inside the container echo $ENABLE_DNSBL
is reporting 0
(the /etc/dms-settings
line should confirm the same, but just in-case :sweat_smile: ).
We're not able to assist if your container is not correctly detecting the ENV change set to 0
from these two checks, that would mean something is wrong on your end. Your best bet would then be to follow my earlier advice as an alternative.
I have the same problem and ENABLE_DNSBL is set to 0
.
# echo $ENABLE_DNSBL
0
When I send mail to my server from both Hotmail and Yahoo accounts they always bounce with a message similar to, "Remote server returned message detected as spam - blocked using zen.spamhaus.org"
I have the same problem and ENABLE_DNSBL is set to
0
.
You need to confirm storage too:
Run these commands in the container:
postconf smtpd_recipient_restrictions
postconf postscreen_dnsbl_sites
grep ENABLE_DNSBL /etc/dms-settings
grep ENABLE_DNSBL /root/.bashrc
The first two should not have any mention of zen.spamhaus.org
, and the last two confirm that ENABLE_DNSBL
as 0 is processed correctly during startup scripts.
Output of postconf smtpd_recipient_restrictions
:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_recipient_domain, check_policy_service inet:localhost:65265, reject_rbl_client zen.spamhaus.org
Output of postconf postscreen_dnsbl_sites
:
postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.mailspike.net b.barracudacentral.org*2 bl.spameatingmonkey.net dnsbl.sorbs.net psbl.surriel.com list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].[2..3]*-4
Output of grep ENABLE_DNSBL /etc/dms-settings
:
grep: /etc/dms-settings: No such file or directory
No output of command grep ENABLE_DNSBL /root/.bashrc
.
The first two both mention zen.spamhaus.org
and I think the last two are confirming that ENABLE_DNSBL as 0 is not being processed correctly during startup scripts.
Sorry to have wasted your time as I wasn't using the latest version.
I pulled the latest image, recreated the container and can confirm that ENABLE_DNSBL
is working as expected.
Thanks.
Should be noted that with DNSBL enabled these emails should not be being blocked, they are not listed in the DNSBL
This issue has become stale because it has been open for 20 days without activity. This issue will be closed in 10 days automatically unless:
meta/stale
label or adds the stale-bot/ignore
labelThis issue was closed due to inactivity.
Subject
Mail being rejected by spamhaus
Description
Hi, I have quite a serious problem when receiving mail from clients, most mails are being rejected by the DNSBL, however I searched the spamhaus database with the IPs and none of them are listed. multiple clients from multiple other hosting provides are all having the mails being sent back. I really need to address this issue immediately as we can't have mails being bounced back changing
ENABLE_DNSBL
to0
has no affect (everything used to work but something changed, when? I don't know)if anyone could point me in the right direction to getting this fixed I would be eternally grateful!
When people try to send me mail they get this bounceback from their host:
and here are the corresponding logs to go along with the email they tried to send: