Curtis Maurand wrote, On 6/11/10 8:30 AM:
currently I have in my smtpd_client_restrictions: ...
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit
Is flat out rejecting clients on the RBL's considered too agressive?
No.
Or, yes. Maybe. A lot depends on who your users are and who their legitimate
correspondents are.
For "false positive" rejections, there is almost zero risk for almost all
mail systems in using Zen for absolute rejection, provided you make sure you
either exempt authenticated submission or don't have any need to do so. The
Spamcop BL is intrinsically a little riskier, but it has become a lot safer
over the past few years. Many systems use those two lists outside of scoring
structures without trouble.
Beyond the FP risk, there is a more subtle issue of whether the benefit of
rejecting spam cheaply is worth the potential cost of not having a steady
stream of representative spam feeding the adaptive dynamic features of a
scoring system like SpamAssassin.
should I just let spamassassin handle this and score accordingly?
A mailing list can't tell you who you are. That is especially true for one
made up largely of sysadmins. :)
Questions you need to address for a clearer answer:
1. How much mail are you handling? Scale can make lightweight spam rejection
important, but it can also reach a point where statistically you are
virtually assured of having a constant stream of FP's from even 'safe'
blacklists like Spamcop.
2. What sorts of users do you have? Business and personal mail systems are
often more deeply knowable in this aspect than are ISP and educational
systems, but anyone running a mail system has to be aware of who the users
are, how diverse their legitimate mail is, how much spam they get, etc.
3. How much spare capacity do you have? If you have a bunch of free memory
and idle CPU cycles, you may not be spending anything valuable to you by
showing every message to SA.
4. What are your tolerances for complexity and malfunction? One of Postfix's
best design features is that subtle and complex policy issues are left to
optional external programs. Limiting yourself to what Postfix can do by
itself means that you have a simpler configuration that is easier to get
right and easier to troubleshoot when it does not do what you want.
SpamAssassin is a great tool, but making it work well for your mail streams
and your users can be a lot of work. Restricting yourself to the
configurability of Postfix itself makes figuring out problems easier, but it
also means that you might not be able to solve problems in an ideal way.
Using the external filtering and policy tools that can be hooked into
Postfix offers you the freedom to devise configuration as subtle and
purpose-fit for your needs as possible, and using that freedom may chain you
to an endless task of tweaking that configuration.
And you thought your question was simple...
