Simon / Jean >I'm not sure what you mean by instructions for production usage but if you >are exposing james on the public internet please make sure to setup >fail2ban or the crowdsec hooks, there will be a lot of bots out there >hammering your server to bruteforce passwords
hmm, well since I run a publicly exposed mail exchanger (actually not James, but that's neither here nor there) and fail2ban I can add to this. Firstly, if you want fail2ban to watch the log output produced by James, be prepared to write your own python regex filters. And fail2ban will not allow you to just make a "lazy" or crude match; I suggest that may be problematical, especially if like myself, you do not know python. Secondly and I think lastly also, I have never yet (in many years) seen an attempt to brute force my imaps port or even a single unexplained failed log in attempt. At the moment (past several weeks) I am seeing loads of attempts to deliver mail to non-existing users of one particular domain; so these just get blackholed by the mail exchanger, fail2ban sees this in the logs and blocks the ip address. I've configures for a 400 hour block; I can't say what would happen without fail2ban, but the small VM is untroubled memory wise and always responds promptly to requests for hosted web pages. Hard to understand who thinks this bad behaviour is a worthwhile exercise and what they hope to achieve! It does seem there are people with control of a large number of compromised machines that are short of useful things to do :-) -- David Matthews m...@dmatthews.org --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
