I am not sure if this is ready to merge yet. Maybe we need some discussion as well:

• One question is: Why can't we simply take the upstream version of the config? Does anybody know the reason? It would allow us to get fixes from upstream.
• The other one is: Should I write a test for this? If yes, how?

I'm really not sure, I'm not using fail2ban in the container myself as I don't want to grant that. It would be nice if someone more familiar with the setup could chirp in. I agree that it would be much nicer to simply use the upstream rules if that is possible. @fbartels?

i must say i am not using it either. it seems it was introduced for convenience quite a while ago. But if its largely similar to the packages default the the default should imho be used.

@nknapp if you have time can you check the next branch? Is it also affected and/or has this been fixed there? If we can change to the default upstream configuration I'm all for that unless it breaks something. If it passes the existing tests that is a great start!

i must say i am not using it either. it seems it was introduced for convenience quite a while ago. But if its largely similar to the packages default the the default should imho be used.

Briefly comparing to the mainstream version, I haven't found big differences. I would suggest to remove this override. Perhaps @r-pufky can comment?

@gmasse Not really sure if I can provide any additional context here; though I do agree with what's being said in this thread with some additional thoughts:

• Large mental strain induced for a 0.9.x F2B container versus current releases; whichs includes breaking changes compared to modern releases. I would bet that most people don't even realize this is an issue using F2B in this container. (Given the buster changeover, F2B will rollout breaking changes).

• Should be running as close to possible as a direct F2B upstream pull as possible. Given Debian stretch F2B release is essentially 14 releases behind head, which also includes a major breaking changes; I would recommend (and do) run a separate F2B container with modern rulesets; which also reduces privileged system access in this container. Maybe there should be a poll for actual F2B usage within the container to determine if it remains in the image, or a modern back-ported version for the container.

• Custom rules within the container should be explicit as to the intent and why it is different from the vanilla upstream ones, with comments clearly stating intent and purpose for those rules. I would guess given the age (~3 years) of these rules that most rules are covered in a modern F2B release and only a small additional subset are needed. In addition, four years has probably allowed for things to stablize and standardize in F2B best practices. This would need to be analyzed.

A poll would be great, but I don't think we will get that many answers and the ones we get may not be representative. Perhaps we should focus on the next branch (buster), go with upstream and see what happens to the tests? If they pass it can't be all that bad.

I removed the custom rules and unfortunately that broke the tests. I'm still in favor of doing that, but as I'm not using this feature myself I don't want to be the one who drives it and fixes the tests. As of now the latest release which is now based on Buster still has the old rules.

I don't know when I find the time to do this, but I am willing...

I haven't found out how to run the tests locally though. Can you tell me?

Yes indeed. First of all you need a Linux box (real or virtual). The tests work only on Linux. Then you should be able to follow https://github.com/tomav/docker-mailserver/blob/master/CONTRIBUTING.md. The main gotcha is the git submodule init and git submodule update steps. Please give it a try and let me know if you have questions!

I have reverted my original change, reset my branch to tomav/master and pushed a change that uses the distributed version of "/etc/fail2ban/filter.d/dovecot.conf" and removes the custom-version from this repo.

I ran the tests locally and they have all passed. I am running them again, to be sure.

I have also had a look at the "fail2ban/filter.d/dovecot.conf" that is now in the container. It seems to contain a regex for "aborted authentications" as well, but labelled "mdre-aggressive". I suspect this is only active if "mode=agressive" is set for the dovecot jail.

So, everything should be fine, but I will try to write a testcase to ensure that attempted connections do not lead to the banning of the client.

Very good. When I tried I also removed postfix-sasl.conf, but I see that you have kept it. Do you want to complete the test first, or shall I merge this one?

Of you are OK with it, please merge. Saves me one more rebase, I guess.