Andreas Kemper via Mailman-users writes:
Following this change, list continued operation as usual, but after a few days it seemed to be attacked via it's GUI, according to the attached Django error message.
If your users are not using socialauth login (that is, OAuth2 login with ID providers such as Google, GitHub, and Fedora). you should disable them. I have seen a couple of reports that poor OAuth2 implementations are being exploited, and it's annoying to have the baddies pounding on your site. You can disable each provider individually in settings.py.
That said, it appears the exception here is "expected" (a generic "wrong syntax" exception), and was handled without crashing. In any case, Django is unrelated to Mailman's post distribution.
You should check both mailman.log (which is where errors that would cause mail to go down would be) and mailmanweb.log and error.log for more information about the apparent attack on Django and whether it's actually causing problems.
Since then mailman doesn't send out anymore mails and I have a persistent master.lck file.
Log in to the host as the mailman user or use su or sudo (we recommend 'mailman', on Debian hosts many admins prefer to use Debian's 'list' user). Then run "mailman stop", That should remove the master.lck file. Then run "mailman start --force", which will do its best to remove the lock file if it remains. If the lock *still* remains, then you have a mailman master process that is still running (or you're quite unlucky and there's another process with that PID). You'll have to check for the running process, if it is Mailman presumably it's deadlocked or a zombie and you'll have to forcibly kill it. This should not lose mail or anything like that, but obviously it's a last resort. If it's not Mailman, don't kill that process, just remove that master lock file, and start Mailman.
If your init.d/mailman3 script or systemd unit file doesn't have the --force option, then you can add it. It's safe.
Furthermore, during mailman start smtp.log always shows a "Connection lost during _handle_client()".
This is unrelated to the master lock file, I'm pretty sure. Mailman simply won't start, and any information related to that will go to the console or mailman.log, not to smtp.log.
In addion, should I include further directives in my Caddyfile in order to protect mailman from coming attacks?
Aside from requiring TLS >= 1.2 for all connections, there's nothing generic. As I mentioned above, if you don't need a socialauth provider, then disable it in settings.py. If you're running an enterprise network with single-sign-on (SSO) such as Shibboleth, it's possible to configure Apache so that only SSO-authenticated connections get to talk to Django. I don't know if you can do that with nginx or Caddy, probably, but I've not done it myself.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan