-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rspamd symbol HFILTER_HOSTNAME_UNKNOWN #3168
Comments
We removed the PTR check from Postfix and moved it to Rspamd. |
It is a bit strange you see I think your unbound container is not working correctly. It should not have been flagged. Anything in your unbound logs? Can you increase verbosity? I recommend you decrease the symbol score on your system to something lower OR reimplement the ptr check to Postfix while also monitoring unbound. Verbosity unbound-mailcow:
|
I noticed when performing a I’ll increase the log verbosity and continue to monitor for now. It’s not every single mail that gets caught but a significant amount seems to be. |
If you use nslookup inside unbound, you need to query 127.0.0.1. With dig it is Is it happening when the host is busy? You should reduce the symbols score in Rspamd UI while testing. I think you only now found out about this issue, because mails pop up in your quaratine and Rspamd log. They were probably rejected before, but you only now noticed. |
Also that could be the case but it seems unlikely, nobody ever reached out to suggest that mail hadn't been responded to. |
Use dig in acme-mailcow and dig against @Unbound |
I'm just simulating some mail in to see if I can find a failure with the verbosity increased on Unbound now. What's the best place to debug this, I'm around on IRC if that helps. |
I don't think that's a general issue. Join the Telegram group and post some logs. But I won't do anything today anymore. :) I might be around tomorrow evening. |
Upon further investigation it looks like it's the very first mail that's received from mailcow after a reboot or restarting the full stack. The first lookup takes a little longer as it resolves each NS/TLD chain. Can we perhaps force a lookup upon startup for Unbound? |
We can do that. :) |
So for anybody that is experiencing similar issues, I had mailcow configured as per default with ipv6 enabled despite not having an ipv6 enabled network. That was causing issues with Unbound, specifically PTR lookups were taking much longer than they should and would often result in hosts with a valid PTR coming up as unknown and being marked with the I've submitted a PR for the docs mailcow/mailcow-dockerized-docs#182 which recommends disabling IPv6 if your network is not capable, this has prevented the issue in my scenario. |
Perhaps we can make the fallback to IPv4 happen faster? Is there such a config option in unbound? |
I couldn't find such a config, the only way I was able to prevent it from occurring without disabling IPv6 on the whole stack was to disable IPv6 for Unbound specifically
|
@andryyy while not a big deal, it's probably still worthwhile changing the value above, whether that's done based on the watchdog check or by specifying in the documentation I'll let you decide. The reason being, if you only disable ipv6 in the mailcow network Unbound will still be making attempts to ipv6 upstream and will silently error and fail, disabling it in Unbound might actually make more sense to prevent this all together. |
I have a VPS server running MailCow with IPv6 networking working and i still have issues of HFILTER_HOSTNAME_UNKNOWN.... |
Why issues? It is a symbol, that triggers with missing/wrong PTR records. :) Have you validated, that your sender has a valid PTR? |
Yes, the log indicate an IPv4 address that match with the MX server of the sender... |
You can whitelist the sender in mailcow UI and inform the sender. :) |
That nearly what i did. |
You are welcome. :) |
Prior to placing the issue, please check following: (fill out each checkbox with a
X
once done)Description of the bug: What kind of issue have you exactly come across?
Regularly seeing the
HFILTER_HOSTNAME_UNKNOWN
rspamd symbol, since this has a very high rating almost all mail is rejected/quarantined.This issue appears to be similar to #2014 although there's no SMTP proxy in my case.
Here's the Postfix log for two cases of offending mail:
Reproduction of said bug: How exactly do you reproduce the bug?
I have tried or I do... (fill out each checkbox with a
X
if applicable)System information
Further information (where applicable):
docker version
)docker-compose version
)Further notes:
git diff origin/master
, any other changes to the code? If so, please post them.iptables -L -vn
,ip6tables -L -vn
,iptables -L -vn -t nat
andip6tables -L -vn -t nat
docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254
(set the IP accordingly, if you changed the internal mailcow network) anddocker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @1.1.1.1
- output? Timeout?Both return:
The text was updated successfully, but these errors were encountered: