Add reject_unknown_client_hostname to main.cf#2691
Add reject_unknown_client_hostname to main.cf#2691polarathene merged 4 commits intodocker-mailserver:masterfrom GoliathLabs:patch-1
reject_unknown_client_hostname to main.cf#2691Conversation
|
Not sure whether change in the docs is needed |
It could be worth documenting that, but until an issue is raised regarding it, I'm fine avoiding docs for now as I'd like to know if this change does cause problems for users. This change is for the more strict version than With I suspect that can be a common misconfiguration by our users based on past issues. For those using I realize this is about filtering out inbound mail, nothing related to outbound mail, but I was thinking of scenarios with tests or when one DMS instance sends to another. Ideally any legitimate mail server is going to be configured correctly, and pass those additional conditions, so hopefully when users update, they're not going to find legitimate mail being rejected that is received from third-parties. |
|
I also think this is a worthwhile addition and a right one :) |
|
@georglauterbach @polarathene one thing I noticed yesterday is that sending mail from another container on the same host will fail: dani-garcia/vaultwarden#2647 |
|
Normally you would want to have a separate host for your mails, but in some cases that is not the case. So we need to solve this somehow by allowing mails from the internal Docker networks. I tried both |
|
I figured you might get something like that happening 😅 You can play around with a fully offline setup with local DNS as I demonstrate here. Your change shouldn't cause new rejections if the client passes either permits: Is your client sending on port 25 instead of 587/465? If so you'd need to sort out the network, which you can debug in this method to ensure both containers have the same network/interface to connect to each other and that the IP falls within the subnet. |
casperklein
left a comment
There was a problem hiding this comment.
LGTM, however this should be fixed:
|
I am sending over 587 and STARTTLS. When I change the permit_network to connected-networks or network, it still doesn't work. Interestingly, 172.25.0.1 is the gateway IP of the mailserver_default network, which normally shouldn't be a problem since we included it with either network or connected-works. Nevertheless, it doesn't seem to work. The main.cf with connected-networks: |
|
Have you tried following my advice for a local multi-instance setup with the local DNS config it shows? It may still fail though as the Corefile there doesn't configure rDNS 🤔 I am unable to help investigate any time soon, but I did link to full offline setup you can adapt. I know it's not quite enough to copy/paste and test, but at least would provide a more common config to reproduce from, since you haven't really shared much information of your own for reproduction. If the hostname is really an issue look in |
|
My findings so far and my mail server setup. And thank you @polarathene for taking the time to help me. Sadtly I don't have time to create a replica of my mail server at home right now. But I did find out some interesting things below which may help to debug this problem? (hopefully) mailserver.env Now the interesting part, reverse DNS seems to be working just fine. Yet I have to add my docker networks IP to the /etc/hosts file to finally be able to send via an internal IP Now everthing get's through. |
|
Your DMS container is only aware of the |
|
@polarathene But Any recommendations for modifying my docker-compose file? Thanks in advance 😄 |
|
I just gave it a try and added DetailsRelevant Real spam seems to be rejected: |
I could be wrong, it's been a while since I've messed around with Docker networks. You're probably right about You've got a lot more going on in your setup, I would simplify it down to bare minimal for using DMS. Create a separate
What was the before state of This doesn't seem right.. Doesn't that say The containers should be authorized to bypass the restriction instead.
Here only Note that you only want to permit IPs from your containers that should be allowed to send mail without auth, I assume Likewise, be careful of proxies that don't carry over the original client info like IP/host, you don't want your container working around a restriction (although I don't think it matters with this rule, which checks client hostname based on mail headers?). There was one user who had an issue with RoundCube getting banned by Fail2Ban because all users were seen as from the same IP (the RoundCube container) when authenticating I think. Ideally your containers would use SASL auth (587 or 465 port with user + password), not port 25 without auth. If that's acceptable, then |
|
I'll try to do the debugging today |
|
Update from my setup: Lots of rejected SPAM Mails with 0 false positives so far 👍 |
|
I think I got it. My temporary |
|
I'll merge. My current commitments are delaying time to spare for this project, so the feature PR I've been working on and holding up the next release with may arrive later this month. If you'd like to release 11.2 before then, I'm ok with that. I'll prepare a release sometime this week as time permits 👍 |
|
Thanks @GoliathLabs for taking the time to look into this and contribute a PR! ❤️ |
|
hello there, first off, thanks for this wonderful project. after upgrading from v11.1.0 to v11.2.0 I have found myself unable to receive from google (which I previously have been able to), as represented by the following (irrelevant parts redacted): I am aware it has been posted here earlier that communication with gmail worked for some users (so it did for me, before this change, apparently). is there any quick way to remedy this? |
|
@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf Seems like you are behind a NAT? Because the 192.168.224.1 IP address comes from a private address space and is not the public facing IP of Google's infrastructure |
hey! thanks for a quick reply. perhaps a "docker" kind of NAT? the mailserver is configured with proper public IPs, that's how I was able to receive email before, not sure I follow. I am aware the address comes from the private space, although there didn't appear to be any issues with it before. could I provide anything specific to help debug this? btw I said to myself yolo and for the moment rolled back to the previous version (11.1.0), which immediately allowed me to receive mail from google again, even got some previously rejected messages finally delivered on retry. |
|
That is correct. With this version we check if there is a valid hostname behind the IP. In the previous release, these checks were not executed. Can you provide your mailserver env file and your docker compose file? (omit sensitive values) |
sure:
compose file: |
|
Does your host have IPv6 connectivity? That might explain the NAT: https://docker-mailserver.github.io/docker-mailserver/edge/config/advanced/ipv6/ |
the host does indeed have IPv6 connectivity. I will try to edit my compose file to have IPv6 work all the way through to the mailserver container, update again, test receiving from G and then report back (hopefully, all will be working then). thanks for the pointer @casperklein EDIT: didn't work, still got: may or may not be due to the fact that the host is not in fact using |
|
@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf can you post the log of the ipv6nat container on startup? |
sure, it's restarting (" a more complete version (after compose restart) - it actually segfaults first: |
|
@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf Can you try this: |
thanks, tried it just now. sadly, the result appears to be the same: this is the setup without the I said earlier I was using One last thing that came to mind is I am running the compose setup using EDIT: alright the issue is definitely not the issue is that |
|
would one of the solutions be disable ipv6 in postfix? I am willing to sacrifice ipv6 if that allows for a simpler way forward. |
|
No docker-mailserver/mailserver.env Lines 269 to 283 in b60b401 |
thanks, that's great. one last question, though. I feel it would be best if the mail domain was solely used for sending email and not anything else, but I wanted an |
I can imagine, that google will try IPv6 first and if connections cannot be established, it falls back to IPv4. But that's not guaranteed and up to google how they configured their mailserver. You can use E.g. you can additional configure address@some-complete-different-domain, and point that domains MX record also to And for |
thanks @casperklein, that's what I ended up doing in the end. also removed AAAA record for the mail domain and set postfix+dovecot to only work in ipv4 mode. it took a while for the new dmarc records to propagate but now it all works fine, I was even able to upgrade to the new version (11.2.0). |
|
@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf keep in mind that IPv6 is becoming increasingly dominant across the web. It might be a good idea to look into supporting IPv6 (-only) servers in the future as well. |
fair point, that's right, but until I find a way to run ipv6+nftables+docker that will most likely be a docker-less setup... |
|
There might be issues regarding this PR: #2970 |
|
@casperklein can't replicate the issue on my side |
|
Same here, I am just wondering because there are at least two people with same/similar issues. IPv6 may be a factor. |
But I think it depends on the network setup, as I also use IPv6, but in combination with an IPv6NAT container. |
Description
As discussed in the below mentioned issue this adds the
reject_unknown_client_hostnameoption.Reference: http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
Fixes #2650
Type of change
Checklist:
docs/)