Dovecot is an open source IMAP/POP server that runs on either Linux or UNIX systems. Dovecot is suitable for both small and large installations (I just recently installed Dovecot on a 300+ user system) and will work in the background like a workhorse.

In this article I will show you how to install Dovecot and get it up and running with either IMAP or POP quickly and with as little pain as possible.

Installation

Since we are installing on a Ubuntu machine, installing Dovecot is as simple as running the command sudo apt-get install dovecot-common dovecot-imapd dovecot-pop3d. You can actually install either dovecot-imapd or dovecot-pop3d depending upon which protocol you need to support.

Once installed the executable command is /etc/init.d/dovecot start.

Configuration

There is only one configuration file you need to deal with. That file will be located in either /etc/dovecot.conf or /etc/dovecot/dovecot.conf. Believe it or not, the default configuration file is fairly well set up for you. You will only have to make a few modifications. So don’t let the 1,000+ line configuration file look you in the eye and defeat you. You can best this beast with little time.

The first configuration you will need to make is to configure the protocol. Look for the line:

protocols = pop3 pop3s imap imaps

You can just leave this as is, or, if you know you are only using certain protocols, edit to suit your set up. Just remove the protocols you do not need.

The next line you need to look for is:

mail_location =

There are two popular choices here:
mail_location = maildir:~/Maildir # (for maildir)
or
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u # (for mbox)

In other words, if your users’ mailboxes will reside in the home directory, use the former. If the users’ mailboxes will reside in /var/spool/mail, use the latter.

Restart and test

Now restart Dovecot with the command /etc/init.d/dovecot restart and let’s give this system a test. We’ll test this with the help of telnet. Issue the command telent ADDRESS PROTO Where ADDRESS is the address of the server and PROTO is the protocol you want to use (either pop3 or imap). Here’s what the test will look like:
telnet localhost pop3
+OK dovecot ready.
user USER
+OK
pass PASSWORD
+OK Logged in.
list
+OK 1 messages:
1 622

Where USER is a legitimate user on the system and PASSWORD is the password for that user.

If you see the +OK at the end, Dovecot is ready to go. If you have any problems, the best place to look is in /var/log/maillog. And the best way to run that check is by using two terminal windows. In terminal A issue the command tail -f /var/log/maillog and in terminal B run the Dovecot test above. Terminal A should report any issues which will be your starting point for troubleshooting.

Final thoughts

Dovecot really is that easy to install. Of course Dovecot is much more flexible than that. In later articles we will discuss other configuration options for this outstanding server.

In this article you are going to learn how to install Postfix on your already running Ubuntu Server 9.04. I am going to assume you have it networked and have a domain registered that you want to use. At the end of this article you should have a working mail server, ready for use.

NOTE: For the purposes of this article, I will use the fake domain “www.ubuntumail.net”. You will want to use your domain in place of that.

The first step is to install the software necessary. Since you already have LAMP up and running all you will need to do is install Postfix and it’s dependencies. To do this open up a terminal and issue the following command:

sudo apt-get install postfix

The installation will not only install Postfix, but will start the Postfix daemon for you. You will most likely want to test this installation by running the old telnet test like so:

telnet localhost 25

You should see something like:
Trying 127.0.0.1...
Connected to www.ubuntumail.net.
Escape character is '^]'.
220 localhost.localdomain ESMTP Postfix (Ubuntu)

If you do, success! Now you are ready to take care of the configuration steps.

Configuration

There is only one file you need to deal with in Postfix. That file is /etc/postfix/main.cf. There really isn’t much to configuring this file (for a basic installation – which is all we are dealing with right now).

To set your Postfix installation up for your domain you will want to open that file for editing like so:

sudo nano /etc/postfix/main.cf

The above command opens main.cf in the Nano editor. What you need to look for is this section:

myhostname = ubuntumail
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ubuntumail.net, ubuntumail, localhost.localdomain, localhost
relayhost =
#mynetworks = 127.0.0.0/8
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

As you can see, I have already configured the above section to work with our sample domain. You will need to go through the above section and insert your domain where you see ubuntumail.net. You will want to pay close attention to the mydestination line. As you can see that line contains:

ubuntumail.net, ubuntumail, localhost.localdomain

This helps to avoid mailloops in Postfix.

Some people also like to use the mydomain parameter, but since mydomain is taken from $myhostname by removing the first part (unless that would cause the domain to be a top-level domain) it can be redundant. If, however, your mail server serves your entire domain, you will need to use the mydomain parameter. For that you would insert:

mydomain = ubuntumail.net

at the top of the section shown above.

Once you have that configuration saved, restart Postfix with the command:

sudo /etc/init.d/postfix reload

To reload the mail server.

Users

As this is a Linux box, you will want to make sure you have a user created for every email address you need to serve up. So create your users with your favorite user creation tool. Since you are most likely installing on a Ubuntu Server (sans GUI), you will be using the useradd command. You can accomplish this with the command:

sudo useradd -m USERNAME

Where USERNAME is the actual username you want to use. Next you will need to give the user a password with the command:

sudo passwd USERNAME

Where USERNAME is the actual username you want to use. You will be prompted to enter the password twice.

After you have entered the users, you can then test the mail server by sending an email from an external source to see if it arrives. If there is a problem make sure the first place you look is /var/log/mail.err.

Final thoughts

At this point you should have a basic, working mail server. Postfix does make this task much more simple than did Sendmail. In my next article I will cover adding Spamassassin to your Postfix mail server to keep SPAM from getting in.

MTAs (Mail Transfer Agents) can be a tricky lot to set up. Add in to the mix something like relaying and you have all the ingredients for an installation NOT working. Fortunately Postfix isn’t nearly as complicated as Sendmail, so relaying isn’t something you need guru-level access to solve. In this tutorial I am going to show you how to set up Postfix for easy relaying. You can always add this to the Ubuntu Server series that started with the article “Installing Ubuntu Server 9.04“.

Installing Postfix

Just in case you haven’t already, you can install Postfix on your already running Ubuntu Server install with the command:

sudo apt-get install postfix

But I am going to assume you already have Postfix up and running already. And if you’re looking into relaying with Postfix, your problem is that you can receive mail, you just can’t send it. Let’s fix that problem.

Configure Postfix

The file you need to first take care of is /etc/postfix/main.cf. You will need sudo access so open this file with the command:

sudo nano /etc/postfix/main.cf

Now add this to the bottom of that file:

# SMTP Authentication
smtp_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd

NOTE: The portion starting with “smtpd_recipient_restrictions” and ending with “reject_unauth_destination” is actually one line.

NOTE: The portion starting with “reject_unauth” and ending with “sasl_passwd” is also only one line.

NOTE: The above assumes you are using Dovecot as your IMAP server.

The last line of the above should give you a hint as to what is next. Yes, you have to create a file, sasl_passwd, for Postfix to use as a password file. This file will be located in /etc/postfix/sasl/ and will look like the following:

address.for.relaying   username:password

Where:

• address.for.relaying is the actual mail server you will use for relaying.
• username is the username for authentication on the relaying mail server.
• password is the password for authentication on the relaying mail server.

The next step is to create the the sasl_passwd DB file so that Postfix has something it can read. To do this, issue the command:

sudo postmap hash:/etc/postfix/sasl/sasl_passwd

You should now see a new file in the /etc/postfix/sasl directory called sasl_passwd.db.

One file step before restarting Postfix. Because the password file is plaintext it should be secured so that it can not be read by just any user. Say, for instance, you want Postfix to only be read by the root user. For this issue the command:

sudo chown root:root /etc/postfix/sasl/sasl_passwd && chmod 600 /etc/postfix/sasl/sasl_passwd

Do the same thing with the sasl_passwd.db file like so:

sudo chown root:root /etc/postfix/sasl/sasl_passwd.db && chmod 600 /etc/postfix/sasl/sasl_passwd.db

NOTE: If you have need for a different user, you can chown the file to whatever user you want…just make sure it is a secure user.

You’re finished. All that is left is to restart Postfix with the command:

sudo /etc/init.d/postfix restart

Open up your mail client and text to see if relaying is now working for you.

Final thoughts

Gone are the days of the overly complicated (and insecure) Sendmail configurations. Setting up relaying is simple when you are using Postfix.

In this article I will give you a step by step setup for getting Sendmail to accept email from outside of localhost and your own LAN. This will require you to manually edit some configuration files and you will need root access (or sudo access) in order to do this.

In order for this to work I am going to assume you have your own domain name. For the sake of this article we’ll illustrate with the sample domain www.sampledomain.com. I will also assume this FQDN is working properly and you have Sendmail already installed and starts properly. The operating system I am using for this example is Ubuntu Server 8.10. With that in mind, let’s get to this.

/etc/mail

All of the configurations you will be doing will be within the /etc/mail directory. In this directory you will be modifying the following:

• sendmail.cf
• sendmail.mc
• access
• local-host-names

Once all of the modifications are made you will then restart Sendmail.

sendmail.mc

By default Sendmail is setup to only accept mail from localhost. This is the first change that needs to be made. This change is made in the sendmail.mc file. What you are looking for is the following line:

DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Addr=127.0.0.1, Port=smtp')dnl

The line needs to be altered to look like:

DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Port=smtp')dnl

The Addr=127.0.0.1 section instructs Sendmail to only accept email from localhost.

Now you need to add these changes to the sendmail.cf file by issuing the command:

sudo make -C /etc/mail

This will add your changes. The reason I use sendmail.mc for these options is that configuring the DAEMON_OPTIONS is a bit confusing and hard to find. The other options are quite easy to add directly to sendmail.cf.

sendmail.cf

The options you will want to add in this file are for setting your domain name.  The first option is under the “my official domain name” heading. What you will see in the example is:

#Dj$w.Foo.Com

replace this with (and remember we’re using our sample domain):

Djsampledomain.com

The next option will be set for masquerading. In some recent Sendmail releases this is not in the cf by default. Take a look for the quoting section that looks like:

# dequoting map
Kdequote dequote
# class E: names that should be exposed as from this host, even if we masquerade
# class L: names that should be delivered locally, even if we have a relay
# class M: domains that should be converted to $M
# class N: domains that should not be converted to $M
#CL root

At the bottom of this add:

# who I masquerade as (null for no masquerading) (see also $=M)
DMsampledomain.com

Now you are done with the sendmail.cf file.

access

This file defines access control to your mail server. For our sample we will add the following to the bottom of this file:

sampledomain.com
www.sampledomain.com
mail.sampledomain.com

Save that file and you have one more configuration to take care of.

local-host-names

This file will define the host names associated with your Sendmail server. In this file we will add:

sampledomain.com
mail.sampledomain.com

Restart Sendmail

It is now time to restart Sendmail. Do this with the command:

/etc/init.d/sendmail reload

Once sendmail restarts you should be accepting email from the outside world. Run a test with an email address outside of your domain.

Final thoughts

Sendmail isn’t really as difficult as it is made out to be. With this simple walkthrough you should have Sendmail accepting mail from all over quickly and easily.

By employing Spamassassin you can set up an outstanding SPAM  filter system that will protect your users. It’s not as simple as double clicking an .exe file to install, but the end results will be worth the time and effort.

Installing the tool

This portion of the task is simple. Open up your Add/Remove utility, do a search for “spamassassin” (no quotes), select the results, and apply the changes. After you have installed the package you need to take a few steps to finish up the installation.

Now you are going to need a local.rc file. You can open up the /etc/mail/spamassassin/local.rc file for hand editing, or you can use this handy web-based tool to set it up for you. This tool was written by Michael Moncur and makes the setup of Spamassassin much easier. Once you have selected all your options click the Generate button and then click the Download button. You will need to place this file in /etc/mail/spamassassin in order for it to be used.

It’s time to start the daemon. Issue the command /etc/init.d/spamassassin start (or /etc/rc.d/init.d/spamassassin start – depending upon your distribution.)

Test the install

Spamassassin comes with a sample file you can run through the filter for testing. In modern installations this file is located in /usr/share/doc/spamassassin-*/sample-spam.txt. To test this issue the command:

spamc -R </usr/share/doc/spamassassin-3.2.5/sample-spam.txt

You should see results like this:

Content analysis details:   (1000.0 points, 5.0 required)

pts rule name              description
—- ———————- ————————————————–
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
1000 GTUBE                  BODY: Generic Test for Unsolicited Bulk Email
-0.0 NO_RECEIVED            Informational: message has no Received headers

As you can see, this sample scored 1000 points. Only 5 points are required for an email to be considered SPAM. It’s safe to say this is SPAM and safe to say Spamassassin is working.

Using Spamassassin with Procmail

You will need to set up Procmail (or another MTA) in order to deliver mail. What we want to do is set this up globally so you don’t have to deal with each users ~/.procmailrc file. To do this you will edit the /etc/procmailrc file. All you need to do is add the following lines:

DROPPRIVS=yes

:0fw

| /usr/bin/spamc

Spamassassin should now be working.

Training spamassassin

At first you might not notice much of a drop in SPAM. This is because Spamassassin has to have a period of training.  There is a built-in tool for this called sa-learn. What you need to do is create two folders, one for SPAM and one for HAM. In the SPAM folder collect 100 or so emails that are definately SPAM. In the HAM folder collect 100 or so valid emails. Once you have those folders collected issue the following commands:

sa-learn –spam /PATH/TO/SPAM/FOLDER

sa-learn –ham /PATH/TO/HAM/FOLDER

Where /PATH/TO/SPAM/FOLDER and /PATH/TO/HAM/FOLDER are the explicit paths to these folders.

You can also set up a cron job to help Spamassassin train frequently if you need.

Final Thoughts

If SPAM is clogging up your Linux mail server you will be wise to employ a tool like Spamassassin. Your users and your IT staff will thank you for it.

A second application would be to fight spam before it is retrieved and downloaded to a local PC. Pal Mail is a tiny secure application that can retrieve the mail headers of an unlimited number of accounts with the main option to delete mails right on the mail server. Retrieved are the mail headers and the messages but not the attachments of the mails.

Every mail can be marked for deletion which effectively deleted it from the mails server. The consequence is that your primary mail client will not retrieve the messages that have been deleted before.

Pal Mail is a standalone application that does not require any dlls or other files to run. This makes it an idea software for a portable device.