mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-27 09:55:58 +03:00
[GH-ISSUE #921] DNSBL report incorrect #797
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#797
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dugite-code on GitHub (Sep 19, 2016).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/921
Originally assigned to: @tonioo on GitHub.
Just upgraded to 1.6.0 from 1.5.1
added new crontab entries then manually ran
/srv/modoboa/env/bin/python /srv/modoboa/instance/manage.py modo check_mxas vmail with no errors. All DNSBL show as listed, my manual checks (where possible) show no listings. using dnsbl.info only dnsbl-3.uceprotect.net shows listed due to my server being a digital ocean droplet (minor issue).I am unsure how to debug this issue. I have set debugging to True in settings.py is there a log file I can check?
@tonioo commented on GitHub (Sep 19, 2016):
Could you paste some screenshots please ?
@dugite-code commented on GitHub (Sep 22, 2016):
Is this what you're after? It's every DNSBL provider from the
constants.pyfile.PS: I just did a fresh install on a new droplet (broke stuff with my tinkering) issue is pressent with a brand new install.
@tonioo commented on GitHub (Sep 30, 2016):
Have you checked that the MX record found by Modoboa is the right one ?
@dugite-code commented on GitHub (Oct 3, 2016):
MX record is correct with correct IP address. I also have reverse DNS lookup working.
@hennedo commented on GitHub (Oct 3, 2016):
I can confirm this behaviour on a fresh installation of Ubuntu 16.04 without ufw.
@tonioo commented on GitHub (Oct 4, 2016):
Guys, would be easier to debug if one of you could give me a domain name that fails. Do not hesitate to send me a private message.
@hennedo commented on GitHub (Oct 4, 2016):
Try smells.sexy :)
@tonioo commented on GitHub (Oct 4, 2016):
Thank you. I'm sorry but I fail to reproduce your issue... I see your domain as not blacklisted. Where is your server ? Is there any DNS limitation or something similar which could cause this ?
@hennedo commented on GitHub (Oct 4, 2016):
Not that i'm aware of it..
When I manually try to query the ip, it shows the following
Which is fine, if i'm not mistaking... I will have a look at the code tonight..
@tonioo commented on GitHub (Oct 5, 2016):
Yes, it is fine. Which user runs the management command ?
@tonioo commented on GitHub (Oct 5, 2016):
@dugite-code Have you tried to run the command as root ?
@hennedo commented on GitHub (Oct 5, 2016):
Found the error!
I had set a DNS Search Domain in my /etc/resolv.conf.
socket.gethostbyname always returned the IP address of my Webserver. The Searchdomain also is the hostname of my Webserver, so it seems, when socket.gethostbyname cannot resolve the Hostname, it takes the IP of the searchdomain.
Removing the Searchdomain fixed this.
(and the script crashes if no MX is present now... mhh did I break something? :D the try..catch, doesn't seem to catch the "dns.resolver.NXDOMAIN" error, which is raised if no MX is present...)
^- forget that, this seems to be already fixed in the current git master...
@dugite-code commented on GitHub (Oct 6, 2016):
@tonioo just gave it a shot running as root with no change * Edit just sent you my domain details via email
I also got the same result using dig
@henne- Unfortunately I don't have a dns search domain defined.
@awein commented on GitHub (Oct 9, 2016):
This issue is caused by a missing domain entry in the
resolv.conffile. An empty value might still cause issues in case your hostname is a subdomain (like mail.example.com).@tonioo I suggest to append a
.at the end of the hostname (which will force the name to be the full DNS name instead of a relative one)(e.g.
bl.spamcop.net.instead ofbl.spamcop.net)The workaround until then is to add the following line to the
/etc/resolv.conf:@dugite-code commented on GitHub (Oct 10, 2016):
I can confirm adding
domain .to my/etc/resolv.conffixed this issue for me. Thanks @awein*edit: yes my domain was a subdomain like mail.mydomain.com
@dugite-code commented on GitHub (Oct 10, 2016):
Incidentally dnsbl.njabl.org show's listed but according to dnsbl.info and vamsoft.com njabl.org has been shutdown and should probably be removed.
@ghost commented on GitHub (Oct 10, 2016):
Are you guys using some public DNS resolver? Because many DNSBL services are known to block or limit the queries from such resolvers.
I use my own DNS resolver (Unbound), so I only have
nameserver 127.0.0.1in resolv.conf file. And everything is fine here with many domains.Just my 2 cents.
@dugite-code commented on GitHub (Oct 10, 2016):
@csmk that's interesting to know. I'm using the google name servers because I honestly didn't think of changing the default settings.
My Digital Ocean droplet built using their
Ubuntu 16.04.1 x64image/etc/resolv.conf@tonioo commented on GitHub (Oct 10, 2016):
@awein Thank you! I'll update the code.
@gabsoftware commented on GitHub (Mar 29, 2022):
That was it! zen.spamhaus.org refused DNS queries with public DNS resolvers, even the ECS enabled 9.9.9.11... Which should have worked according to their usage terms https://www.spamhaus.org/organization/dnsblusage/ .