Spam issues and how to overcome them

Lance Charette lcharette at slingshottech.net
Tue Jun 14 22:00:06 CEST 2016


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


More information about the users mailing list