Updated iPv6 entry in docs and removed not working fix.#3061
Updated iPv6 entry in docs and removed not working fix.#3061AlperShal wants to merge 1 commit intodocker-mailserver:masterfrom AlperShal:master
Conversation
|
Documentation preview for this PR is ready! 🎉 Built with commit: effff50 |
|
|
||
| ## Background | ||
| ## Not Available | ||
| docker-mailserver doesn't currently support iPv6 networking! Trying to get mails using iPv6 will result with postfix not being able to find your hostname. |
There was a problem hiding this comment.
I don't think this is 100% correct. It is probably not even a DMS issue, but a Docker issue. I could try setting up a Kubernetes dual-stack cluster which supports IPv6 just fine and DMS should work in this setup too. @casperklein @polarathene do you think this really is accurate?
There was a problem hiding this comment.
It is probably not even a DMS issue, but a Docker issue.
@polarathene do you think this really is accurate?
The previous content was more accurate about the "why" and should remain really (the gateway IP varies IIRC, dependent on what the docker network got assigned).
The #2927 referenced issue is the one I was intending to respond to, but got side-tracked with all the test refactoring in jan 😅 I recently shared details on how to get IPv6 working properly, although I haven't applied it for DMS myself yet to verify that resolves the issue.
Probably better to update the docs with information from there as the IPv6 NAT support wasn't available when these docs were written IIRC.
There was a problem hiding this comment.
do you think this really is accurate?
Afaik, none of us is using IPv6. So we can't properly test/reproduce any errors that are reported. Given the amount of IPv6 related issue, I am not sure if we should advertise it to be functional. So a warning seems reasonable to me. The wording however is a bit harsh and might be adjusted.
| + gateway: fd00:0123:4567::1 | ||
| ``` | ||
| ## Fix | ||
| To fix the issue, basicly remove the AAAA record for your mailserver. This will prevent email senders from using iPv6. |
There was a problem hiding this comment.
To fix the issue, basicly remove the AAAA record for your mailserver.
Haha, I'm all for that ❤️ This is probably not something someone who needs to use IPv6 wants to hear though..
There was a problem hiding this comment.
I didn't want to hear this too but that was the only fix I was able to find. :)
polarathene
left a comment
polarathene
left a comment
There was a problem hiding this comment.
Background info seems relevant still. I'd rather not drop that. The alternative fix and additional issue to reference is good though 👍
It should be possible to configure your Docker host to support IPv6 NAT and I think that will resolve the issue experienced. If anyone can confirm that I am happy to revise the docs here with that approach.
If I hadn't started actively using my mail server I would definitely check it and validate but it's impossible for me to risk missing some mails right now. |
It might be possible, but the current documentation will fail to give that. So it should at least carry a big warning "this IPv6 NAT approach is only theoretically interesting as it is practically useless for mail reception". |
Docs state that IPv6 will connect, but mail will fail SPF check (which causes rejection, at least if not authenticated IIRC?):
Referenced issue #2927 shows: And another related issue (with another user already configured with IPv6 advice I gave) had that same error (but with an IP that wasn't a private address). It's possible that this PR which made it to the I've assigned myself to look into it. I'm currently focused on overhauling the test suite so that we can improve test coverage for issues like this, especially with DNS and more real-world style mail delivery. After that I'll try to reproduce and go from there. |
Correct.
That is only correct if you use the stock configuration. If you enable robbertkl/ipv6nat per instructions, you will get the the address of the IPv6 gateway.
I haven't experienced the issue with the rejected public address, only private (both IPv4 as you wrote and IPv6 with robbertkl/ipv6nat). Hope this helps. |
Since Docker supports IPv6 NAT via The quoted docs may only apply to stock configuration but they do describe the reason IPv6 is problematic out of the box, so I still see value in keeping that in the docs.
So even with that container setup and providing proper IPv6 NAT, you don't receive mail? But no errors like others are seeing? Do you have any other logs that communicate failures? |
I'm not sure what would proper IPv6 NAT mean in this case. Any configuration of IPv6 I found via web search and tried thus far, be it via |
I meant that it was supported instead of the container seeing an IPv4 address it should be an IPv6 one. I think it can be a bit more problematic if there are other containers routing the traffic though. With reverse-proxies for example, they handle this fine, but if a container they bridge needs the external IP, they need to provide it via a separate header IIRC, as otherwise they get the wrong IP (internal container IP). It would be helpful if there's a simple config + steps that I can try reproduce with when I get the time to investigate.
Oh, I misread your previous statement about public. Most reports are with the private address being rejected. I thought you were saying you weren't seeing that in your logs 😅 In that case, it's very much likely caused by this PR. I think if you revert that change, it may fix the problem. If you try this and it does fix it for you, please let us know. |
Sure, reset Docker config to default (i.e. remove
I believe this is the case. However, that PR is correct in its thinking so I don't want to revert it. The container receiving the connection via IPv6 should see the public IPv6 of the sending side and not the private IPv4/IPv6 address of the gateway. The problem is that it doesn't happen and I have no idea whether this is due to incorrect configuration of Docker or robbertkl/ipv6nat. Either way, the documentation should mention the issue exists. |
github-actions
Bot
added
the
meta/stale
polarathene
added
stale-bot/ignore
|
As is, this PR can not be merged as maintainers decided it removes information still relevant. Since IPv6 is just an awfu.. complex protocol, this needs more work. Moreover, this seems to have stalled, which I absolutely dislike, but I also understand it in this case.. so, @polarathene, what would you do now? I would like to do something about this PR - otherwise it will continue to rot. |
|
see #1438 and #3057 (with #3057 (comment)) for reference. Superseeds #3061
|
Closing in favor if #3244 which superseeds this PR. |
5 participants
Description
This fix no longer works as mentioned in #2927 and with my same experience. @vedranmiletic had the same experience too.
Fixes #2927
Type of change
Checklist:
docs/)