Typically, bots messing with email servers do so for quite a lot of time before stopping attempts so it makes sense to ban them for longer than the system default (e.g. 10 minutes on Debian). 96 hours (4 days) seems to be a reasonable compromise between size of the fail2ban DB and ban usefulness. |
||
---|---|---|
.. | ||
fail2ban | ||
logrotate.d | ||
systemd | ||
vim | ||
README.md |
Distribution files for maddy
Disclaimer: Most of the files here are maintained in a "best-effort" way. That is, they may break or become outdated from time to time. Caveat emptor.
systemd unit
maddy.service
launches using default config path (/etc/maddy/maddy.conf).
maddy@.service
launches maddy using custom config path. E.g.
maddy@foo.service
will use /etc/maddy/foo.conf.
Both unit files use DynamicUser to allocate user account for maddy, hence you don't need to create it explicitly. Also, they use *Directory options, so required directories will be created as well.
Additionally, unit files apply strict sandboxing, limiting maddy permissions on the system to a bare minimum. Subset of these options makes it impossible for privileged authentication helper binaries to gain required permissions, so you may have to disable it when using system account-based authentication with maddy running as a unprivilieged user.
fail2ban configuration
Configuration files for use with fail2ban. Assume either backend = systemd
specified
in system-wide configuration or log file written to /var/log/maddy/maddy.log.
See https://github.com/foxcpp/maddy/wiki/fail2ban-configuration for details.
logrotate configuration
Meant for logs rotation when logging to file is used.
vim ftdetect/ftplugin/syntax files
Minimal supplement to make configuration files more readable and help you see typos in directive names.