This PR should be properly tested before merging. It's not just replacing iptables with nftables, because they both are mostly compatible, but not 100%. Otherwise we wouldn't have to introduced the usage of iptables-legacy in the past. What was the reason for that? Is that reason now obsolete?
I ran into issues when I switched from one to the other and ended up reverting it. That was some time ago and I can't remember what exactly the issue was.

I think the reason for switching to legacy was that the support for Fail2Ban was not there at the time. Support was introduced not too long ago. At the time of the change to legacy (i.e. the change to Debian 10 I guess), Fail2Ban was not ready. Moreover, it was just easy to change to legacy instead of adjusting configurations.

Now, Fail2Ban is ready and I tested the mail server locally. Everything seems to be running quite smoothly. F2B can ban IPs, nft makes working with the routing way easier (compared to iptables).

While I agree that we should be careful here to not forget anything, I cannot think of anything right now. We do not have to merge this straight away, maybe you @casperklein can test with an image created from this branch like I did? Other than that though, I think we're quite fine.

maybe you @casperklein can test with an image created from this branch like I did

Yes, but earliest next week.

Another thing that come to my mind: At the moment, my host and DMS uses iptables. I don't know if it could be problematic, if host and container doesn't match?

Interesting to know would be, if there are already working setups at the moment, with nftables on the host and iptables in DMS.

maybe you @casperklein can test with an image created from this branch like I did

Yes, but earliest next week.

👍

Another thing that come to my mind: At the moment, my host and DMS uses iptables. I don't know if it could be problematic, if host and container doesn't match?

My tests took place on such a system, i.e. iptables on the host and nftables on the system.

Interesting to know would be, if there are already working setups at the moment, with nftables on the host and iptables in DMS.

This I cannot test currently.

I have an idea about testing the image from this branch: I will push the image built from this branch to GHCR. This way, everyone can test the new changes beforehand.

EDIT: You can now pull ghcr.io/docker-mailserver/docker-mailserver:testing-nftables

I'm running this in production now, and it seems to work very well. I had some troubles at first, but this was due to a wrong custom configuration on my side. F2B bans IPs properly:

root@mail:/# fail2ban-client status
Status
|- Number of jail:	5
`- Jail list:	dovecot, postfix, postfix-sasl, postscreen, recidive
root@mail:/# fail2ban-client status postfix
Status for the jail: postfix
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	6
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	2
   `- Banned IP list:	212.70.149.72
root@mail:/# nft list set inet f2b-table addr-set-postfix
table inet f2b-table {
	set addr-set-postfix {
		type ipv4_addr
		elements = { 212.70.149.72 }
	}
}

I will make an announcement and I will monitor the logs. If all seems well, we can then go ahead and merge this to be in v11 (maybe even as the last PR to go into v11).

@casperklein what do you think about merging this as the last PR for v11 after #2506 and #2525 are merged?

Yes, but also #2530 + one little fail2ban script feature I going to provide this week.

Edit: Basically, all PRs that are tagged for v11? https://github.com/docker-mailserver/docker-mailserver/milestone/10

Edit: Basically, all PRs that are tagged for v11? https://github.com/docker-mailserver/docker-mailserver/milestone/10

Yes :D And this one as the last one :)

I don't care. For me, this PR is fine and can be merged anytime. Or do I miss something?

I don't care. For me, this PR is fine and can be merged anytime. Or do I miss something?

Nothing :) I will go ahead and merge this then, as I too think this is fine.

Documentation preview for this PR is ready! 🎉

Built with commit: eb59b7a

I noticed these days, that in my setup IPs don't seem to be banned anymore. Banned IP count gets lower every day.

From today, I see this in /var/log/fail2ban.log:

2022-04-20 17:04:06,001 fail2ban.filter         [2394]: INFO    [dovecot] Found 63.134.141.35 - 2022-04-20 17:04:05
2022-04-20 17:04:07,646 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 63.134.141.35 - 2022-04-20 17:04:07
2022-04-20 17:24:24,724 fail2ban.filter         [2394]: INFO    [dovecot] Found 112.219.231.93 - 2022-04-20 17:24:24
2022-04-20 17:24:26,198 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 112.219.231.93 - 2022-04-20 17:24:26
2022-04-20 17:24:41,165 fail2ban.filter         [2394]: INFO    [dovecot] Found 207.191.163.60 - 2022-04-20 17:24:40
2022-04-20 17:24:42,623 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 207.191.163.60 - 2022-04-20 17:24:42
2022-04-20 18:06:46,160 fail2ban.filter         [2394]: INFO    [postfix] Found 182.204.178.57 - 2022-04-20 18:06:45

However, cross-checking with fail2ban-client status postfix, I don't see 182.204.178.57 as banned. Could someone else check if banning still works?

Edit: Found != Banned. My fault.

@georglauterbach

My tests took place on such a system, i.e. iptables on the host and nftables on the system.

There are 2 types of iptables. The current version is meant to be a drop-in replacement for the older (legacy) iptbales, but under the hood it uses nftables.
The other version is iptables-legacy. On Debian based systems you can switch to that version using update-alternatives --set iptables /usr/sbin/iptables-legacy

Some appliance, notably QNAP, still uses the legacy version of iptables, and don't ship with nftables, although they have recent Linux kernels.
For those systems, nftables (and the new iptables) is not available in Docker environment

This PR broke those systems :)

PR #2662 contains a discussion about this issue. Although I fully agree of not carrying legacy stuff around, it's important for docker-mailserver users to know about this issue.

@dguerri now that you say it, yes, I was using the drop-in replacement of iptables which uses nftables under the hood. I will put my other notes under your PR :)