On Wed, Dec 07, 2016 at 10:01:54AM +0100, Julian Kippels wrote: > Am Tue, 6 Dec 2016 08:24:56 -0600 > schrieb /dev/rob0 <r...@gmx.co.uk>: > > > On Tue, Dec 06, 2016 at 08:59:56AM +0100, Julian Kippels wrote: > > > I use a policy deamon that registers every mail that is sent by > > > our servers. The metadata is stored in a SQL Database. Every two > > > minutes a cronjob is run which checks the metadata for which > > > sasl_sender has send how many mails. If a sasl_sender surpasses > > > a certain threshold the cronjob automatically blocks this user > > > in our LDAP so that he can't submit any more mails. > > > > First, I don't understand the need for the cron job. Just let the > > policy service keep track of the number of mails sent per SASL user > > and reject (or quarantine, via HOLD action, if that is better for > > your site) when the quota is reached. > > > > We use 4 MTAs that are load balanced. Without a central instance > keeping track of all mails it would be quite difficult to identify > a compromised account. Additionally we want to be able to view the > metadata afterwards. Hence we write it all to a postgres sql > database.
So I'm still confused. Why can't the policy daemon write to and read from PostgreSQL also? > > Likewise, there is no need to have the interaction with LDAP. > > The policy daemon should be able to do this all natively. > > This is just to stay compatible to established procedures. We have > just switched to using postfix as our MTA software. Before this we > used to have Sun Java System Messaging Server. All we do in LDAP is > to scramble the userPassword-Hash, so that it is impossible for the > user to log in. This forces the user to use our to change their > password to a new, uncompromised one. Sure, but it's still better to reject a spam right away, as soon as you know the credentials are compromised. Seems like you have built in a delay. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
