On Mon, May 29, 2017 at 10:34:11AM +0200, Bastian Blank wrote: > On Sun, May 28, 2017 at 04:07:08PM -0700, Hubro wrote: > > I have already made similar scripts, but the issue is that it runs "postcat" > > and "postsuper" once for every queue ID, so it becomes absolutely unusable > > when needing to delete tens- or hundreds of thousands of emails. > > Why do you have tens- or hundreds of thousands of emails waiting to be > deleted?
Right. Use a policy daemon to limit the number of messages a client, sasl_username or IP address, can send in an hour/day. Then run scripts every interval to warn you of IPs and sasl_usernames as they approach the limits. Then you can take corrective action before millions of messages have been sent and the queue has 100s of thousands of defered messages. I remember the days of trying to improve the cleanup proceedure. They were horrible days. With policyd, 200 messages/recipients per hour, 500 messages/recipients per day works for most of my customer base. I have a few, thirty-ish, who legitimately need to send more than that. A separate policy group with limits of 10,000 per hour and 50,000 per day handle them. They get the talk about keeping their passwords secure. You would have to pick values which make sense for your userbase. Scripts process the maillog hourly and send me e-mail telling me the top sasl_usernames for the day and what IPs they've logged in from with counts, and the logins from "unusual" IP addresses since the log rotated. If someone logs in from overseas who usually doesn't, I look at the maillog to see if the recipeint addresses look okay. If I can't tell, I just watch it over the next day or week. We still have between 3 and 20 accounts phished each month, but I don't lose sleep over them. I don't even stress over doing the cleanup. There are usually very few messages still in the queue. And having allowed even 1,500 messages via three phished accounts while I was off-line for sleep does so much less damage to my server's reputation. Having three of the high-volume accounts compromised would be bad, but not as bad as one account without limits for one hour. When we have a compromise, I run a script with disables the account, changes their password to a new random value, and e-mails the customer service reps. I sleep really well and spend a lot less time on compromised accounts now. -- Scott Lambert KC5MLE Unix SysAdmin lamb...@lambertfam.org