New email server options

X

xy16644

Hi all,

I am in the planning stages of building a new server. If interested here is the hardware I will be using:

New Server Build

I am currently running the following on my existing server for email:

  • Courier-authlib
  • Courier-IMAP
  • Cyrus SASL
  • Postfix
  • Procmail
  • SpamAssassin
  • Roundcube
  • ClamAV

Although I have been pretty happy overall with the above ports I was having a rethink as to what I should use on the new server. After a bit of R&D I put this list of ports together:

  • Dovecot IMAP
  • Postfix (no change)
  • Maildrop
  • Bogofilter
  • Roundcube (no change)
  • Spamd tarpit/greylisting
  • ClamAV (no change)

From what I understand mail/dovecot replaces security/courier-authlib, mail/courier-imap and security/cyrus-sasl2, is this correct?

mail/procmail is being replaced by mail/maildrop and mail/p5-Mail-SpamAssassin is being replaced by mail/bogofilter.

mail/spamd is a new addition.

Is this a good choice of ports for running a secure/stable email server? I've only read up on the new ports I plan on changing to so I have no experience with them. Clients include Thunderbird and Smartphones (Android) with the occassional user accessing their email via a web browser.

Just to make sure I understand the order that these ports are used in when email is being processed (for incoming email) I have the following order in my mind (please correct me if I am wrong or have misunderstood):

Code: 
spamd ---> postfix/ClamAV ---> bogofilter ---> maildrop ---> users mailbox

Am I on the right track here? Appreciate any feedback! :e
 
mail/maildrop and mail/bogofilter have worked for me. Both of those kind of depend on the users, the first to program a .mailfilter or use a prewritten one. bogofilter depends on a realistic sample of actual spam, so the users have to save it somewhere.

I tried mail/spamd but did not keep it. Can't recall exactly the problem, probably something to do with my particular use of DNSBLs, rejecting entire CIDR address ranges, and reverse DNS.
 
Thanks @wblock@.

If I decide to go ahead and use the chosen ports above, is this the correct order that each port is called when an email is received:

Code: 
spamd ---> postfix/ClamAV ---> bogofilter ---> maildrop ---> users mailbox

I just want to make sure I have the order correct in my head first before getting into more detail!
 
Last edited by a moderator:
If you are at the stage of researching options for a new email server I would point out that OpenSMTPD is a recently matured option.
[OpenSMTPD]
Goals

Be as secure as possible. Code carefully, do strict validity checks especially in the network input path, and use bounded buffer operations. Use privilege separation to mitigate the effects of possible security bugs.
Reliability is extremely important, any e-mail that OpenSMTPD has accepted has to be handled with care and must not be lost.
Provide a lean implementation, sufficient for a majority. Don't try to support each and every obscure usage case, but cover the typical ones.
Provide a powerful and easy to understand configuration language.
Be fast and efficient. OpenSMTPD must be able to handle large queues with reasonable performances.

OpenSMTPD www@openbsd.org
$OpenBSD: goals.html,v 1.1.1.1 2012/10/08 18:31:31 gilles Exp $
Click to expand...

Whether OpenSMTPD supports your particular needs is something you will have to decide - I can vouch that it is lean, clean, efficient and well documented.
 
xy16644 said:
Thanks @wblock@.

If I decide to go ahead and use the chosen ports above, is this the correct order that each port is called when an email is received:

Code: 
spamd ---> postfix/ClamAV ---> bogofilter ---> maildrop ---> users mailbox

I just want to make sure I have the order correct in my head first before getting into more detail!
Click to expand...

It can be done that way, I think, but I use an entry in .mailfilter (maildrop) to run bogofilter. That way all the mail from mailing lists and such can be sorted before it gets to bogofilter.

Code: 
...
# run bogofilter if present
BOGOFILTER=`which bogofilter`
if ( $BOGOFILTER )
{
    xfilter "$BOGOFILTER -e -p"
    if (/^X-Bogosity: Spam, tests=bogofilter/)
    {
        xfilter "${REFORMAIL} -a'$SPAMHEADER bogofilter detection'"
        to $SPAM
    }
}
 
Last edited by a moderator:
xy16644 said:
Is this a good choice of ports for running a secure/stable email server?
Click to expand...
Maybe I'm stating the obvious, I'll take that risk, but comments like these trigger that in me. Please be well aware that running a secure and/or stable e-mail server is not determined by the kind of software you use but totally depends on how you're using ("configuring") and maintaining said software.
 
All I'm trying to do is ensure that the new server I build (and configure) works as well as the current one. I built the current email server using the book "Building a Server with FreeBSD 7 A Modular Approach" and over the years added greylisting etc.

For the new server I would like it to scan emails with ClamAV, recognise a spam email and put it into a "Junk" folder and to use greylisting.

I currently receive maybe one junk email every day or two in my junk folder and would like to keep it that way!
 
As others have covered your original question, I'll add one useful tip: Start with the least expensive test.

If you're checking SPF records, do that early as it's a cheap test. DNSRBLs are relatively cheap too, so those go early, but obviously after SPF. Greylisting is cheaper than spam/virus checking, so that obviously goes next. And so on.

Do configure a DNS cache, specifically for your mail server if you can. This will help reduce the risk of your server being used in a DDoS against someones name servers, as well as reduce the load on your own server.
 
I do currently use SPF checking and have my SPF record set[ ]up in DNS.

I don't use DNSRBL so this is something I will look into for Postfix.

Greylisting for me is a must, I found it incredibly good. It reduced the spam in my Junk mail folder by about 80-90%! I literally receive one spam email every day or two now. Amazing.

I've read that some people use SpamAssassin AND Bogofilter, why is this? I also see some people using ClamAV AND Amavis, why? I would have thought one or the other would have been good enough?
 
xy16644 said:
I also see some people using ClamAV AND Amavis, why?
Click to expand...
Why not? If you simply check the Amavis website (link to Amavis-new website) to read up on what the software actually is you'll quickly see for yourself:

amavisd-new is a high-performance interface between mailer (MTA) and content checkers: virus scanners, and/or SpamAssassin.
Click to expand...
As such it's not a virus or spam scanner of its own, thus using it without one would be a somewhat illogical thing to do.
 
Make sure you do the math on how much time it takes to process one email message and convince yourself that your server can take that kind of load. Do that for an average case and then for the worst case. Doing all kinds of content filtering as part of the SMTP negotiation can be very resource heavy. If you have a busy domain and your server does not cope with the load you risk dropping valid SMTP connections because the content filtering takes too long and the client hangs up when the server does not respond in timely manner.
 
Currently I host three domains (two are mine and one is a friend's). Looking at the stats the server processed 40000 emails in the last year (sent and received) so it's not too busy at all.

I just want to minimise (or eliminate!) spam and not receive any emails infected with a virus.

At this stage I am trying to figure out the best ports to use for my new email server. I'm still battling to understand why people use SpamAssasin and Bogofilter as well as two AV scanners. Am I missing something? I have only been running one of each on my current server and it has been fine. What's the reason for two of each? Added protection? Peace of mind?
 
The reason to use more than one of a particular type of spam detection is because none of them catches everything. Systems usually are not set up that way from the start, new tests are added to catch the undetected spam that got through.

@Savagedlight makes an excellent point about the order of the tests. Ordering them from cheap to expensive (in terms of resources used) helps to cut your costs. I'd suggest adding GreetPause, but I think spamd already does that.
 
Last edited by a moderator:
wblock@ said:
The reason to use more than one of a particular type of spam detection is because none of them catches everything. Systems usually are not set up that way from the start, new tests are added to catch the undetected spam that got through.

@Savagedlight makes an excellent point about the order of the tests. Ordering them from cheap to expensive (in terms of resources used) helps to cut your costs. I'd suggest adding GreetPause, but I think spamd already does that.
Click to expand...

Thanks @wblock@, that makes sense.

I also like the point @Savagedlight makes about testing from cheap to expensive.

I think I am maybe trying to take on too many ideas here at one time and need to break this down into smaller chunks. So what I was thinking of doing was starting simple:
  1. Install Postfix
  2. Implement SPF/DNSRBL
  3. Use postscreen (Postfixes equivalent to GreetPause? URL: Postfix Postscreen Howto)
 
Last edited by a moderator:
Agreed. Start with Postfix. I'd do mail/spamd next. DNSRBL should be easy, although I don't know the details for Postfix. SPF... meh. That's an anti-forgery thing, despite it originally being billed as antispam. SpamAssassin does it internally anyway.
 
wblock@ said:
Agreed. Start with Postfix. I'd do mail/spamd next. DNSRBL should be easy, although I don't know the details for Postfix. SPF... meh. That's an anti-forgery thing, despite it originally being billed as antispam. SpamAssassin does it internally anyway.
Click to expand...

I agree. I want mail/spamd for its greylisting/tarpitting. When I enabled greylisting on my current server my spam levels dropped substantially.
 
Although I don't have experience with mail/spamd myself I can recommend using mail/postgrey as a greylisting extension for Postfix. Simply because it was designed to be used together with Postfix and it seemingly blends in.

For example; it's configuration files also end up in the main Postfix directory and this makes it very easy to configure and administrate. Enabling it only takes one addition to the smtpd_recipient_restrictions option to point the check_policy_service to the port postgrey is listening on.
 
ShelLuser said:
Although I don't have experience with mail/spamd myself I can recommend using mail/postgrey as a greylisting extension for Postfix. Simply because it was designed to be used together with Postfix and it seemingly blends in.

For example; it's configuration files also end up in the main Postfix directory and this makes it very easy to configure and administrate. Enabling it only takes one addition to the smtpd_recipient_restrictions option to point the check_policy_service to the port postgrey is listening on.
Click to expand...

I use mail/postgrey and have been VERY happy with its results! The amount of spam was reduced by about 80-90% when using this port.

I think I am going to give mail/spamd a miss. I will not be running a firewall on my server (as my server sits behind my router/firewall) and from what I understand mail/spamd required PF (or a firewall).

I think mail/postfix and mail/postgrey are a great combination.

Am I correct in saying that PostScreen in Postfix is the same as tarpitting in mail/spamd?
 
So today I started using Postscreen and I have to say, the results have been impressive so far! I have set the following in my /usr/local/etc/postfix/main.cf:
Code: 
postscreen_access_list = permit_mynetworks,
        cidr:/usr/local/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3
        b.barracudacentral.org*2
        bl.spameatingmonkey.net*2
        dnsbl.ahbl.org*2
        bl.spamcop.net
        dnsbl.sorbs.net
        psbl.surriel.com
        bl.mailspike.net
        swl.spamhaus.org*-4
        list.dnswl.org=127.[0..255].[0..255].0*-2
        list.dnswl.org=127.[0..255].[0..255].1*-3
        list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 3
postscreen_greet_action = enforce
postscreen_greet_banner = Please don't spam!

postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes

There is a delay in receiving emails (which I was expecting) of about 15[ ]minutes but I am happy with this considering the benefits of having little to no spam.

Before starting to use Postscreen I had the following options set in /usr/local/etc/postfix/main.cf
Code: 
smtpd_delay_reject = yes
smtpd_client_restrictions = reject_rbl_client cbl.abuseat.org,
                            reject_rbl_client b.barracudacentral.org,
                            reject_rbl_client zen.spamhaus.org,

smtpd_recipient_restrictions = permit_sasl_authenticated,
                               permit_mynetworks,
                               reject_unauth_destination,
                               check_policy_service unix:private/spf-policy,
                               check_policy_service inet:127.0.0.1:10023,
                               reject_rbl_client b.barracudacentral.org,
                               reject_rbl_client zen.spamhaus.org,
                               reject_rbl_client psbl.surriel.com,
                               reject_rbl_client cbl.abuseat.org,
                               reject_rhsbl_client dbl.spamhaus.org,
                               reject_rhsbl_sender dbl.spamhaus.org,
                               reject_rhsbl_helo dbl.spamhaus.org,

Is greylisting and DNSRBL checking needed in smtpd_client_restrictions and smtpd_recipient_restrictions now that I am using Postscreen?
 
I've been running Postscreen for about a week now and I thought I'd share my results.

In seven days, five spam emails were "successfully" delivered to my Junk folder and 2660 were rejected. WOW! That's really impressive. Before implementing Postscreen I was receiving about 70 spam emails in my Junk folders per day (and this was with greylisting enabled). Before greylisting was enabled I was receiving about 2500 spam emails per week in my Junk folders.

I'll be disabling the following options tomorrow for a week to speed up email delivery:
Code: 
postscreen_bare_newline_enable = yes
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes

I knew these options would cause delays but the delays ranged from five minutes to five hours.

I don't think disabling these options will let much (if any) spam in but the next week will reveal all.
 
You must log in or register to reply here.
Back
Top