another FreeBSD postfix

Contents

* Introduction
* Resources
* Installing postfix from cvs
* Post-Installation Requirements for postfix
* Configuring postfix as a Null Client
* Starting and Testing postfix

Introduction

The previous articles in this series have got you as far as installing perl-5.8 from source, and now we're ready to do some serious work. So why do we need to install an email system on the server first?

Your server is going to run headless which means you don't use it for everyday stuff. You don't need a keyboard, mouse, or display to control it, because that's happening though the ssh interface via PuTTY. In fact, your server is going to sit in a closet and you won't even know it's there.

Which brings us back to email. Your server is going to email you stuff like security reports and daily system checks. Once you get the bug tracker installed, it's going to email team members bug reports and other useful information.

So why not stick with the default sendmail system that ships with FreeBSD? After all, it reportedly handles about 50% of the Internet's email. The reason is that a casual system administrator (you) has little or no chance of really understanding the arcane syntax of the sendamil config file(s). So we're not even going to try. We're going to use postfix instead.

In this article, we'll get postfix installed from source, and learn a bit about figuring out build dependencies. I'll show you how to set up the mailer as a null client, which means it does not receive or route any local mail. It just sends mail to your local mail host or directly to the Internet.
Resources

The postfix program has a wide following, so natuarally it has its own web site with an excellent summary of existing .

The O'Reilly OnLamp website also has a decent article on basic installation and configuration.

For those that really want to dig deep on the internals of postfix, there is the obligatory O'Relly postfix book.
Installing postfix from cvs

Installing postfix from source is relatively straightforward. The first thing to do is figure out if the port requires any other libraries or applications. This is relatively easy if you use the FreeBSD Posts Search page to look for ports with "postfix" in the package name. Here's clickable query link...

http://www.freebsd.org/cgi/ports.cgi?query=postfix&stype=name

We're lucky here, there aren't too many packages with "postfix" in the name. A quick look at the list tells us that the available ports are:

* postfix-2.2.20040504 - which is really called postfix-current
* postfix-2.1.4 - which is really called postfix

Depending on how risk averse you are, I'd pick postfix over postfix-current, unless you absolutely need the latest bleeding edge updates - and for our system, I'm not sure we do.

Either way, have a look at the "Requires" line for the port, and you'll see that pcre-4.5 is needed to build and run postfix. Click on the link for pcre-4.5 and you'll see that it's in the devel category. And it looks like pcre-4.5 has a requirement for libtool-1.5.6_1 which is also in the devel category.

In short, postfix has the following dependencies:

mail/postfix
+- devel/pcre
+- devel/libtool15

Remember that you figure out the download name of the port by clicking on the "Description" link and checking the title of the page you end up on. After a while, you'll figure out that you can just hover the mouse over the "Description" link and get the name from the status bar of your browser.

Now we have enough information to go and get the relevant port files to build postfix. Here are the commands I used to get postfix, as root of course.

setenv CVSROOT :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs
cd /usr
cvs login
cvs checkout -A -P -r RELEASE_4_10_0 ports/devel/libtool15
cvs checkout -A -P -r RELEASE_4_10_0 ports/devel/pcre
cvs checkout -A -P -r RELEASE_4_10_0 ports/mail/postfix
cvs logout

Building postfix is now simply a matter of:

cd /usr/ports/mail/postfix
make install

The postfix install script is interactive. Don't change anything and just tab over to the "OK" and hit return to accept all the defaults. As the build porgresses, you may (depending on how long ago this was written) see the following scary looking bit of output:

===> postfix-2.0.19,1 depends on shared library: pcre.0 - not found
===> Verifying install for pcre.0 in /usr/ports/devel/pcre
===> pcre-4.5 is marked as broken: unknown LIBTOOL version: 14.

Don't panic. It's just telling us we actually need libtool14 instead of libtool15. So all we need to do is download that port, like this:

setenv CVSROOT :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs
cd /usr
cvs login
cvs checkout -A -P -r RELEASE_4_10_0 ports/devel/libtool14
cvs logout

and restart the build...

cd /usr/ports/postfix
make install

A little while later, you'll get the following prompts if everything goes well:

Would you like to activate Postfix in /etc/mail/mailer.conf [n]?

Answer "y" and hit Enter. Then you'll see this prompt:

You need user "postfix" added to group "mail".
Would you like me to add it [y]?

Again, answer "y" and hit Enter. That's all the interactive stuff until the installation is complete.
Post-Installation Requirements for postfix

Assuming postfix installed well, and that everything worked, now we need to do some post-install configuration before going much further.

Here's a copy of some important information that scolls by near the the end of the install procedure. I've broken down into useful chunks for discussion...

If you have postfix configured in your /etc/mail/mailer.conf (answered yes to
the previous question) and would like to enable postfix to start at boot time,
please set these variables in your /etc/rc.conf file:

sendmail_enable="YES"
sendmail_flags="-bd"
sendmail_pidfile="/var/spool/postfix/pid/master.pid"
sendmail_outbound_enable="NO"
sendmail_submit_enable="NO"
sendmail_msp_queue_enable="NO"

This will disable Sendmail completely.

Alternatively to the above settings, you can enable postfix to start with
the other local services, for example, after your database server starts if
you need it to be running for postfix. To do this, set in your rc.conf file:

sendmail_enable="NONE"

Then make the following symbolic link:

cd /usr/local/etc/rc.d
ln -s /usr/local/sbin/postfix postfix.sh

For my installation, I copied the first set of variables and pasted them into my /etc/rc.conf file.

Also, you will want to disable some Sendmail-specific daily maintenance
routines in your /etc/periodic.conf file:

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

This turned out ot be unnecessary as there is no /etc/periodic.conf file yet on our minimal server, and besides, we disabled sendmail as part of the initial installation of FreeBSD.

If you are using SASL, you need to make sure that postfix has access to read
the sasldb file. This is accomplished by adding postfix to group mail and
making the /usr/local/etc/sasldb* file(s) readable by group mail (this should
be the default for new installs).

We're not using SASL, so don't do anything. That's all there is for the post-install step, now let's move on to configuring postfix.
Configuring postfix as a Null Client

Our minimal embedded development team server is not going to be a complete mail system. In fact, it's only ever going to send mail to others. We won't enable it to receive email until later, if at all. A server that only sends mail is acalled a null client in postfix terminology.

So the first thing to do is to disable the ability of postfix to pick up mail. You do that by editing your configuration files as suggested in this section on setting up a null client. Wait. Slow down. Let's figure out what this really means. Especially the part about disabling local mail delivery. Exactly what do we touch in the master.cf file to make this happen?

Here's a copy of the relevant parts of my master.cf file that ends up disabling the mail receive and distribute capability of postfix:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#smtp inet n - n - - smtpd
#submission inet n - n - - smtpd
# -o smtpd_etrn_restrictions=reject
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
#local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil

See how the smtp and local services are commented out by prefixing them with a "#" - that's all there is to it. Save the file, and now we can figure out the setup for the rest of the system.

I'm running my server on my local network. I've got a Linksys wireless router that handles all the traffic inside the house, and it's connected to my DSL modem. My DSL modem gets an IP address assigned by my local ISP.

To make things even more complicated, I do happen to have a real domain name, but it's hosted by a company across the country. Finally, my ISP (like many others) will not accept email unless it can verify that the domain name that the mail appears to be coming from is in fact real.

On a default setup of postfix, you need to touch exactly three things to send mail out the door. Here's the relevant section from my main.cf file:

# INTERNET HOST AND DOMAIN NAMES
#
# The myhostname parameter specifies the internet hostname of this
# mail system. The default is to use the fully-qualified domain name
# from gethostname(). $myhostname is used as a default value for many
# other configuration parameters.
#
#myhostname = host.domain.tld
#myhostname = virtual.domain.tld
myhostname = funkenfanger

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
#mydomain = domain.tld
mydomain = hempeldesigngroup.com

# SENDING MAIL
#
# The myorigin parameter specifies the domain that locally-posted
# mail appears to come from. The default is to append $myhostname,
# which is fine for small sites. If you run a domain with multiple
# machines, you should (1) change this to $mydomain and (2) set up
# a domain-wide alias database that aliases each user to
# user@that.users.mailhost.
#
# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no @domain part.
#
#myorigin = $myhostname
#myorigin = $mydomain
myorigin = $mydomain

All I've done here is added lines to specify myhostname, mydomain and myorigin to reasonable values. The most important one is myorigin, because it needs to be a real domain name or else your mail host is likely to bounce it right back, or worse silently ignore it.

So, to recap, just set myhostname, mydomain and myorigin, makeing sure that myorigin is a real domain. If you are unsure of what to put there for now, use example.com which is reserved for documentation but does actually resolve to an address.
Starting and Testing postfix

Hold on, we're almost done. If you haven't rebooted since we started this article (and why would you) you'll need to start postfix manually. This is accomplished as follows:

postfix start

Any time you make changes to a currently running postfix installation, you'll need to let postfix know so it can parse the changes. Here's how:

postfix reload

Testing your system is as easy as sending yourself some email. I'm assuming that if you are reading this, you have acess to email. We haven't got a fancy GUI installed on our box, and we're using PuTTY to access it, so how are we going to send email?

Well, back in the deep dark past of the early Internet, the hackers of the stone-age were able to send email using a command line interface! Yes, it's true!

Here's a transcript of my test email session....

funkenfanger# mail
Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/sysadmin": 0 messages
& m rhempel@bmts.com
Subject: Test Message
Postfix is up and running on funkenfanger!
.
EOT
& q
funkenfanger#

Pretty primitive, huh? The "&" is mail's idea of a prompt. The "m" followed by an email address is how youstart an email, then you are prompted for a subject line. After that comes the body of your email. The end of the email is signified by a single "." on a line all by itself, which then returns you to the "&" prompt and the "q" gets us back to the standard command prompt.

Of course, you'll use your own email address when testing your postfix installation! Although I'll be happy to get email form you describing how easy it was to get this far, I really don't want to see all of your test emails.

Once you're back at the command prompt, you can check to see if the mail went out as follows:

funkenfanger# mailq
Mail queue is empty
funkenfanger#

In a few minutes, fire up your email client and check your mail. You should get an email from "Charlie Root" with the subject and body you just typed in. If not, yo umight want to check the last few lines of /var/log/maillog to see if there are any error messages that can help you figure out what went wrong.

Well, that's it! We're done with the postfix setup. You'll be getting at least two emails a day from your server. One is the daily run output, and the other is the security run output. They'll give you a basic idea of how your box is doing, how many times other folks tried to hack it, and other useful stuff like disk usage statistics.

Now we can move on to getting Apache 2 up and running. See you at the next article.