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

Reply via email to