[TriLUG] postfix spam blocking

Warren Myers volcimaster at gmail.com
Fri Dec 16 13:19:54 EST 2011


Can't recommend Barracuda highly enough!

IronPort is a solid solution, but far too expensive, in my opinion.

On Friday, December 16, 2011, Matt Pusateri <mpusateri at wickedtrails.com>
wrote:
> I think we were paying $16k a year for an Ironport, $1200/yr is cheap.
Depends on how many users though. Barracuda boxes are nice and effective
though.we use one at my kids school where there is zero tolerance for most
of the spam subjects, and it works great.
>
> Sent from my iPhone
>
> On Dec 16, 2011, at 8:30 AM, "Jim Ray" <jim at neuse.net> wrote:
>
>> I've tried several products and plan to go back to the one that works
>> best for us, Barracuda Spam Virus Firewall. It uses a combination of
>> techniques yet with proper tuning effectively blocks a measured 99% of
>> spam plus provides end user quarantine. Prepare to break out your
>> wallet, though, because even though they use open source products under
>> the hood, they package it together and charge $1200/year in services.
>> They now offer flavor that runs on Vmware ESXi as opposed to selling the
>> software on pizza box server that sounds like helicopter from Vietnam
>> era.
>>
>> Regards,
>>
>> Jim Ray, President
>>
>> 2 Davis Drive, PO Box 13169
>> Research Triangle Park, NC 27709
>>
>> main:    919-838-1672
>> cell:    919-606-1772
>> skype:    neusedotnet
>> email:    jim at neuse.net
>> web:    www.NeuseRiverNetworks.com
>>
>> ONE(tm) Plan to put IT maintenance behind the scenes, after-hours and
>> out of your way since 1997 with Service Representatives Available
>> 24/7/365
>>
>> Customer Service/Support: Send email to support at neuse.net or log on to
>> our web portal http://support.neuse.net
>>
>>
>>
>> -----Original Message-----
>> From: trilug-bounces at trilug.org [mailto:trilug-bounces at trilug.org] On
>> Behalf Of David Black
>> Sent: Friday, December 16, 2011 8:06 AM
>> To: Triangle Linux Users Group General Discussion
>> Subject: Re: [TriLUG] postfix spam blocking
>>
>> I experimented with client and recipient restrictions a while ago and
>> found the client restrictions sometimes blocked too early.  The
>> connecting MX didn't get enough of a chance to say much about who it was
>> and what it wanted, before being disconnected.  If the filters were 100%
>> accurate it'd be different, but the free RBLs, for instance, definitely
>> aren't.
>>
>> Better to load up recipient restrictions with a nice set of filters,
>> able to act on all the info gathered after the HELO.   The author of
>> this page seems to agree:
>> http://www.akadia.com/services/postfix_uce.html
>>
>> Also, postgrey works but does delay emails from new sources - the
>> MTA/to/from triad, and there's the odd MTA that doesn't know how to
>> correctly retry or takes a very long time to do so.  Many services use a
>> different from address every time, forcing a delay for *every* email.  I
>> used to use it and don't any more, because of the occasional legitimate
>> email that never arrived and more delays than expected.  At least in a
>> business setting, I've consistently found it's better to let a bit more
>> spam through and not block legit emails, than have the occasional - and
>> very important to the CEO - email just disappear.   IMHO today people in
>> general depend too heavily on email.
>>
>> These days I use spamassassin on the MXs to classify but not block.  The
>> decision to block/not block is done at the local mailbox delivery, and
>> the end user at least has an opportunity to fish an email out of their
>> junk folder.
>>
>> Dave
>>
>> ----- Original Message -----
>>> When setting up postfix to help curb spam, which is more
>>> correct/effective when specifically addressing RBLs?  OR can this be
>>> done in both places in main.cf to enhance the protection:
>>>
>>> smtpd_recipient_restrictions = reject_rbl_client zen.spamhaus.org
>>>
>>> OR
>>>
>>> smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org
>>>
>>> OR
>>>
>>> both?
>>>
>>> OSX Server puts the setting in the smtpd_client_restrictions via the>
This message was sent to: M. Pusateri <mpusateri at wickedtrails.com>
>> To unsubscribe, send a blank message to trilug-leave at trilug.org from
that address.
>> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web    :
http://www.trilug.org/mailman/options/trilug/mpusateri%40wickedtrails.com
>> TriLUG FAQ          :
http://www.trilug.org/wiki/Frequently_Asked_Questions
> --
> This message was sent to: Warren <volcimaster at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
http://www.trilug.org/mailman/options/trilug/volcimaster%40gmail.com
> TriLUG FAQ          :
http://www.trilug.org/wiki/Frequently_Asked_Questions
>



More information about the TriLUG mailing list