So let's start the installation by getting the needed software. You will notice that below I create a new directory called /downloads and I place the Qmailrocks tarball in that directory before unpacking it. I would strongly reccomend you do this as the rest of the instructions on this site are geared toward this source directory structure. Anyway, lets get down to business.
mkdir /downloads
cd /downloads
Now download the Qmailrocks.org software bundle. The command below will download the bundle from the qmailrocks.org main server in Texas, USA. You can also download the bundle from a qmailrocks mirror site, if you wish)
wget http://www.qmailrocks.org/downloads/qmailrocks.tar.gz
(Alternatively, if you'd like to download individual packages or view a listing of all the packages, you may do so right here.)
Once you've downloaded qmailrocks.tar.gz, were going to place in a directory called "downloads" and then unpack it...
tar zxvf qmailrocks.tar.gz
Now that you've downloaded all the needed packages, we can start the install. At this point you should have a qmailrocks source directory located at /downloads/qmailrocks. If you don't, go back to step 1. This step involves the setup of the very heart of you new qmail server. In this step, we'll install qmail itself, ucspi-tcp and daemontools. These 3 packages are the core of the qmail server and will be the foundation on which we build everything else. So don't screw it up!
(RH 9/RHEL/Fedora/Slackware users: click here before you start.)
To start things off, I've created a handy little shell script that takes care of the first portion of getting qmail, ucspi-tcp and daemontools intalled. Simply run this script from the command prompt of your Solaris box and you should be golden. The script will tell you what it's doing along the way.
/downloads/qmailrocks/scripts/install/qmr_install_linux-s1.script (click here to view this script)
If all goes well, you should have all the needed user and groups created as well as all the needed directories, permissions and ownership settings needed for the installation of qmail, ucspi-tcp and daemontools
Before we start to compile and install qmail, ucspi-tcp and daemontools, we're going to apply a group of patches to qmail. These patches will build all sorts of cool functionality directly into qmail before we install it. In total, we're going to add around 15 patches, but fortunately John Simpson has combined all but one of these patches into one giant patch file. But it gets even easier because I've thrown together a shell script that applies ALL the patches in one quick step. I'm making this so easy for you it's almost sickening. :)
Here's the basic gist of these patches: All critical patches included in this bundle will be automatically integrated in your qmail server's functioning. However, there are a few non-critical patches that have to be configured in order to work. These non-critical patches are included merely to give you a few extra little goodies that you can play with on your own time. Some of these "extra little goodies" are new to me too, so as I learn more about them I will certainly go into more detail.
So that you're not completely ignorant as to what theses patches are going to be doing to your qmail server, here's a quick list of what patches are included. I have color coded these patches so that you will know which ones are critical and which ones are not.
red patch = critical patch, as far as the QMR install is concerned, that is automatically integrated into your qmail server and requires no additional work on your part.
blue patch = a non-critical patch that merely adds some cool functionality. Blue asterisk patches also will be automatically integrated and require no additional work.
green patch = a non-critical patch that merely add some cool functionality, but which needs to be configured in order to be active.
maxrcpt patch - Allows the sysadmin to set limits a message's number of recipients. The default for this patch is set to 100. mfcheck patch - causes qmail-smtpd to reject messages where the domain portion of the envelope sender is not a valid domain quota patch - Turns "over quota" errors into HARD errors, not soft. A wake up call for those 2 or 3 jackasses on your server who never check their mail. date-localtime patch - causes qmail to use the local timezone in any headers it generates. qmailqueue - the classic patch that allows qmail-smtpd to call other programs to process messages. Through qmailqueue, we will later tie in Clam Antivirus and Spamassassin. However, many ofther programs can also be tied in if you so desire. jms1-antispam patch - An anti-spam patch created by John Simpson, which works within qmail-scanner to trick spam servers into believing a spam message is delivered, when in fact it isn't. This is inactive by default, but you can play around with this if you want. errno.patch - patches error.h to work correctly with libc-2.3, which is used by RedHat 9 and a few other Linux distributions smtp-auth patch - good old smtp authentication STARTTLS/AUTH patch - patch from qmail.org, modified by John Simpson to not advertise AUTH unless the command line elements are there, AND adding a check to not advertise or support AUTH unless the connection is secure. forcetls patch - a patch created by Ryan Schlesinger to compensate for mail clients that do not support TLS. Using this patch, your qmail server will always accept an smtp connection encrypted with TLS. However, if any of your users have a mail client that does NOT support TLS, they will still be able to connect with just a plain AUTH connection. This is the default setting that this patch installs with. However, if you're a security nazi, this patch allows you to set your server so it will REQUIRE a TLS smtp connection no matter what. This patch simply gives you some flexibility with your TLS enabled qmail server. The SPF patch - adds SPF checking to qmail-smtpd. SPF is a system where the owners of domain names can "publish" the list of IP addresses from which their users send mail. If another mail server sees an incoming message claiming to be "From" that domain, but not coming from an IP on their SPF list, that server can reliably reject the message as spam. More info can be found here. qmail-0.0.0.0 patch - fixes a difference between how Linux interprets the IP address "0.0.0.0" and how the *BSD systems handle it. According to RFC 1122, the IP address 0.0.0.0 should always be treated as an address for "this host, this network". Part of qmail's loop-detection logic is determining whether or not a given IP address "is" the current machine. This patch "teaches" qmail that 0.0.0.0 is always the local machine. qmail_local patch - fixes a possible bug in qmail-local having to do with how the first line of a .qmail file is interpreted, when it starts with whitespace. sendmail-flagf patch - fixes how the "-f" option to /var/qmail/bin/sendmail is handled, so that it more closely matches how the original "sendmail" program's "-f" option worked. bind-interface patch - a patch that lets you control the "source IP" from which outgoing connections appear from a machine with multiple IP addresses. This page on qmail.org describes the patch more clearly, as well as the format of the /var/qmail/control/bindroutes file which it uses. 8k-buffer-patch - increases the size of the memory buffer that qmail uses when querying the system for a list of all local IP addresses. |
Ok, so enough talk. Let's apply these mega-patches and get this patching business out of the way...
/downloads/qmailrocks/scripts/util/qmail_big_patches.script (click here to view this script)
Now we build Qmail...
cd /usr/src/qmail/qmail-1.03
make man && make setup check
./config-fast your_fqdn_hostname (ex: ./config-fast mail.mydomain.com)
OK, qmail itself is now built and installed. Now let's generate a secure certificate that will be used to encrypt your server's TLS encrypted SMTP sessions...
make cert
When you run the above command you will be asked a series of questions regarding the generation of your certificate. They are non-technical questions...such as your location, business name, organaization name, common name and so forth. If you've ever generated an SSL cert before, this should be familiar stuff to you. If you haven't, simply follow the directions. It's easy. If you have trouble following the directions, you might as well give up now because you're a RETARD. Since the cert you are generating is already NOT from a trusted authority such as Verisign or Thawte, the information you provide here is not really THAT important, so don't sweat it.
Here's a sample of my cert cert configs. Don't be an idiot. Substitute in your own information.
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Georgia
Locality Name (eg, city) [Newbury]:Atlanta
Organization Name (eg, company) [My Company Ltd]:qmailrocks.org
Organizational Unit Name (eg, section) []:mail
Common Name (eg, your name or your server's hostname) []:mail.qmailrocks.org
Email Address []:postmaster@thisdomain.org
If the cert is successfully generated it will be automatically installed at /var/qmail/control/servercert.pem, along with a symlink to that cert at /var/qmail/control/clientcert.pem
Now we set the right ownership for the newly create cert...
chown -R vpopmail:qmail /var/qmail/control/clientcert.pem /var/qmail/control/servercert.pem
Now we build ucspi-tcp...
cd /usr/src/qmail/ucspi-tcp-0.88/
RH 9/RHEL/Fedora/Slackware users: You will need to patch ucspi-tcp with an additional errno patch: patch < /downloads/qmailrocks/patches/ucspi-tcp-0.88.errno.patch |
make && make setup check
If you don't get any errors, that's it for ucspi-tcp!
Now we build the daemontools....
cd /package/admin/daemontools-0.76
RH 9/RHEL/Fedora/Slackware users:You will need to patch daemontools with an additional errno patch: cd /package/admin/daemontools-0.76/src patch < /downloads/qmailrocks/patches/daemontools-0.76.errno.patch cd /package/admin/daemontools-0.76 |
package/install
If no errors are reported, you've successfully compiled the daemontools package!
All done for now...
If you run take a look at the running processes on your server at this point, you should see the daemon "svscanboot" running. You can usually do this with a "ps -aux" command. Here's a screenshot of it. If you see "svscanboot" running, you're in good shape.
OK, Qmail is almost totally installed but we're going to pause right here and install a bunch of handy tools and features that will make Qmail pretty and fun! After that, we'll make some final changes to Qmail and then crank it up!
Vpopmail is one of the major components of this installation. Vpopmail allows us to do virtual domain mail hosting. It's got a lot of built in tools and features that make it a dream to work with. Even if you don't want to host mail for multiple domains, I would still recommend installing Vpopmail. It just makes the whole mail game easier. Plus, my installation centers around it, so if you don't install it you're going to have a headache.
So let's install it...
cd /downloads/qmailrocks
tar zxvf vpopmail-5.4.13.tar.gz
cd vpopmail-5.4.13
- Helpful Hint: Vpopmail configuration options - The vpopmail "configure" command can have loads of options. Use "./configure --help" to see them all. In the syntax used in this installation, I specify to the type of logging that I want vpopmail to use. Vpopmail logs its activities to the server's syslog and there are several options you can use. I've used the "p" option, but feel free to adjust it to your needs. Here's are the details: --enable-logging=n - logs nothing --enable-logging=e - logs only errors (default) --enable-logging=y - logs all attempts --enable-logging=p - logs errors with passwords --enable-logging=v - verbose. Logs all attempts with passwords |
Now let's configure vpopmail...
./configure --enable-logging=p
make && make install-strip
If you don't get any errors, then Vpopmail is good to go!
Wait! I'm getting an error! What do I do? If you are using GCC version 3.x, you may get a compilation error similar to this: In file included from vconvert.c:35: If you get this error, you will need to apply a patch to Vpopmail: patch < /downloads/qmailrocks/patches/vmysql.patch Once you've applied the patch, try running "make" and "make install" again and you should be ok. |
Vqadmin is simply a nice web based interface that will let us manage Vpopmail. Through the interface we can create new domains, new users, net quotas, enable services and much more.
So let's install it...
cd /downloads/qmailrocks
tar zxvf vqadmin-2.3.6.tar.gz
cd vqadmin-2.3.6
./configure --enable-cgibindir=/path/to/your/cgi-bin --enable-htmldir=/path/to/your/html/directory
(Example: ./configure --enable-cgibindir=/var/www/cgi-bin --enable-htmldir=/var/www/html )
make && make install-strip
If the installation is successfull, Vqadmin should install itself in the cgi-bin directory of your default website. Unless you tell it otherwise, that usually defaults to /var/www/cgi-bin. You can specify another location in the ./configure command above.
Now you will need to add the following to your server's Apache configuration file (usually httpd.conf)
deny from all
Options ExecCGI
AllowOverride AuthConfig
Order deny,allow
In addition, within the Apache master config file you will want to set the "AllowOveride" option to "All". Example: AllowOverride All
cd /path/to/your/cgi-bin/vqadmin
Now you will want to create a .htaccess file to password protect the Vqadmin interface. There should already be a .htaccess file in the vqadmin directory, so all you need to do is configure it. We'll use the ever useful vi editor for this.
vi .htaccess
AuthType Basic
AuthUserFile /path/to/where/you/want/to/store/the/password/file/.htpasswd
AuthName vQadmin
require valid-user
satisfy any
chown apache .htaccess (you may need to change the chown to either "nobody", "apache" or "www" etc., depending on what user your installation of Apache is running as)
chmod 644 .htaccess
Now you need to create a corresponding .htpasswd file that's going to contain the username and encrypted password for the Vqadmin administrator...
htpasswd -bc /path/to/where/you/want/to/store/the/password/file/.htpasswd admin admin_password
chmod 644 /path/to/where/you/want/to/store/the/password/file/.htpasswd
Now restart Apache...
apachectl stop
apachectl start
If all has gone well, you should now be able to browse (in your web browser) to:
http://www.yourdomain.com/cgi-bin/vqadmin/vqadmin.cgi
Note: make sure you include "vqadmin.cgi" in the path or you will get a 403 forbidden error!
Enter the user "admin" and whatever password your assigned it.
You should now see the Vqadmin interface. Go ahead and add a new domain to your server! Pretty cool, huh? The "postmaster" user serves as the admin user for any new domain and we will use it to log into Qmailadmin, when we install that. As soon as we complete the install, that domain will be instantly able to get mail (assuming the MX is correctly pointing to your server). The nice thing about Vpopmail and Vqadmin is that you do not need to restart anything after you add a domain. Once you add it, it simply works! We're almost done!
Qmailadmin is going to provide us with a nice web based interface for administering mail accounts once they are setup through Vpopmail (or Vqadmin). From Qmailadmin we can create mailboxes, aliases, fowards, mail robots, mailing lists. You'll also find a few other handy functions as well. Qmailadmin is sort of the icing on the Qmail cake. Let's install it... |
cd /downloads/qmailrocks
tar zxvf qmailadmin-1.2.9.tar.gz
cd qmailadmin-1.2.9
./configure --enable-cgibindir=/path/to/your/cgi-bin --enable-htmldir=/path/to/your/html/directory
note: The paths in the above configure script will need to be custom tailored to your systems configuration
make && make install-strip
That's it! Now browse to http://www.yourdomain.com/cgi-bin/qmailadmin and you should see the login screen. Login with the postmaster account and password for the domain that you created a while back using Vqadmin. Pretty cool, isn't it? Go ahead and create some additional mailboxes for your domain(s).
If you didn't get any errors, Qmailadmin should be all set!
Ok, we've installed a bunch of bells of whistles onto our qmail installation. Now it's time to wrap up the configuration for qmail itself. After that, we will stop and remove Sendmail from the server and then it's time to crank qmail up!
The first thing we're going to do is create the qmail supervise scripts, create the the qmail rc and qmailctl scripts and then set the needed permissions on all these scripts. Lucky for you, I've created a script to do all this for you. The script will give you a breakdown of what it is doing while it's running. If any errors occur, you'll see them. However, if you've configured everything right up until now, you shouldn't have any problems. You can check out the contents of this scripts right here.
So let's run the script...
/downloads/qmailrocks/scripts/finalize/linux/finalize_linux.script
Hey, that was easy. Now there are just a couple tweaks to make to these new scripts we just created...
vi /var/qmail/supervise/qmail-pop3d/run
Find "mail.example.com" and change it to your server's hostname. For example: mail.mydomain.com.
vi /var/qmail/supervise/qmail-smtpd/run
Find "mail.example.com" and change it to your server's hostname. For example: mail.mydomain.com
Next, we'll kill any running qmail processes so that we can implement some final configurations.
qmailctl stop
We setup selective relaying for localhost...
echo '127.:allow,RELAYCLIENT=""' >> /etc/tcp.smtp
qmailctl cdb
Now we create the common system aliases. These aliases are going to tell Qmail what to do with common server-generated mails. Stuff like bouncebacks, cron daily output and various other systemic sources. It's a good idea to redirect these aliases to a mailbox that you are going to check on a regular basis. You don't want to have your systemic mails piling up in some deep dark corner of your server doing no good and slowly filling your disk up.
echo some_address > /var/qmail/alias/.qmail-root
where "some_address" is the system user or email address you want these addresses aliased to.
echo some_address > /var/qmail/alias/.qmail-postmaster
where "some_address" is the system user or email address you want these addresses aliased to.
echo some_address > /var/qmail/alias/.qmail-mailer-daemon
where "some_address" is the system user or email address you want these addresses aliased to.
ln -s /var/qmail/alias/.qmail-root /var/qmail/alias/.qmail-anonymous
chmod 644 /var/qmail/alias/.qmail*
Alright. We've got qmail ready to go. One of the last things we need to do is to disable/uninstall Sendmail on the server and replace the Sendmail binary with a symlink to qmail, so that our server won't freak out with Sendmail being gone.
Well, the moment you've been waiting for is finally here. We're going to uninstall the current MTA from the server. On some systems, this means removing Sendmail while on many systems it involves removing Postfix (another popular MTA). Either way, we're going to remove the current MTA and replace it with our new qmail installation. However, since Sendmail (or rather the path to Sendmail) is such a commonly used item among tons of server operations and cronjobs, you will see that, after we uninstall Sendmail, we will actually make an artificial Sendmail that is nothing more than a direct injection into Qmail.
Anyway, let's do it...
Since this installation concerns Redhat, I'm going to assume that either have Sendmail or Postfix installed as an RPM. If you have it installed from source instead, we'll cover that as well.
Removing Sendmail
First, you'll want to check and see if your Sendmail installation is an RPM installation or a source installation. A good way to tell, of couse, is to simply ask....
rpm -qa | grep sendmail
If Sendmail is installed as an RPM, you will see an output similar to this:
sendmail-x.x.x.x
sendmail-doc-x.x.x.x
sendmail-devel-x.x.x.x
sendmail-cf-x.x.x.x
If it's installed as an RPM, you can uninstall Sendmail quite easily by running the followinng commands:
/etc/rc.d/init.d/sendmail stop (to stop Sendmail)
rpm -e --nodeps sendmail-x.x.x.x
rpm -e --nodeps sendmail-doc-x.x.x.x
rpm -e --nodeps sendmail-devel-x.x.x.x
rpm -e --nodeps sendmail-cf-x.x.x.x
That's it! Sendmail is gone! Keep in mind that if you had an rpm installation and you ever want to return to Sendmail, you can simple install the RPMs again with no trouble (assuming you remove Qmail).
However, if the RPM query produces no output, you most likely have a source install of Sendmail. In that case...
/etc/rc.d/init.d/sendmail stop (to stop Sendmail)
mv /usr/lib/sendmail /usr/lib/sendmail.old
mv /usr/sbin/sendmail /usr/sbin/sendmail.old
chmod 0 /usr/lib/sendmail.old /usr/sbin/sendmail.old
Removing Postfix
First, let's see if you actually have Postfix installed...
rpm -qa | grep postfix
If it's installed, you'll get an output similar to this:
postfix-x.x-x
So let's remove it...
/etc/rc.d/init.d/postfix stop
rpm -e --nodeps postfix-x.x-x
Establishing an "artificial" Sendmail path
Now we will need to set up an "artificial" Sendmail, which is just a symbolic link to Qmail's Sendmail. This is needed to ensure that the myriad of systemic mail scripts are still able to send mail! Qmail's "Sendmail" is nothing more than a direct injection into Qmail itself...
ln -s /var/qmail/bin/sendmail /usr/lib/sendmail
ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail
That's it! If all has gone well, Sendmail or Postfix should be uninstalled and the Qmail Sendmail should be in its place.
Now it's time to give qmail a final test and then crank it up!
Alright, qmail should be ready to go! But before we crank it up, let's run a script that will check the key components of the installation and make sure everything is alright.
To do this test, I have borrowed Dave Sill's "inst_check" script, but I've made a few custom modifications to accomodate for the subtle differences between the Qmailrocks installation and the Life With Qmail installation. Basically, the Qmailrocks installation has a slightly different logging setup and some slight variations in permissions settings. If you've installed according to this site, use my version of the script, as using Dave's version will result in a lot of "error" detections that are false positives due to the differences in the 2 installs. When you run the script, it will check for some key required files and folders and will also check permissions and owership settings on many key items. It a needed file does not exist or if the ownership/permissions settings are wrong on a key file, it will tell you and then make a suggestion as to how to correct the error. This script does NOT check the CONTENT or SYNTAX of your scripts, but only for the scripts' existence and their ownership/permissions settings. If you've screwed up the syntax of on the run scripts, this tool will not detect it. So you ready? Let's do it...
/downloads/qmailrocks/scripts/util/qmr_inst_check
If you get a "congratulations" type of message, you're all set. If you get some errors, just follow the directions to fix the errors and then re-run the script until you get all errors corrected and you get a "congratulations" message.
Assuming, you've passed the installation check script, let's crank Qmail up!
qmailctl stop
qmailctl start
You can find out how things are running by:
qmailctl stat
You should see an output like this:
/service/qmail-send: up (pid 29956) 2 seconds
/service/qmail-send/log: up (pid 29960) 2 seconds
/service/qmail-smtpd: up (pid 29963) 2 seconds
/service/qmail-smtpd/log: up (pid 29968) 2 seconds
/service/qmail-pop3d: up (pid 29971) 2 seconds
/service/qmail-pop3d/log: up (pid 29972) 2 seconds
messages in queue: 0
messages in queue but not yet preprocessed: 0
If you, don't see anything like that or if you see error messages, click here for troubleshooting tips.
Congratulations, Qmail is now officially up and running and you should be able to send and receive mail on the server.
Let's test your new server's POP3 service...
telnet localhost 110
you should see something like this:
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
+OK <16658.1054485137@yourserver.com>
user postmaster@mydomain.com (enter your username here. remember to use the full e-mail address)
+OK
pass your_password
+OK
quit
+OK
Connection closed by foreign host.
This is the sign of a successfull POP connection to the server!
Now try sending mail to that same user from another location. Telnet to 110 again and run the "list" command and you should see the message that your send...
telnet localhost 110
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
+OK <16658.1054485137@yourserver.comt>
user postmaster@mydomain.com (again, remember to log in with the full email address of the user)
+OK
pass your_password
+OK
list
+OK
1 323 (there's your message!)
.
quit
+OK
Connection closed by foreign host.
And now let's test your server's SMTP service to make sure the TLS functionaltiy is there...
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 somewhere.anywhere.com ESMTP
ehlo localhost
250-somewhere.anywhere.com
250-AUTH LOGIN CRAM-MD5 PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250-PIPELINING
250 8BITMIME
starttls
220 ready for tls
quit
quit
Connection closed by foreign host.
[root@somewhere control]#
In the above SMTP session, I have higlighted the important aspects in DARK RED. After you give the server the initial "ehlo localhost" command, you should get a response back that lists "250-STARTTLS", signaling that the server is in fact equipped for TLS functionality. Then, after you issue the "starttls" command, you should get the :"220 ready for tls" response if the server is able to successfully start the TLS session.
If you happen to get an error that states "454 TLS not available: missing RSA private key (#4.3.0)" after you issue the "starttls" command, you will want to check 2 things: 1) Verify that the cert actually exists at /var/qmail/control/servercert.pem. If it's not there, go back to step 2 and repeat the cert creation step. 2) Verify that the cert is owned by vpopmail:qmail. If it's not, then make it so like this: chown vpopmail:qmail /var/qmail/control/servercert.pem |
Alright! If you have reached this point, then Qmail is now successfully up and running. Technically speaking, you could quit right here and have a functioning mail server. However, we still have a few options that we're going to plug into Qmail before we're done. In the next pages we will:
Install Courier IMAP & IMAP SSL.
Install Squirrelmail web based mail interface (requires that IMAP be installed).
Install Qmail-Scanner, an alternative queueing device.
Install Spamassassin, to tag all incoming spam.
Install Clam Anti Virus - To quarantine e-mails containing known viruses
Install qmailanalog, so that you can get nightly server stats.
Install Qtrap, to filter out messages containing undesirable words that may make it past Spamassassin.
Now that you have qmail up and running, we're going to add a few extras onto it. For starters, we're going to install Courier-imap/imaps along with Courierpassd. We will also be installed the Courier-authlib package to enable proper authentication through courier-imap. Installing IMAP will, obviously, enable IMAP connections to the mail server and it is a necessary ingredient for most popular web based mail clients such as Horde, SQwebmail and Squirrelmail. Courier-imap is the preferred IMAP server to install because it has built in support the vchkpw mail user setup that Vpopmail utilizes. In short, Courier IMAP works with Vpopmail and virtual domains. In addition to installing Courier-imap, we're going to install Courierpassd. Courierpassd is a utility that allows users to change their mailbox passwords remotely. This will come in handy when we install Squirrelmail in the next step of the installation. Courierpassd will allow your mail users to change their passwords using the Squirrelmail interface. This will give your users more power over their account settings and, more importantly, keep them from pestering you whenever they want to change their passwords. Keep in mind that when we get to compiling courier-imap, it will have to be compiled by a NON-ROOT USER.
So let's start by installing courier-authlib...
cd /downloads/qmailrocks/
tar jxvf courier-authlib-0.55.tar.bz2
cd courier-authlib-0.55
./configure --prefix=/usr/local --exec-prefix=/usr/local --with-authvchkpw --without-authldap --without-authmysql --disable-root-check --with-ssl --with-authchangepwdir=/usr/local/libexec/authlib --with-redhat
make && make check
make install-strip && make install-configure
Now we will add a startup command for authedaemond to the /etc/rc.local file to ensure startup on boot...
vi /etc/rc.local
Add the following line:
/usr/local/sbin/authdaemond start
Now let's install courier-imap/imaps...
Remember, courier imap needs to be compiled by a NON-ROOT USER. For the purposes of this guide, I am going to use a NON ROOT user called bsmith. Anyone who doesn't read this and asks me who "bsmith" is will be smacked across the head.
cd /downloads/qmailrocks/
tar jxvf courier-imap-4.0.2.tar.bz2
chown -R bsmith:wheel courier-imap-4.0.2
cd /downloads/qmailrocks/courier-imap-4.0.2
su bsmith
./configure --prefix=/usr/local --exec-prefix=/usr/local --with-authvchkpw --without-authldap --without-authmysql --disable-root-check --with-ssl --with-authchangepwdir=/usr/local/libexec/authlib --with-redhat
Note: the configure process will take a few minutes. Go grab a snack...
make && make check
Now we will exit out of our NON-ROOT USER and go back to being root...
exit
make install-strip && make install-configure
Now let's create an SSL certificate for the IMAP-SSL server...
/usr/local/sbin/mkimapdcert
This will start and automated process that creates a self-signed imap-ssl X.509 certificate called imapd.pem. It should create this new certificate at /usr/local/share/imapd.pem. If the certificate already exists, the "mkimapdcert" tool will not let you overwrite it.
A Note on IMAP-SSL certificates: Keep in mind that since this SSL certificate is self-signed and is not from a "trusted" authority such as Verisign or Thawte, mail clients such as Outlook will give a warning when they attempt to connect to your IMAP-SSL server on port 993. The warning will state that the certificate is not from a "trusted" authority. While the warning is a bit ugly, it does NOT mean your IMAP-SSL connection is any less secure than it would be with a real certificate from Verisign or Thawte. All it means is that the SSL certificate was not generated by a company which Microsoft recognizes as a "trusted" authority. From a security standpoint, however, your IMAP-SSL server is every bit as secure as it would be if you bought the certificate from Verisign or Thawte. If the warning is too inconvenient for your purposes, you will need to purchase a "real" certificate from a "trusted" authority such as Verisign or Thawte. Be prepared to shell out a good chunk of change if you do so.
vi /usr/local/etc/imapd.cnf
change postmaser@example.com an administrative email address
Save and exit
vi /usr/local/etc/imapd
Make sure that the following configuration exists: IMAPDSTART=YES
vi /usr/local/etc/imapd-ssl
Make sure that the following configuration exists: IMAPDSSLSTART=YES
Make sure that the following configuration exists: TLS_CERTFILE=/usr/local/share/imapd.pem
Save and exit the file.
Special note for people running a small home or office network: If you are planning on having multiple users connect to your IMAP server from a single IP address, such as in a small home or office network, you may want to increase the "MAXPERIP" setting with the /usr/local/etc/imapd config file. This setting establishes the maximum number of IMAP connections that can be made from a single IP address. An example of this might be if you have a small office network runing on a single DSL or Cable IP address and your mail server is outside of that network. While each computer in your internal network may have it's own private IP address, to the outside world anyone coming from your network has the single routeable IP address assigned to your DSL or Cable connection. The default setting for "MAXPERIP" is 4 so f you have a similar network setup and more than 4 people trying to access your IMAP server, you may want to increase this setting accordingly to avoid connection errors. Within the /usr/local/etc/imapd file, the line you are looking for looks like this: MAXPERIP=4 |
vi /usr/local/etc/authlib/authdaemonrc
Around like 27, you should see the "authmodulelist" setting. Make sure that "authvchkpw" is the only module listed. Like so:
authmodulelist="authvchkpw"
Save and exit the file.
Now we create the startup scripts...
cp /usr/local/libexec/imapd.rc /etc/rc.d/init.d/imap
cp /usr/local/libexec/imapd-ssl.rc /etc/rc.d/init.d/imaps
Now let's start up Authdaemond, IMAP and IMAPS. To be safe we'll stop each service before starting it...
/usr/local/sbin/authdaemond stop
/usr/local/sbin/authdaemond start
/etc/rc.d/init.d/imap stop
/etc/rc.d/init.d/imaps stop
/etc/rc.d/init.d/imap start
/etc/rc.d/init.d/imaps start
If you run "nmap localhost", you should see both 143 and 993 now open and listening.
Now let's test it...
telnet localhost 143
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE STARTTLS] Courier-IMAP ready. Copyright 1998-2003 Double Precision, Inc. See COPYING for distribution information.
a login postmaster@mydomain.com my_password
a OK LOGIN Ok. (successful login!)
a logout (logs you out)
* BYE Courier-IMAP server shutting down
a OK LOGOUT completed
Connection closed by foreign host.
Hint: The "a" that you see before my login commands is required.
If you were able to log in , as in the example above, you're all set. IMAP is installed! For further testing, you can configure a mail client such as Outlook to test both the IMAP and IMAP-SSL connetion to your server. IMAPS runs on port 993.
Now that Couroier-imap is installed, let's install Courierpassd. Remember, Courierpassd is going allow us to enable your mail users to change their own mail passwords via the Squirrelmail interface.
Note: Courierpassd will require that port 106 be open to at least local traffic (traffic from 127.0.0.1)
cd /downloads/qmailrocks
tar zxvf courierpassd-1.1.0-RC1.tar.gz
cd courierpassd-1.1.0-RC1
./configure
make && make install
OK. Courierpassd is installed now. Next, we are going to configure Xinetd/Inetd to run courierpassd. Most Redhat installations use Xinetd, but I've included Inetd directions just in case
If your server uses Xinetd, here's how you integrate Courierpassd into it: cd /etc/xinetd.d Here we create the xinetd script for courierpassd... vi courierpassd service courierpassd Note: You may want to add additional IP's to the "only_from" setting above, depending on your needs. Save and exit. |
If your server uses Inetd, here's how integrate Courierpassd into it: vi /etc/inetd.conf Add the following line: courierpassd stream tcp nowait root /usr/local/sbin/courierpassd -s imap Save and exit. |
Now let's add the Courierpassd service to the system's services file:
vi /etc/services
Append to following line to the /etc/services file:
courierpassd 106/tcp #for /etc/xinetd.d/courierpassd
If your system uses Xinetd, them we now want to restart Xinetd:
/etc/rc.d/init.d/xinetd restart
If your system uses Inetd, then we now want to restart Inetd
/etc/rc.d/init.d/inetd restart
Now let's test Courierpassd by trying the reset the password for a mail account. Here's what a successfull test should look like:
root@redbox:/# telnet localhost 106
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 courierpassd v0.30 hello, who are you?
user postmaster@qmailrocks.org
200 Your password please.
pass my_password (don't be a dumbass. Put your own password here)
200 Your new password please.
newpass my_new_password (don't be a dumbass. Put your new password here)
200 Password changed, thank-you.
quit
200 Bye.
Connection closed by foreign host.
root@redbox:/#
If the above session is successful for you, Courierpassd is working correctly!
No comments:
Post a Comment