Prev: reject_unverified_sender in postfix woud like to over ride withemail address
Next: Disable Connection Cache for local filters
From: Charles Marcus on 19 May 2010 07:03 On 2010-05-19 6:33 AM, Stan Hoeppner wrote: > Then just delete the 20K messages from the queue using postsuper > within a script and reset the password on the compromised account. He wasn't asking how to delete the queued messages, he was looking for a way to limit the damage if a user account gets compromised in the future (this subject has come up before), and rate-limiting is one way to do that. Enforcing strong passwords is another. -- Best regards, Charles
From: Kenneth Marshall on 19 May 2010 08:23 On Wed, May 19, 2010 at 07:03:12AM -0400, Charles Marcus wrote: > On 2010-05-19 6:33 AM, Stan Hoeppner wrote: > > Then just delete the 20K messages from the queue using postsuper > > within a script and reset the password on the compromised account. > > He wasn't asking how to delete the queued messages, he was looking for a > way to limit the damage if a user account gets compromised in the future > (this subject has come up before), and rate-limiting is one way to do > that. Enforcing strong passwords is another. > With replies to phishing attempts and keyboard/password sniffers, limiting the damage is often the first step and can also be used to help identify the compromised accounts. Strong passwords do not help in these situations. Cheers, Ken
From: Charles Marcus on 19 May 2010 08:36 On 2010-05-19 8:23 AM, Kenneth Marshall wrote: > On Wed, May 19, 2010 at 07:03:12AM -0400, Charles Marcus wrote: >> He wasn't asking how to delete the queued messages, he was looking for a >> way to limit the damage if a user account gets compromised in the future >> (this subject has come up before), and rate-limiting is one way to do >> that. Enforcing strong passwords is another. > With replies to phishing attempts and keyboard/password sniffers, > limiting the damage is often the first step and can also be used to > help identify the compromised accounts. Strong passwords do not > help in these situations. I agree - maybe you misread my response to mean either/or? I did word that part of my response badly. What I meant to suggest was to use *both*, to provide a *layered* approach. Imo, strong passwords comes first - then rate-limit to detect the idiots who fail the phish tests and disable their accounts until the damage can be dealt with appropriately. Depending on the situation (good for corporates, bad for ISPs), you could also consider adding an internal 'phish test' occasionally (monthly? quarterly?), to catch the idiots in the act, so you can engage them in training sessions on how to recognize phishing attempts. -- Best regards, Charles
From: Gary Smith on 19 May 2010 11:44 >I am using Postfix as an MTA but I see nowadays lot of spam going out of my system. I have used transport based throttling for a domain but I am looking for options for per sender based rate limiting. Can I achieve per user based throttling using postfix or I have to use some 3rd party software ? >If no what rate limiting software can I use to achieve this. Anything is possible. I'm working on a similar idea for controlling this, where I track the message count over a period of time, for each sender, and if it goes beyond a threshold, they are suspended until it's resolved (or they stop sending). General idea is to catch the SASL sender on before queue, script it against and in memory db (like memcached), and allow/reject based upon throttles setup. If you can write perl/python there are some working samples over on the postfix site that have a base framework for this.
From: Punit Jain on 20 May 2010 01:24
> Anything is possible. I'm working on a similar idea for controlling this, where I track the message count over a period of time, for each sender, and if it goes beyond a threshold, they are suspended until it's resolved (or they stop sending). > General idea is to catch the SASL sender on before queue, script it against and in memory db (like memcached), and allow/reject based upon throttles setup. If you can write perl/python there are some working samples over on the postfix site that have a base framework for this. I came across Policyd. It seems to follow similar Perl script for rate limiting. Does that sound like a solution ? |