|Main Archive Page > Month Archives > engarde-users archives|
We are running v3.0.9
We have been experiencing a big increase in spam being sent to our web address and I've been looking for ways to reduce this problem.
I found some very good tips at
After making the changes shown below, I analyzed the message log over a 24 hour interval starting at 10/22/2006 00:15 and found that the system blocked 772 messages while sending 140. Unfortunately, most of the 140 sent are also spam, so more restrictions are needed.
Since our email system is mostly used to route incoming messages back out to real email addresses, I need to focus on ways to avoid relaying spam. At this point it seems like the best next step is to implement greylisting.
Has anyone implemented greylisting when running with the default SELinux policy? If so, would you be willing to help me with the needed steps? This would involve activating the last two commented out lines of the section shown below, as well as implementing the other steps outlined in the article I quoted above.
Or, is there a better way to proceed?
# part 2
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain,
# part 3
smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination,
reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client dnsbl.njabl.org, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client bl.spamcop.net,
reject_rhsbl_client blackhole.securitysage.com, reject_rhsbl_sender blackhole.securitysage.com,
# check_policy_service unix:private/spfpolicy
# check_policy_service inet:127.0.0.1:10023
# end spam restrictions added 11/20/06