On 1/31/2012 8:30 PM, l...@airstreamcomm.net wrote: > On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones <njo...@megan.vbhcs.org> > wrote: >> On 1/31/2012 8:03 PM, l...@airstreamcomm.net wrote: >>> We run a small cluster of postfix servers that are dedicated outbound >>> relayhosts for our customers. Beyond the outbound postfix cluster we >>> have >>> another cluster of mail filtering appliances that have served their >>> purpose >>> very well, but we are starting to get more compromised account due to >>> phishing attempts and some of the spam is getting through the outbound >>> filters due to the volume of new spam messages. >>> >>> I am looking for advice on how to limit our exposure to malicious > senders >>> that have access to a users credentials. One method we have zero >>> experience in is using RBLs, which I am hoping to learn more about. >>> >> >> Most people address this with sender rate limits using a policy >> service such as policyd or postfwd, possibly combined with outbound >> virus/spam scanning. >> http://www.postfix.org/addon.html#policy >> >> Once the rate limit (or outbound virus/spam limit) is tripped, the >> account is flagged for an admin to check further, and maybe >> temporarily disabled depending on site policy. >> >> I'm not quite sure how an RBL would be useful here. >> >> >> -- Noel Jones > > What we were thinking was using RBLs to dynamically block known malicious > IPs before allowing SMTP Auth to occur, hopefully seeing a decrease in > spam. Not sure if this would have unintended consequences, which is why I > am consulting the list. >
That would probably cause a huge number of false positives; a support desk nightmare. Many "consumer" IPs are listed on the popular RBLs. As a consequence, legit users may be unable to send mail because their dynamic IP was used by a spambot at some point in the past. I don't know of any RBLs that would be useful on incoming authenticated mail. You can test this yourself by inserting "warn_if_reject reject_rbl_client zen.spamhaus.org" just before permit_sasl_authenticated. Then watch your logs for reject_warning: from legit connections. (this is a logging-only function; the client is not rejected and sees no additional messages.) -- Noel Jones