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

Reply via email to