Random Quotes:
|
| |
 |
 |
|
 |
|||
Killer Qmail on Debian Etch (Soon to be Lenny): Tutorial: Step 1
(This is a document in progress - please feel free to contribute thoughts, ideas or issues you have with this document) Reasons for this documents existence: I was originally introduced to the world of Qmail via a web site called Qmailrocks. While I found it helpful at the time, I increasingly became aware of many problems that arose from the way it did things. In particular, the use of scripts to facilitate the install of most of the walkthrough robbed the users of the experience and knowledge of how the system was being set up. Also, the Qmailrocks website appears to have been abandoned for the past few years and I, along with w0ls0n, parsec and Pebkac have been left to support the users on the QMR forums that the site left behind. Despite being told about the age of the QMR install, people still insist on following it which left the 4 of us (as well as numerous people on the QMR mailing list) to deal with answering the same questions over and over (See John S's remarks regarding these issues). I can't say that I mind helping though as, for me its payback for all of the help that John Simpson, marlowe, Nigel, Niamh, Bookworm, w0ls0n and everyone else on both the QMR and Qmail-patch mailing lists who helped me out. This document is intended to answer a large number of questions that I see daily on the QMR forums regarding a better way to set up a Debian / Qmail server. These are also serving as my own install notes. Overall, I hope to lead the user to an intermediate understanding of Qmail and it' supporting programs. Since Qmailrocks appears to be abandoned, I'm a bit worried that all of the notes and solutions that many of us have posted there may be lost so I'm beginning to build a Qmail FAQ as well that I'll be tying into this document. This walkthrough is currently intended only for Debian Etch (although notes on Lenny will be added at a later date) and draws heavily from a variety of sources such as John Simpson’s Qmail site (Thanks John!), Qmailrocks and a walkthrough passed on to me by Carlos Romualdo on the QMR mailing list. Numerous other people on the Qmail-Patch and QMR mailing list have also contributed directly or indirectly.
This walkthrough will provide the following:
Please note that these are not the only programs available for these various services and I hope to expand this document into a sort of choose-your-own-adventure install once I make time to test out items such as Simscan, Dspam and numerous other possible enhancements. Emphasis on this first version of the walkthrough:
Requirements:
25 - TCP - SMTP
25 - SMTP Step One: Get the softwareNote: I had originally put together a large apt-get command that would allow you to install a lot of the minor supporting packages that would aid in troubleshooting a lot of the issues I ran into when putting this walkthrough together but it was pointed out to me that the best walkthroughs explain why you are installing each package. Thus, I’ll be installing them right before they are needed. I’ve gone ahead and repackaged Eric’s QMR3 beta package with the current versions of most programs as well as making a few script changes. I don’t plan on using most of the scripts as they seem defeat the purpose of taking the time to explain each step. Bear in mind that, while there are a number of source packages for various programs in this tarball, many of these packages will be installed via Apt. Much of this tutorial requires that the directory locations be exact. (Don’t do what I did on your first install and try to install from a different location. It makes things a lot harder than they need to be as certain commands look for things in this directory. Be sure to have everything in /downloads/killerqmail) With the exception of a couple of steps (particularly the Courier IMAP install), this walkthrough requires that you are logged in as root.
Wget allows you to download something from the web directly into the directory you are in. Lets use it to get the full Killer Qmail package. THis package contains various source packages and patches that we will be usingin addition to the APt packages.
The following uncompresses and un-tars the contents of the zip file. tar zxvf killerqmail-0.01-beta-syngin.tar.gz Ok, we’ve got the main set of source packages now that we won’t be installing via Apt. I’ll include the download locations for each so that you can check for new versions. I don’t guarantee that newer versions will install correctly with this walkthrough though. Now its on to Step 2. ---------------------------------------------------------
Killer Qmail on Debian Etch: Tutorial: Step 2: Installing Qmail
(For those of you familiar with QMR v2, I’d recommend reading John Simpson’s notes on upgrading QMR v2.x here: http://qmail.jms1.net/upgrade-qmr.shtml You’ll need a browser like Firefox to view John’s site as he has IE banned (which really isn’t a bad thing) If you’ve had any experience with Qmail, you’ve either read at least some of his site or you really need to. John maintains a set of combined patches (which we’ll be using shortly) that make Qmail what it is today. Ok, lets get started. Eric at QMR originally wrote a script that does a number of mundane things like creating necessary users and directories for our install. He initially had most of the next set of commands in a script but I’m going to list them individually here instead so you are aware of each step. Having said that, here we go. Lets make sure you are in the correct directory:
The following creates the primary Qmail directory. It is important to note that /var is normally a strange place to install programs. Dan Bernstein has a FAQ at the following location to explain why he chose this location (http://cr.yp.to/qmail/faq/install.html) Note that the -p flag forces the creation of any parent directories if needed.
Next, lets create the directory for our Qmail source code and the necessary users and groups. mkdir /usr/src/qmail groupadd nofiles Ok, lets go and extract the various sets of source code that we will be needing. cd /usr/src/qmail The following is the source package for Qmail itself written by Dan Bernstein. While Qmail is available via Apt, it ends up being installed with parts of it in very different places which would render much of the available documentation invalid. Thus, we’re going to stick with the source package instead. It’s a little old by itself but we’re going to supercharge it with John Simpson’s combined patch set shortly. FYI: A very good visual representation of how Qmail works can be found in ‘The Big Qmail Picture’ here: http://www.nrg4u.com/ For reference, Qmail’s home page is here: http://cr.yp.to/qmail.html Lets extract the Qmail source code now. tar -zxvf /downloads/killerqmail/qmail-1.03.tar.gz UCSPI-TCP is a client / server program that manages TCP connections. For more information on it, its home page is located here: http://cr.yp.to/ucspi-tcp.html
tar -zxvf /downloads/killerqmail/ucspi-tcp-0.88.tar.gz Now lets create the package directory (I’m honestly not sure why the following packages weren’t uncompressed into the same directory as the 2 above in other walkthroughs. If anyone knows the reason, could you let me know?)
mkdir -p /package And change the permissions.
chmod 1755 /package Daemontools is a collection of Unix tools for managing services. Its home page is here: http://cr.yp.to/daemontools.html tar -zxvf /downloads/killerqmail/daemontools-0.76.tar.gz UCSPI-SSL is a set of command line tools for creating SSL (Secure Socket Layer) applications. It will allow us to encrypt connections on the server. This is one of the big changes since version 2. Its home page can be found here: http://www.superscript.com/ucspi-ssl/intro.html
tar -zxvf /downloads/killerqmail/ucspi-ssl-0.70.tar.gz Now we create the SUPERVISE directory. This is where we will set up all of the run scripts for the various Qmail services that will eventually be run under Daemontools.
Thus ends the contents of that particular script. Don’t you feel better for having entered those commands manually and actually learned what it was doing? Next, we are going to go and get one of the more recent combined patches that John Simpson has to offer here: http://qmail.jms1.net/patches/combined.shtml Currently, I’m going to be a bit daring and use his 7.05 patch (I’m providing a command below that will allow you to grab it from the command line below) which is currently in ‘testing’ but will probably be stable by the time people read this. We’ll need to make sure patch and patchutils are installed first because they are the programs that will let us patch the Qmail source code: apt-get install patch patchutils Note: If for some reason Apt reports that you already have something installed, that’s fine. This walkthrough assumes you are doing this on a bare Etch install and thus wouldn’t have these items already installed. John Simpson has a full breakdown of all the patches included at the following location: http://qmail.jms1.net/patches/combined-details.shtml You’ll definitely want to read all about them so you understand all of the great new functions you will be able to use. Once that’s done, switch to the Killer Qmail patch directory and download JS’s patch set there: cd /downloads/killerqmail/patches/ For our example, I’ll grab the 7.05 patch. Its already in the /downloads/killerqmail/patches directory but the following is an example of the wget command you would run to retrieve a more recent patch set version if desired. wget http://qmail.jms1.net/patches/qmail-1.03-jms1.7.05.patch Now lets jump back to the Qmail source code directory: cd /usr/src/qmail/qmail-1.03 Apply John’s big qmail patch set: patch < /downloads/killerqmail/patches/qmail-1.03-jms1.7.05.patch Apply the DomainKeys patch (already in the patches directory but its home page is here along with a plethora of additional information I recommend reading: http://qmail.jms1.net/patches/domainkeys.shtml): patch < /downloads/killerqmail/patches/qmail-1.03-domainkeys-jms1.7.patch Be sure to check the output of the patch command for failures. If you do run into patch failures, I would recommend joining the QMR or John Simpson’s Qmail-Patch mailing list. There is a ton of experts on that list and John S. himself also monitors it too. I highly recommend reading the mailing list FAQ FIRST here though first: http://www.qmrwiki.org/faq.php If you didn’t experience any problems, we should be good to go. A base Etch system doesn’t have openssl, make, gcc OR g++ installed so we’ll have to ensure that they are installed first: apt-get install make gcc g++ openssl libssl-dev We will also be using the DomainKeys patch. DomainKeys (as well as SPF) require that you can use TXT records in your DNS. It’s important to check that your Domain Registrar allows this first (hint: As of this writing, Network Solutions doesn’t allow you this option if your DNS is hosted there, GoDaddy does though) A free DNS service that supports TXT records can be found at http://www.zoneedit.com if needed)
Parts of the following instructions are paraphrased from: http://qmail.jms1.net/patches/domainkeys.shtml
cd /downloads/killerqmail The last command will run a test. It’s the checking that’s important. Since we don’t have a key set up yet, it will fail. Now we install a few of these files into necessary locations: install -m 644 libdomainkeys.a /usr/local/lib/ Ok, lets get Qmail compiled. cd /usr/src/qmail/qmail-1.03 make man Next we run an included script that will add the domain name of your server to a number of necessary files. Be sure to replace ‘your_FQDN’ with the ACTUAL domain name of your server (and yes, it should be legit) ./config-fast your_FQDN John Simpson has stressed heavily not to use the config-fast script due to an issue with the locals file in /var/qmail/control so we’ll go in and remove your domain from that particular file afterwards. It’s important that you edit it in a text editor, remove the domain name and then save the file even though its empty. (Footnote: John’s notes on this script and the locals file are towards the bottom of the page at http://qmail.jms1.net/upgrade-qmr.shtml ) nano /var/qmail/control/locals *delete the domain name Press Control-X to save. Assuming you didn’t run into any errors, Qmail should now be installed. *Whew!* Next, lets generate a certificate for encrypted connections. When you run the make cert 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, organization name, common name and so forth. The areas you need to respond to are in bold below. This step is to generate a secure certificate that will be used to encrypt your server’s TLS encrypted SMTP sessions. The certificate generated will be placed in /var/qmail/control (where all of the main Qmail configuration files go) Run the following command and fill in the answers to the questions it asks in bold below. Before it’s done, it will set the correct permissions of the certificate for you. make cert You will see output similar to the following:
Ok, now lets build ucspi-tcp (used for tcp client / server application): cd /usr/src/qmail/ucspi-tcp-0.88/ Ok, first we will need to patch the source code with the errno patch. (Note: QMR 2 instructions said that this wasn’t needed for Debian but it is now)
If you don’t get any errors, that’s it for ucspi-tcp! Now let’s install ucspi-ssl package, which will be used for our SSL enabled SMTP server… cd /package/host/superscript.com/net/ucspi-ssl-0.70 You’ll need this Perl library to get this to install correctly: apt-get install libperl-dev Ok, let’s compile it… package/compile Now we test it. This will take a moment and apparently doesn’t return any results on FreeBSD but does return results on an Etch machine. package/rts I always receive the following after I run this: 1108c1108,1111 < sslclient: fatal: unable to set cipher list — > sslclient: fatal: unable to SSL connect:protocol error > sslclient: error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available > sslclient: fatal: unable to SSL connect:protocol error > sslclient: error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available On the QMR forums, Parsec reports that you can safely ignore these errors although we’ll need to check some vpopmail permissions (also see John S.’s QMR upgrade notes again ): http://forum.qmailrocks.org/showthread.php?t=5115 Now let’s install this: package/install If you don’t get any (other) errors, that’s it for ucspi-ssl! Ok, next we move on to daemon-tools. First we’ll need to apply an errno patch to this as well:
Note: You may notice that after you install daemontools, the install script will tell you to reboot your server in order to start the svcscan service. Take this advice and reboot your server now. reboot When your server comes back online, a “ps -aux” command should reveal that the daemontools “svcscan” service is now running. (If you have a lot of stuff running on the server, try ps –aux | grep svcscan instead) --------------------------------------------
Killer Qmail on Debian Etch: Tutorial: Step 3: Support programs for Qmail
Ok, lets install a few support programs for Qmail. Ezmlm is essentially a mailing list manager for Qmail and integrates well into Qmailadmin (which we will be installing later) Since it isn't available in the Apt repository, we are going to use the source package. The home page for this package can be found here: http://www.ezmlm.org/ Installing Ezmlm is quick and easy:
Lets uncompress and extract Ezmlm. tar -zxvf ezmlm-0.53-idx-0.41.tar.gz Then we enter the directory. cd ezmlm-0.53-idx-0.41 And finally we compile it: make && make setup If there were no errors, you are all set! The next program to be installed is autorespond. This does pretty much what it sounds like. (ie. allows us to set up autoresponders for email accounts) This is available via Apt in Debian so we will be installing it from there. Please note that it is in the contrib repository so you will need to ensure that you are checking this repository. nano /etc/apt/sources.list Look for something like the following in there (Note: your actual server names will probably be different than this example) Ensure that contrib is listed. deb http://debian.yorku.ca/debian/ etch main contrib non-free If contrib is not listed in the above locations, add it and then press Control X to save the file. Run the following to refresh your Apt database and then install autorespond: apt-get update Lenny note: As of the time of this writing, autorespond appears to have been removed from both lenny and sid. This may not be permanent. (I think the maintainer may have vanished and the package hasn’t been reassigned yet) Check the following URL to see if it has been re-added: http://packages.qa.debian.org/a/autorespond.html This issue should not affect Etch) apt-get install autorespond If the above command reports that the package cannot be found, we will need to install the package from source (I have included a copy in /downloads/killerqmail):
There we go. Autorespond is installed. Finally lets install maildrop. Maildrop is essentially a replacement for the local mail delivery agent and is part of the Courier Mail server group of programs (http://en.wikipedia.org/wiki/Maildrop) Note: Maildrop is available in Apt but has the courier-authlib package as a dependency. I’ve had difficulty getting the Apt version of the courier-authlib package to work with this install which is why I’m compiling both packages from source. The Debian courier-imap package doesn’t support the authentication scheme we are using (vchkpw) and perhaps this is reason for the problems I’ve encountered with the Apt courier-authlib package. Lenny note: I’ve been unable to get maildrop to compile successfully on Lenny so you may have to install it via Apt in the end anyway. Maildrop home page: http://www.courier-mta.org/maildrop/ You’ll need 4 more packages from Apt for the compile to work correctly.
Whenever configuring a source package, it’s important to see what options you have available to you. Running ./configure --help will list all of the flags you can use in the configure command. Bear in mind that, with some programs (particularly Vpopmail), if you decide to go back and recompile it with extra features later on, you’ll need to recompile a number of programs that rely on it as well. Thus, it’s important to choose your configure flags carefully. Also, applying patches to the source code of programs can add extra options so hold off checking --help until you are done patching. ./configure --help For this walkthrough, we are going to use the following: ./configure --prefix=/usr/local --exec-prefix=/usr/local --enable-maildrop-uid=root --enable-maildrop-gid=vchkpw --enable-maildirquota make && make install-strip && make install-man Note: I’ve run into the occasional issue compiling this version of maildrop under Etch at this step. Using the old maildrop version (1.6.3) seems to work fine in these instances though. There is a copy in /downloads/killerqmail and it can also be retrieved from here: http://www.qmailrocks.org/downloads/maildrop-1.6.3.tar.gz ) Ok, we should be all set with maildrop now. --------------------------------------------
Killer Qmail on Debian Etch: Tutorial: Step 4: Vpopmail
Note: This section needs to be heavily expanded to explain all of the various options we have available to us at compile time. While pretty old, the following location has a lot of additional install tips for Vpopmail (http://www.inter7.com/vpopmail/install.txt ) It is heavily recommended that the user run ./configure --help to see the options that are available. Vpopmail will be housing all of our virtual email domains. Vpopmail's home page is at: http://www.inter7.com/index.php?page=vpopmail For this demonstration, I won’t be integrating MySQL into the Vpopmail install. Even without this integration, our setup will still be able to support around 50 domains. Note: The most recent version of Vpopmail can be found via Vpopmail's home page. If you are using a newer version, you will need to download the file via wget into /downloads/killerqmail and change the following instructions to suit that version’s filename. For this example, we will be using 5.4.26. Note: Since we are going to be using John Simpson’s skel patch for Vpopmail, ensure that you obtain the patch for the right version of Vpopmail (http://qmail.jms1.net/vpopmail/#skel )
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 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 Patch the source with John Simpson’s skel patch (the 5.4.26 version is available in /downloads/killerqmail/patches): patch < /downloads/killerqmail/patches/vpopmail-5.4.26-skel4.patchHaving access to a skel setup allows us to create files in a directory that will appear in all user directories when the user is created. This is particularly useful for .mailfilter files. Let’s see what our compile options are: ./configure --help Having looked at our options, I've gone ahead and chosen our loggin option, enabling maildrop and enabling the skel option provided by the above patch.
------------------------------------------------------------------
Killer Qmail on Debian Etch: Tutorial: Step 5: Qmail Administration Programs
(This portion assumes that you already have Apache 2 up and running) Next we install our 2 web based administration tools for QMail: vqadmin and Qmailadmin. VQAdmin :VQAdmin home page: http://www.inter7.com/?page=vqadmin VQAdmin is a web based control panel that allows system administrators to perform actions which require root access ie. for example, adding and deleting domains. This cgi program is authenticated using Apache-style .htaccess / .htpasswd files.
Now, lets configure vqadmin. (Note: be sure to change the below settings to the location your actual cgi-bin and web directory):
make && make install-strip VQAdmin should now be installed into a vqadmin subdirectory of the cgi-bin directory you specified above. (in the case of the above example, that would be /var/www/cgi-bin/vqadmin ) Next we need to make some additions / changes to your Apache configuration. You will need to edit the master Apache 2 configuration file: nano /etc/apache2/apache2.conf At the bottom, add the following (substituting the location of vqadmin where you installed it): # This is for VQAdmin <Directory “/var/www/cgi-bin/vqadmin”> deny from all Options ExecCGI AllowOverride AuthConfig Order deny,allow </Directory> While in this file, also ensure that the following line exists and is not commented out: AddHandler cgi-script .cgi Press Control X to save. Next, we will assume that you will be accessing this at your server’s normal domain. Run the following command to edit your default website configuration: nano /etc/apache2/sites-enabled/000-default In this file look for the following: ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory “/var/lib/cgi-bin/”> AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> We need to make some changes here. We will need to change the ScriptAlias to reflect where vqadmin is located. The Directory and AllowOverride parameters also need to be changed. Replace the above section with the following (changes are in bold):
ScriptAlias /cgi-bin/ /var/www/cgi-bin/ <Directory “/var/www/cgi-bin“> AllowOverride All Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> Control-X to save. Next, we are going to create an Apache .htaccess file to password protect this directory. cd /var/www/cgi-bin/vqadmin Note: the dot before the filename is necessary. nano .htaccess Change the contents to the following: AuthType Basic AuthUserFile /etc/apache2/conf.d/.htpasswd AuthName vQadmin require valid-user satisfy any Press Control X to save. Now we assign this file to be owned by Apache and set it with the correct permissions:
Lets create the password file now. Run the following command (replacing admin_passwd with the password you wish to use). Please note that the user MUST be ‘admin’:
Restart Apache2: /etc/init.d/apache2 restart If all has gone well, you should now be able to browse (in your web browser) to: http://www.your_default_domain.com/cgi-bin/vqadmin/vqadmin.cgi Now that you are here, go ahead and enter your username (admin) and the password you created) Once in vqadmin, add your first domain. We will need this later when we set up Qmailadmin.
Qmailadmin:Qmailadmin home page: http://www.inter7.com/?page=qmailadmin Next up, we are going to install an admin tool that is best used for day to day email account maintenance which displays information only for the domain the user comes from when logging in. By this I mean it is domain specific so you can hand out Qmailadmin accounts to domain admins so they can administer their own domains.
As with VQAdmin, you will need to tailor the following configure command to the right location of your cgi-bin and www directory. Please run the following and read about the many options you have with configuring Qmailadmin: ./configure --help For now, I’m just going to recommend a basic install so we will run the following command (remembering to substitute the cgi-bin and www directories so they are pointed to the right place) ./configure --enable-cgibindir=/var/www/cgi-bin --enable-htmldir=/var/www --enable-modify-quota --enable-domain-autofill --enable-modify-spam --enable-maxusersperpage=50 --enable-maxaliasesperpage=30 You will receive a brief breakdown of the settings when the configure script finishes. Finally, we run the make commands. make && make install-strip That’s it! Now browse to http://www.yourdefaultdomain.com/cgi-bin/qmailadmin and you should see the login screen. Login with the postmaster and password for the domain that you created a while back using Vqadmin. Once you log in, you will notice that you can also administer Ezmlm mailing lists as well as email accounts and forwards for your domain now. Additional Qmailadmin documentation can be found here: http://www.inter7.com/index.php?page=qmailadmindocs
Killer Qmail on Debian Etch: Tutorial: Step 6: Finalizing QmailWe should be pretty much good to go as far as moving the server over to using Qmail now. Assuming you are using a base Etch install, It may have installed Exim4 by default. We'll be removing that first. Apt will try and complain however because it won't think that there is any MTA is installed so, if we were to simply use Apt to remove Exim4, it will want to remove everything on the system that lists an MTA as a requirement. While it’s sort of ok to have Exim4 still on the system but not running, you run the risk of overwriting a few of our configurations here if you run apt-get upgrade and there's an Exim4 upgrade that you don't notice. Better to be safe than sorry. Thus, we need to do the following (Special thanks to Carlos Romualdo on the QMR mailing list for this step):
This copies the file that will substitute for Exim4. cp /usr/share/doc/equivs/examples/mail-transport-agent.ctl /tmp This will compile our new "fake" MTA: equivs-build mail-transport-agent.ctl If Exim4 is installed, remove it now by doing the following:
These two lines will remove Exim4 without messing dependencies. Now we have to install the fake MTA .deb. dpkg -i /tmp/mta-local_1.0_all.deb Now we can update the system without breaking it. Let's move ahead with the run scripts necessary for our services: qmail-pop3d, qmail-smtpd, qmail-send and for logging for each service. Note: I’ve ditched the old QMR run scripts in favor of the ones that John Simpson put together (I believe that Dave Sill initially may have created at least some earlier versions of these). The new ones offer a LOT more functionality. NOTE: Each of these cp commands is intended to be all on one line. cp /downloads/killerqmail/scripts/finalize/linux/service-pop3-run /var/qmail/supervise/qmail-pop3d/run For all of the logging run scripts, we’re going to be using John S’s version that is included in the tarball. Its important to note that we won’t be able to use a number of features provided by the John Simpson patches if we don’t use his various run scripts here (Home page for this script is here: http://qmail.jms1.net/scripts/ ) cp /downloads/killerqmail/scripts/finalize/linux/service-any-log-run /var/qmail/supervise/qmail-pop3d/log/run For the SMTP services, we’re going to use his SMTP run script (This script has its own page here: (http://qmail.jms1.net/scripts/service-qmail-smtpd-run.shtml )
Note that we’re setting up a separate log service for each SMTP / POP3 service.
Qmail-send takes care of internal routing of email.
And another log run script added for qmail-send.
This is actually another copy of the SMTP run script used above but we will modify it later so that it uses SSL and runs on port 465.
And one last log script for our soon to be SSL SMTP service.
The next 2 commands copy the rc and qmailctl scripts to their proper locations. Qmailctl will be used to start, stop and report queue stats for Qmail.
Finally, we need to set the right permissions to all the scripts we just moved to the correct location.
This basically lets qmail know the subdirectory of the user account that the email will be delivered to. echo ./Maildir > /var/qmail/control/defaultdelivery These set the maximum number of concurrent remote sessions that Qmail can have open and the correct permissions on this particular file.
This sets the maximum number of concurrent incoming emails at any given time as well as the necessary file permissions.
This links the script for starting, stopping and viewing the email queue into /usr/bin so you won’t have to include the path when you run it.
Finally, we add links to all of the Qmail services under /service so that daemontools can look after them. This command is intended to be all on one line.
Excellent. Let’s do some editing of these run scripts so that they are configured the way we want them. Note: I could have pre edited these scripts but its best if you do it so that you can familiarize yourself with what they do and how they do it. First, we’ll edit the run script for our main SMTP service. This is primarily be used just for receiving email on port 25. We will be configuring an SSL service on port 465 later on that users will use to authenticate and send mail out on. Documentation on all of these settings can be found at: http://qmail.jms1.net/scripts/service-qmail-smtpd-run.shtml I highly recommend reading this page to ensure you understand what each setting is for. Also, John put together a grid for grouping settings together that really helped me out here: http://qmail.jms1.net/tls-auth.shtml
Make the following changes. If you wish to bind the service to one ip, enter that ip after the IP setting. Otherwise, set it to 0 for all ips:
Uncomment all of these. These will enable blacklisting and greylisting (which will be set up later) which preempt any SMTP connection and deny it if it is listed in any of the blacklists configured by the RBL_BAD variable (rblsmtpd) or hold off the connection if the ip is one the server hasn't received a connection from before (greylisting) :
Change these. Setting AUTH to one will allow an authenticated user to be able to send on this port if necessary (handy of you are migrating users from an old server and don't want to have to change everyone's client settings at once):
Uncomment these and set DOMAINKEYS to 1 (We will be finalizing the DomainKeys setup in a little bit) Note the '%' symbol. This will allow the system to determine which domain is sending and sign the email with that domain's DomainKey.
Uncomment this so we will be able to use Qmail-Scanner (which allows us to tie in Spamassassin and ClamAV)
Control-x to save this file. Next, we will be modifying a copy of the same script for our SSL service on port 465 that users will be sending email out on.
Change the following:
Uncomment the following:
We won’t need to edit the other scripts.
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. 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. Substitute in your own information. Country Name (2 letter code) [GB]:CA
OK, all done there. By now, you may notice that some Qmail functions are already up and running, so to finish the install, we weill stop Qmail....
And setup elective relaying...
Then we run the command that rebuilds this addition into the tcp.smtp database.
(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.) echo some_address > /var/qmail/alias/.qmail-anonymous (where "some_address" is the system user or email address you want these addresses aliased to.)
Alright. We've got qmail ready to go. One of the last things we need to do is to disable/uninstall Sendmail / Exim4 or Postfix 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.
Just a note. If for some reason you left Exim4 on your system and you accidentally upgrade it, the following 2 links are what gets overwritten. Now lets link in their new replacements:
Ok, lets test out your installation now with Eric's test script (which is a modified version of Dave Sill's Life with Qmail install check script).
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!
Run the following to ensure that there are no other qmail services running:
If there are still services running, kill them all then start Qmail again:
You can find out how things are running by:
You should see an output like this:
Note: pop3d will be active after we complete the Courier-IMAP install. ------------------------------------------------------------
KillerQmail on Debian Etch: Tutorial: Step 7: Installing Courier IMAPCourier-IMAP home page: http://www.courier-mta.org/imap/ Courier-authlib home page: http://www.courier-mta.org/authlib/This step has probably created more problems on the QMR forums for Debian users than any other. At some point after Eric published QMR v2, the maintainers of the Debian Courier-IMAP server package stopped support in it for vchkpw authentication. Thus, most people have since then been installing Courier-IMAP from source. (Note: at least one user on the QMR forums has put together a Courier-IMAP .deb but reports were that it wasn’t working well if you were using MySQL in your install. I haven’t confirmed this.) Ok, lets get started. First, we need to make sure bzip2 is installed (I think. I’m not sure whether the -j flag in tar works without it installed). First, we’re going to install courier-authlib. We’ll need 2 Debian packages first:
Note: courier-authlib-0.60.0 was available as of this writing but ‘make’ ran into problems with the authvchkpw module which negated it from being included in this walkthrough.
Around line 26, change the following line:
to this:
Now we will add a startup command for authedaemond to the /etc/rc.local file to ensure startup on boot…
Add the following line above exit 0:
Note: if you encounter a library error, apt-get install libltdl3 That should take care of courier-authlib for now. Let’s install courier-imap… Note: Courier IMAP needs to be compiled by a NON-ROOT USER. For this demonstration, I’ll be using the user syngin.
Note: Substitute ‘syngin’ for your normal user account on the server:
Now we will exit out of our NON-ROOT USER and go back to being root…
Now let’s create an SSL certificate for the IMAP-SSL server…
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.
Change postmaster@example.com to an administrative email address Save and exit
Make sure that the following configuration exists: IMAPDSTART=YES. Also, have a look through to see if there are any other specific configuration changes you want to make. Save and exit the file.
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 he /usr/local/etc/imapd file, the line you are looking for looks like this:
Now we create the startup scripts…
Now let’s start up Authdaemond, IMAP, IMAPS and POP3D-SSL. To be safe we’ll stop each service before starting it…
If you run “nmap -sV localhost“, you should see both 143 and 993 now open and listening. Nmap is a very handy port scanner. If you don’t have it installed, just run:
Now lets make sure these services come up on boot. Add the following 2 lines to /etc/rc.local above exit 0:
Lines to add before 'exit 0':
Now that Courier-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)
OK. Courierpassd is installed now. Next, we are going to configure Xinetd/Inetd to run courierpassd. If your server uses Xinetd, here’s how you integrate Courierpassd into it:
Here we create the xinetd script for courierpassd…
Add the following to the file you are creating:
Note: You may want to add additional IP’s to the “only_from” setting above, depending on your needs. Save and exit. OR If your server uses Inetd, here’s how integrate Courierpassd into it:
Add the following line:
Save and exit. Now let’s add the Courierpassd service to the system’s services file:
Append to following line to the /etc/services file:
Now lets restart xinetd OR inetd (whichever you are using): For xinetd:
OR inetd:
Note: The daemon names on your system might be named differently. On Sarge and perhaps Ubuntu systems, the inetd command might need to be /etc/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 (change the bold items to your own information): root@syngin:/# telnet localhost 106 If the above session is successful for you, Courierpassd is working correctly! Now that we’ve got Courier-imap and Courierpassd installed, next up is Spamassassin, ClamAV and Qmail-Scanner ------------------------------------------------------------
KillerQmail on Debian Etch: Tutorial: Step 8: Spamassassin
Ok, on to the fun stuff. Let's move on the Spamassassin and (later) Clam AntiVirus. Spamassassin home page: http://spamassassin.apache.org/ With all of the great options that John Simpson has in his combine patch set, Spamassassin won't get as hard a workout as it may previously have received but its still a necessary part of the whole antispam equation. Since Spamassassin (3.1.7 as of this writing)(and especially ClamAV) are updated relatively often, we're going to add Debian's Volatile repository to our Apt sources.list. (more info on the Debian Volatile project can be found here: http://www.debian.org/volatile/ ) (Thanks to parsec on the QMR forums for pointing me originally in this direction)
Add the following 2 lines to this file:
Press control X to save the file. Now lets update the Apt database with the new repository :
Seeing a public key signature error like the following?: ... Fetched 6124kB in 26s (232kB/s) Reading package lists... Done W: GPG error: http://volatile.debian.org etch/volatile Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EC61E0B0BBE55AB3 W: You may want to run apt-get update to correct these problems Run the following commands to import the correct GPG key if you experience the above error:
Great. Let's install Spamassassin now along with a number of suggested and recommended Perl modules. The following is all one line:
By default, Spamassassin is disabled. To enable it, we'll need to edit the following file and change the ENABLED variable to ENABLED=1.
Also change the OPTIONS line to look like the following (all on one line):
Press Control X to save the file. Note: The Debian Spamassassin package keeps its configuration files in /etc/spamassassin (rather than /etc/mail/spamassassin where the QMR version (and I believe most source installs keeps them))
Any Spamassassin configuration tends to be relatively specific to the needs of the admin so the following minor changes are very basic. Alternately, there is an online configurator available for Spamassassin 3.x versions that does a pretty good, basic job of getting you up and running here: http://www.yrex.com/spam/spamconfig.php The above configurator will generate a basic set of configs that you can use to replace the default local.cf (When replacing configuration files, its important to note the file permissions on the orginal so they can be applied to the replacement) Any, if you want to just edit the default config, the following should be considered a basic starting point:
Uncomment the following lines:
Bear in mind that there are a ton of other options for this file that are not listed in the default local.cf though. A full list can be found here: http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html I'd recommend going through and seeing what you would like to implement. When you are done editing the file, press Control X to save the file. We'll be coming back to this file when it is time to set up a few Spamassassin plugins: DCC, Razor2, DKIM and Pyzor. DCC Home page: http://rhyolite.com/anti-spam/dcc/
Uncomment the following to enable the DCC plugin :
On to the next file:
Uncomment the following to enable DKIM checking (DomainKeys):
Next, lets fire up the Spamassassin daemon.
One thing that it is important to do is ensure that there are no issues with your configuration (and later, rulesets) with your Spamassassin install. The following command allows you to check your current configuration and rulesets against Spamassassin for errors before you restart Spamassassin and implement the new configuration. Any time you make config or rule changes, it is really important to run this and check its output before you restart the Spamassassin daemon. There will be a ton of information in the output that you can use to tweak your install and it will list any errors it encounters. Anyway, here's the command:
Since we haven't done much with the configuration, there shouldn't be any errors. The Debian Spamassassin package keeps all rulesets in /usr/share/spamassassin . One thing to bear in mind is that, since we're using the Debian package, any changes to these rulesets will be overwritten on the next update. To add your own custom rules (which you may want to do) add them in new files in this directory (I use a standard filename for this purpose that I keep them all in: syngins_rules.cf ) A good HOWTo on creating spamassassin rules can be found here: http://wiki.apache.org/spamassassin/WritingRules An important point (at least IMHO) is to write positive rules that reflect key words related to any businesses that will be using this server as an email server. For example, I'm the network admin for a local company the manufacturers welding guns, MIG guns to be specific, because of this I've added rules such as the following to lower spam scores when certain keywords are found in emails:
----------------------------------------------------------------- KillerQmail on Debian Etch: Tutorial: Step 9: ClamAVNow lets install Clam Antivirus. (Home Page: http://www.clamav.net/ )
Next, we add the qscand user for Qmail-scanner. ClamAV is going to run as this user.
We need to make a change to the default ClamAV configuration:
Change clamav user to qscand (keep all of the other default settings) Lets set our virus update database to our own country. Leaving all of the other settings at their default should be fine.
The following changes ownership of the various ClamAV directories to the new qscand user:
Change DatabaseOwner qscand
Change the ‘create’ line to this: create 640 qscand qscand Do the same for /etc/logrotate.d/clamav-freshclam Start the ClamAV daemon:
-------------------------------------------------------
KillerQmail on Debian Etch: Tutorial: Step 10: Qmail-ScannerQmail-scanner is what we are going to use to tie Qmail, Spamassassin and ClamAV all together. If you will recall, when we compiled Qmail earlier in this installation, we applied John Simpson's combined qmail patch. One of the patches within his combined patch is the "qmailqueue" patch, whcih allows Qmail to be configured to run with a substitute queuing mechanism. That's exactly what were about to do here. We're going to tell Qmail to use Qmail-Scanner as the queuing mechanism / content scanner. Qmail-scanner is going to allow us to integrate Clam Antivirus and SpamAssassin into our qmail server's mail queue. In short, that means your email server will scan all mail for spam and viruses. So let's get on it! Qmail-Scanner home page: http://qmail-scanner.sourceforge.net/
The following is a particularly helpful patch for Qmail-Scanner that adds extra functionality for Spamassassin control (if you are updating to a newer version of Qmail-Scanner, ensure that there is a version of this patch for the version of Qmail-Scanner that you wish to use):
How you go about configuring and installing qmail-scanner from this point on depends on how your server's installation of Perl is configured. For the purposes of this installation, there are 2 Perl setups. 1. Perl is configured to allow for setuid functions. (Generally the default setting on Debian Etch) 2. Perl is not configured for setuid functionality and, in fact, does not permit it. We'll start off with the configuration step for a server that allows setuid. However, if you run into setuid errors, you can jump to a set of instructions for servers that do not allow setuid functionality. So let's do it... First, you need to configure the script for your needs... Again, check the script's help to see if there's anything else you will need:
Ok, use the following command to configure the package (Make sure you change domain.com to the domain(s) the server will be serving email for. Multiple domains can be split using a comma (,)).
If you don't see any errors, run a similar command but with --install at the end.
Ok, lets restart Qmail now:
And lets test it. There is a little script in the below directory that will send out a couple of emails to test our new setup.
We need to make the script executable.
Run the following command and read the output which will explain what it does.
The above command will just show you the explanation of what its going to do. When you are ready for your test, run this command.
----------------------------------------------------------
KillerQmail on Debian Etch: Tutorial: Step 11: Validrcptto and Qmail Updater or Cron Updating
The best source for information on this patch can be found on John S.'s site here: http://qmail.jms1.net/patches/validrcptto.cdb.shtml The following will allow us to create the necessary CDB database:
Change: #ifndef ERROR_H To:
Compile the program.
Note: There used to be a Debian Apt package for CDB_File but it seems to have been discontinued with Sarge. Thus, we will install it via CPAN:
If this is your first time using CPAN, it may ask you for a bunch of settings for its initial configuration ...:
Ok, now we grab a copy of John S.'s script that will scan the system and create a text file with all of the email accounts that the server hosts.
Test from another system (shamelessly borrowed from John;s site. Sorry John): % telnet your.mail.server 25 Ok, validrcptto should be working for you now. To
automate it, John Simpson had a qmail-updater script that will help you
update this file as changes are made to the virtual domains. It’s
mildly complicated to set up. I should point out that, just because it
might be more difficult doesn’t mean the extra work won’t be worth the
effort though. Route #1: http://qmail.jms1.net/scripts/qmail-updater.shtml The way I understand it, John’s script is intended to run under Daemontools and only updates the database when changes are made. If this is going to be a very busy email server, it would be more prudent to follow John’s instructions for this portion of the walkthrough. Please note that if you go John’s route, you will want to have Vpopmail patched with the OnChange patch: http://qmail.jms1.net/vpopmail/#onchange OR Route #2: Alternately, you can just run a cron job every x # of minutes to take care of this. This is slightly more resource intensive but much easier to set up.
Add the following lines to this file (2 lines):
Save the file. (Control-X)
To have this script run every 5 minutes, add the following to /etc/crontab:
Finalizing DomainKeys: Home page: http://domainkeys.sourceforge.net We still need to complete a couple of steps to complete the setup of DomainKeys. Below is a modified version of John’s instructions from the following document: http://qmail.jms1.net/patches/domainkeys.shtml I recommend reading the above document to further your understanding of Qmail and DomainKeys. The bottom portion regarding the DNS setup to support DomainKeys in the above link is particularly important to read. (domain.xyz is just an example of course)
Now we will create our DomainKey:
The above command will create 2 files: default and
default.pub. It is very important to keep the default file safe as any
server that has a copy of that file can send out email for the domain.
After creating or changing keys, you should run these two commands to
ensure that the files have the correct ownership and permissions.
Ok, now let’s add the required DNS entries to support our DomainKey key. If you are using djbdns, John has a walkthrough in that link for you. If it’s Bind or via some web interface, do the following. (I initially had quite a bit of trouble getting this part to work so I’ll go into pretty heavy detail to ensure that we cover everything.) First, open up the default.pub file we created in a text editor. It will look something like this:
Copy and paste the entire line in there into something you can edit. Since the key is on one line without spaces, you can’t wordwrap it with nano’s –w flag so you’ll have to cut and paste each section. Be sure not to include the ‘$’ symbol at the edge of the screen. (This merely indicates that the line continues but that it can’t display anymore of the line) The line must be copied exactly or DomainKeys won’t work. I can’t stress that enough. Example contents (condensed):
Ok, lets go to your DNS and add a couple of TXT files in support of our key. Note: These steps may need to be changed a bit (I’ve been told that this may not be the best way to do this although it IS functional. Again, any recommendations are appreciated) Add the following TXT record in your DNS:
The t=y value is important because it says that your domainkey setup is in testing mode. (we will remove this once everything is working right) o=~ denotes that not all mail coming from your domain is signed with DomainKeys. The ‘r=’ flag allows you to designate an email address that can be notified if someone tries to forge your DomainKey.
to be continued...
|
|||||
 |
 |
 |
Personal writing © 1995 - 2012 - Syngin.Com |
