Spam issues and how to overcome them

[Carpenter, Troy]

On 2016-06-14 04:00 PM, Lance Charette wrote:
> On 6/13/2016 11:17 AM, Philip Trickett (List) wrote:
>> Hi Homer,
>> 
>> I have taken a similar route to you, but I found the things I 
>> implemented that reduced spam the most were:
>> 
>> Greylisting using Postgrey: http://postgrey.schweikert.ch/ 
>> https://www.howtoforge.com/greylisting_postfix_postgrey
>> 
>> Implementing DKIM and SPF for postfix: http://www.opendkim.org/ There 
>> are some good howtos out there as well.
>> 
>> I am using Kolab on Centos 7, but it should be fairly simple to 
>> implement, the most frustrating part is waiting for the DNS updates 
>> for DKIM.
>> 
>> 
>> Hope that helps,
>> 
>> 
>> Phil
> 
> Thanks a bunch Phil and Nathanael for your replies.
> 
> I too had been using greylisting and spf which helped considerably
> however it wasn't near enough for the amount of spam our accounts are
> getting.
> 
> I was hoping to find some information on how I could set up black &
> white lists that could be contributed to by each email user within the
> Roundcube mail client but haven't seen anything yet.  As I indicated
> in the beginning of this tread, I owned and operated an ISP for over
> 15 years and have used a wide variety of email servers and separate
> anti-spam servers as well, all set up and configured within so I have
> a pretty good handle on the do's and don'ts and have done so on both
> Windows based and Linux based platforms.  This is the first time
> however where I have used an 'environment' that takes so many tools
> that are independently otherwise off the shelf and tries to meld them
> all into one.  It's a far cry different than just using an email
> server and a separate anti-spam package... i.e. like spamassassin on
> it's own.
> 
> In the Kolab environment you have Kolab wrapped around everything,
> amavis wrapped about spamassissin and so on and so on and it's the
> lack of a well documented 'strategy' that makes it difficult to know
> (understand) how one affects the other, etc.  A solid block diagram of
> how all the pieces fit into the puzzle would be a great start. Solid
> examples of actual configuration files for a particular Kolab version
> would also help a lot.
> 
> I understand that this is a 'community' effort but one HAS to believe
> that the primary retail side of Kolab has already worked these issues
> out and could reciprocate in the reverse direction given they benefit
> from the community as they do.
> 
> Once satisfied with a working environment... and one that doesn't
> require administration on a daily basis... I will post my examples for
> others in 'our boat' to have something to start from.  I have set up
> two dedicated ScrollOutF1 vm servers, each on the same vm server the
> Kolab resides on respectively and have setup virtual networking within
> for the ScrollOutF1 to talk directly to the Kolab environment
> eliminating the additional load on the physical network.  That's
> working very well.  Also, as ScrollOutF1 is using many of the same
> tools already embedded in Kolab, I'm actually hoping to take the
> settings once defined to our satisfaction in ScrollOutF1 and migrate
> them to the Kolab equivalents and ultimately take ScrollOutF1 out of
> the picture.
> 
> Again, thanks everyone and I will continue to push on and contribute
> as it becomes apparent I have a well working environment... which I
> hope to be soon.  I have users that may exterminate me if I don't.
> 
> hdokes
> users at lists.kolab.org



I'm a little late to this thread...but according to my logs, the 
following smtpd_recipient_restrictions line in my postfix main.cf goes a 
long way to stopping quite a bit of SPAM:

smtpd_recipient_restrictions = permit_mynetworks,
                                permit_sasl_authenticated,
                                reject_unauth_destination,
                                reject_invalid_hostname,
                                reject_unauth_pipelining,
                                reject_non_fqdn_recipient,
                                reject_unknown_recipient_domain,
                                reject_invalid_helo_hostname,
                                check_policy_service 
unix:private/recipient_policy_incoming,
                                reject_rbl_client zen.spamhaus.org,
                                reject_rbl_client dbsbl.sorbs.net,
                                reject_rbl_client bl.spamcop.net,
                                reject_rbl_client rhsbl.sorbs.net,
                                permit

Obviously the reject_rbl_client is the section that does the most.  I 
haven't updated that in a while, so I make no claims as to which of 
those services work except for zen.spamhaus.org and bl.spamcop.net, both 
of which I've seen in my recent logs as being used to block.

For items that get through that, spamassassin still catches quite a bit. 
  It tags and a sieve script moves the email to the Spam directory if the 
score is low enough; otherwise if the score is high, Amavisd shunts it 
to a quarantine database with a web interface for users to release if 
necessary.

The only thing I don't have a good handle on is training the Bayesian 
database...but I only have about 10 users on the system right now.

Troy