At some point in your life you may find yourself in a situation where you are in need of either control of your own mail server, or a file server where you can host files for the whole family, or share them with ease.  For the latter, the methods most people use tend to be clumsy, insufficient, or present a privacy and security risk that shouldn't be taken.  The easiest way to elevate this is to simply build your own file server.  While not completely eliminating all security risks, things can be done that will ensure that your files will be safe, secure and available anytime you need them from any computer on the network.  And even remotely in some cases.  Due note one thing.  This tutorial will teach you how to setup both a file and a mail server on the same machine at the same time.  

The part of this tutorial that teaches you how to setup a mail server on your machine will help you create what is called a "fetching" mail server rather than a standard "receiving" mail server.  You can still use your server as a "receiving" mail server, however, for security reasons, and since this is a personal mail server and it will include a file server as well, it's preferable to use a "fetching" mail server setup instead, hence why I'm using that in this tutorial.  In a later tutorial I'll cover how to setup a proper "receiving" mail server with all the security to make it safe to use on your network.  And lastly, to clarify one thing.  A "fetching" mail server does not receive mail directly.  It goes out and grabs the mail from a remote mail server or mailbox, sorts it locally and delivers it to the respective users.  A "receiving" mail server handles mail in the same way your ISP's mail server does by receiving mail directly from other servers on the net.  Now let's look at how to build our server and how it came be very useful to us.
Installation

The installation of Freebsd for this tutorial is going to essentially be the same (for the initial install of the OS anyways) as was mentioned here for the multimedia workstation tutorial, however, there will be some key differences that I will address, so I am reposting the entire install tutorial here with the appropriate changes to avoid confusion.

The first thing you'll need to install Freebsd is both install disks for Freebsd 6.2 Release. You can get them from www.freebsd.org via one of their ftp sites.  If you can't download them yourself, you'll need to ask a friend who has high speed to do it for you.  Eventually you'll be able to go to on-disk.com to get them, but for now, they don't have them.  The ISOs are about 570 meg and 600 meg in size respectively and can be quickly downloaded to your computer and burned to two CDRs. After that is done, just pop disk one into the cd drive on whatever computer you'll be installing this on, restart the machine and let the disk load up. You will first be greeted with a screen that asks what country your from. Depending on what kind of computer you have, it may default to number 230, which is for the United States, but it may also default to your actual country. Regardless where it lands, if it's not correct, just browse the list until you find your respective country and then hit enter.

Select "Standard Install" and hit enter. This will take you to a second screen that asks about partitioning your drive.  Since our server will be doubling as both a file and mail server, I'm going to show you two different ways to setup your drives depending on how you choose to setup your server.  By this I'm referring to having just one hard drive in it, or several.  If you have just one drive, you'll find that it will immediately ask you to setup your drive with the partitions you need.  If you have two or more drives, it will ask you which one you want to start out with first.  Assuming you've put the drive you want as your primary system drive on the Primary Master IDE interface (or the first serial connector if you're using serial) and your other drives are in the sequential order of how you want to use them, then they will be listed as ad0, ad1 and so on.  ad0 should be kept as your system drive if you're using more than one drive.  If you're doing two or more drives, then ad0 is assumed if you've set the drive on the Primary IDE controller in the master configuration.  Here's the size recommendations for the drives you should use on this server if you're using more than one drive:

ad0 - 40gb (you don't need anything more than this since your extra users and files will go on the second drive)
ad1 - 400gb (you can use a larger or smaller drive than this if you want, but I'm using this as an example for the article)

If you're using only one drive in your system, I recommend it be at least 200gig, preferably more in the area of 400-500gb.  But in the end I feel it's better to separate your data drive from your system drive, and thus the need for at least two drives.  For one, it's faster, and two, your system drive is more likely to fail before your data drive.  So if you have two drives, you're less likely to risk your data over the long term should a hardware failure ever occur.  Now, as mentioned before when partitioning a drive, if you have one drive, it will immediately go into its notice about the drive geometry being off (won't happen to everyone, enough will see it that I'm going to mention it anyways) which you simply hit enter to bypass.  As mentioned before, if you get that error message, it's because your hard drive manufacturer uses a non-standard way of reporting the drive's actual size. A number of hard drive OEM's are guilty of this, so Freebsd simply adapts to this marketing spin by adjusting its settings to the correct parameters for the drive. If you have two or more drives, you'll first be greeted by a series of checkboxes where it'll ask you to choose which drives you want to partition before going into that message and the partition editor.  Start with ad0 and follow the steps to partition it.  

Now you should find yourself in the Fdisk partition editor. You'll want to select each item in here that contains an active partition type (under "desc" it'll say something like extfs, dos, etc and hit the "D" key to delete it.  If one of them says "unused", just ignore it as that's not an active partition. When you're done you should end up with just one entry that has a description of "unused". Now hit the "A" key to use the entire drive and "Q" to quit. The next screen will ask you to install a boot manager. Select "Standard" and hit enter.  If you're using two drives, it'll go back to the previous screen which allows you to setup the second drive.  We'll take care of that later, so just tab down to "OK" and hit enter twice here to continue.  This will take you into the label editor. This will create the actual slices you'll use on your system.

A slice is a subsection of a partition. It's used to divide up the drive into logical sections that can be individually tweaked for security, size, permissions and the like without affecting the whole drive. Now, most people at this point would be tempted to just type "A" and let Freebsd determine what it should have for each slice. It's best not to do that as it might shortchange you in areas in which you'll need extra space. Here's my personal recommendation for each of the slices and their respective sizes on your system. These might seem a bit odd to you, but it's the preferred way to setup your drive for this particular application.  Here's how your drive should be divided up.

Primary (assumes 40gb main drive, but can also be applied to larger drives)
/ - 512 megs (this is your root partition.)
Swap - 4gigs (this should always be at least 2x's the amount of ram you have, preferably 4x's for this application.  My recommendation assumes 1gb of ram on your server)
/var - 4g (This can be up to 8gb-12gb or more if you expect to store a lot of mail on your server or have a LOT of users.  Typically 30 or more.  Just don't go beyond 1/3rd of your total drive space though.)
/tmp - 2g (can be up to 10gb, but don't go beyond ¼ of your total drive space)
/usr - whatever remains.

The other drive(s) should be ignored by setup at this point as we didn't setup a partition on it/them yet that Freebsd could use.  If it prompts you, don't check anything.  Just hit "Q" to exit the slice editor without doing anything further.

Once you're done in here, type "Q" to exit.  In this next screen, select #6, which is "Kern-Developer". We'll need what this provides us later. When you select it, it'll ask if you want to install the Freebsd ports collection. Hit enter to say yes. We'll need this later too. This will take you back to the previous screen. Navigate up the list and select "Exit", then hit enter. In this screen select "CD/DVD" to install directly from the CD you booted from. If you have more than one drive, it may ask you which drive the cd is in. If you're uncertain, try them both. But typically acd0 will be your cdrom drive. The next screen will tell you this is your last chance and what changes you make from this point on are not reversible. Just hit enter. At this point you can go grab yourself a soda as the installer formats your drive and installs Freebsd. This usually takes 3-5 minutes depending on how fast your machine is. After this is done it'll say it's completed its work, but it has a few extra questions for you. We'll want to take special care with these as how you answer will determine your system security later on. Hit enter to continue.

To speed through the next series of questions, I'll list them as bullet points with the question and recommended answer for you. If for some reason you have a different need, feel free to deviate a little bit from this guide to make those changes as this will ultimately be *your* machine.  But for the most part I'd recommend not to deviate at this point because we want to look towards having extra security in this setup, thus my recommendations below are best if followed in order to achieve that.

--------------------------------------------------------
* Would you like to configure any Ethernet or SLIP/PPP network devices - YES
* (select your network device, usually the first item listed, and hit enter)
* Do you want to try Ipv6 configuration of the interface - NO
* Do you want to try DHCP configuration of the interface? - No (We'll want a static IP.  In the next screen, enter your hostname and domain name.  Probubly something like "fileserv.myisp.com" or whatever you want to name it.  Now tab down, enter the IP address you want to use for this machine, the subnet and your gateway.  You'll need to know these in advance, so have them handy.  This includes picking out a free IP address on your network that you can use on this machine.  Once done, select OK and hit enter.)
* Do you want this machine to function as a network gateway - NO
* Do you want to configure inetd and the network services that it provides? - NO (We won't be using this simply for security reasons)
* Would you like to enable SSH login - YES (we'll need this for remote admin)
* Do you want to have anonymous FTP access to this machine? - NO
* Do you want to configure this machine as an NFS server? - NO
* Do you want to configure this machine as an NFS client? - NO
* Would you like to customize your system console settings? - NO
* Would you like to set this machine's time zone now? - YES
* Is this machine's CMOS clock set to UTC? If it is set to local time, or you don't know, please choose NO here! - NO (some machines do have UTC CMOS clocks, most don't. So unless you're 100% certain your CMOS clock supports UTC, say NO here)
* Select your time zone based on continent, country and state/province. In some cases when you hit enter after doing this, you'll get a question that asks if the time zone abbreviation looks right. If it does, hit enter, if not, click no and you can change it.
* Would you like to enable Linux binary compatibility - YES (This will be handy for other things later)
* Does this system have a PS/2, serial, or bus mouse? - NO (it's going to be a headless server, so we won't be having a mouse)
--------------------------------------------------------

Well, that ends that series of questions. The next one it'll ask you is about the ports collection. Select Yes and hit enter. We'll need four basic ports from here to get started. The rest we'll add later.  Here's the ports you'll need:

WWW - Lynx
Mail - Pine (you can use something else if you like, but for what we're doing, pine is best)
Net - Cvsup-without-gui
Shells - Bash

Navigate to each of the categories (ie www, mail, shells, etc) and select each of these packages by scrolling down the list, hitting space to select, tab to select "OK" and enter to go back to the previous screen. Once you've selected all four of these, hit tab and select "Install", then hit enter. It'll ask you to confirm what you want to install. If you missed one, don't worry, just continue and we'll pick it up later if need be. Now hit enter to begin installing the ports. You'll need disk 2 for this as that's where the package files are located at. Just slip that in, hit enter and let it do its thing until it's done.  When it's finished, switch back to disk one.

The next screen will ask you if you want to setup any user accounts. We will be adding other user accounts later, however the only one we're setting up right now will be the "admin" account.  There's a reason for this, but I'll explain that later.  Now select "Yes" and hit enter. Select "User", hit enter. Type in the login ID (this will be the username), tab twice to the group and type 0 so that this user has access to sudo or su for administration purposes, hit tab and enter a password. Hit tab, backspace out the letters in this box and type in the user's full name. (Anything is fine here, but since this will be the admin account and not a regular user account, something like "super user" may be more appropriate here) Hit tab 3 more times, backspace out the text and type in "/usr/local/bin/bash". This will make use of the bash shell you just installed. Hit tab and then enter.  Now select "Exit" and hit enter to leave this section.

The next thing it will do is ask you for the password for "root", which is the supreme admin user on the system. I recommend a good strong password here, but if you like during the setup period you can run root without a password to speed things up when logging in. Just remember to lock down root with a good strong password later if you do. Now the last thing it will ask you is if you want to visit the general configuration menu again. No should already be selected, so just hit enter. Now you'll find yourself back at the original install menu from where you started. Just right arrow over to "Exit Install" and hit enter. Be sure to remove any disks at this point and hit enter.

Whew! That was a lot of work for certain, but don't fear. All that work you've just gone through will pay huge dividends later on, so every step was worth it. Now we'll move on to setting up the system and properly securing it for eventual use.
Post install setup

Ok, now that we've done this, let's move on to the part we came here to work on.  Once your system boots, login as root.  Root uses the CSH shell by default.  If you'd like to use bash at this point, just type "bash" at the command prompt and hit enter.  Believe me, it's a better shell than CSH and easier to work with.  The first thing we need to do is to secure and setup our basic system.  Type "pico .bashrc" and hit enter. This will use Pico for editing your .bashrc file. Type the following two lines.

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:$HOME/bin; export PATH
PS1="[\u@\h \W]\\$ "

Do "ctrl-x" then "y" then enter to save.  Type "cp .bashrc .bash_profile", hit enter.  This has now created your login configuration files for both types of logins.  AKA, via the console and ssh.  Now you'll need to copy these two files up to your admin user so they can have them as well.  To do that, do these three commands and replace "username" with the name you gave your admin user:

* cp .bashrc /home/username
* cp .bash_profile /home/username
* chown username /home/username/.bash*

Next, we'll want to upgrade our ports collection and source tree using cvsup. But before we can do that, we need to create our configuration file. Type the following commands:

* cp /usr/share/examples/cvsup/stable-supfile .
* pico stable-supfile

Now that we're inside the cvsup config file, we'll want to do a couple of things.

* About halfway down, find "*default host" and change the entry "CHANGEME.freebsd.org" to a cvsup server that is closest to you, or the least congested. A list of available servers can be found at: http://www.freebsd.org/doc/handbook/mirrors.html
* Go further down and find the following line: src-all.  Below it, add this on a separate line: ports-all tag=.

Don't forget the dot on the end or else it won't work right.  Ok, that's it. Just save and then type "cvsup stable-supfile" to begin updating your source and ports trees. This can take anywhere from 15 minutes to an hour to complete as it's got a lot of work to do. It may take longer if you're on a slow internet connection or the servers are full due to a recent release of any of the BSD's. In the future, unless you go a long time between updates, this update will typically only take you about 3-15 minutes to complete as the first update is always the biggest.

Now, while that's working, let's jump into another terminal window and do something else. Press "alt-f2" to get into a new tty terminal. You'll see the screen change to a login prompt at this point. If you want to get back to the first terminal to see how it's doing, just press "alt-f1". The first security measure we'll need to achieve is more a deterrent than an actual security measure. But it's handy none the less. Type "pico /etc/motd" and hit enter. Remove anything that is in there and copy this in.

* * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * *
THIS SYSTEM IS RESTRICTED TO AUTHORIZED USERS FOR AUTHORIZED USE
ONLY. UNAUTHORIZED ACCESS IS STRICTLY PROHIBITED AND MAY BE
PUNISHABLE UNDER THE COMPUTER FRAUD AND ABUSE ACT OF 1986 OR
OTHER APPLICABLE LAWS. IF NOT AUTHORIZED TO ACCESS THIS SYSTEM,
DISCONNECT NOW. BY CONTINUING, YOU CONSENT TO YOUR KEYSTROKES
AND DATA CONTENT BEING MONITORED. ALL PERSONS ARE HEREBY
NOTIFIED THAT THE USE OF THIS SYSTEM CONSTITUTES CONSENT TO
MONITORING AND AUDITING.
* * * * * * * * * * * * W A R N I N G * * * * * * * * * * * * *

Save and close.  Now, to protect it from writing, type "chmod 444 /etc/motd" and hit enter.  That'll make the file read only.  Now type "pico /etc/aliases", hit enter and then scroll down until you find "# root: me@my.domain". Remove the # sign from the front of this line, then change "me@my.domain" to your email address.  If you wish to keep all mail from root local to your machine instead of piping it out onto the internet first before retrieving it, you can specify a local user instead, such as the admin user we setup earlier.  Now, save and close. Now type "newaliases" at the command prompt. This will load the new aliases into the system. All mail, including daily logs, error messages (where applicable) and other root mail will now get sent to you.  

Next, we need to setup SSH.  There are two ways to do this.  The first is the standard setup that allows both ssh and SCP through standard windows ssh and scp programs such as putty and winscp, as well as similar linux programs as well.  The second is a far more secure way to setup ssh that restricts your usage only to ssh programs such as SecureCRT and Linux ssh which can support OpenSSH secure keys.  SCP is possible, but not on windows, and only via the console in Linux as there are currently no graphical scp capable clients that I'm aware of that support OpenSSH keys.

For the standard ssh setup, you'll need to open your sshd_config file and make a few changes.  To do that, we'll first want to backup our sshd_config file in case we make a mistake or break something.  Type "cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup" and hit enter.  This will create a backup copy of your sshd_config file as it originally appeared on your system.  Now type "pico /etc/ssh/sshd_config".  Now do each of the following steps to setup sshd to allow the most common connections while remaining secure.  When asked to comment something out, add a # sign at the front of the line.  When asked to uncomment something, simply remove the # sign.

* Line 19 - Uncomment this line.  It should read "Port 22".
* Line 20 - Uncomment this line.  It should read "Protocol 2".
* Line 42 - Uncomment this line.  It should read "PermitRootLogin no".
* Line 61 - Uncomment this line.  It should read "PasswordAuthentication no".  Change "no" to "yes".
* Line 62 - Uncomment this line.  It should read "PermitEmptyPasswords no."

Now, save and exit.  Next, type "killall -9 sshd" to force kill the ssh daemon.  Next, type "/usr/sbin/sshd" to restart sshd.  If you did it right, it should start immediately.  When you hit enter, if it starts right, you should immediately drop back to a command line.  It will only give you feedback if there's an error in your config file.  Now, try logging into your server from another machine via ssh to see if it works.  If you can login successfully, you've done your work right.  Now, if you want the more secure setup, just clear out the entire sshd_config file and add these lines:

# SSHD config file for my server

############################
## Base SSHD config settings ###
############################

Port 22
Protocol 2
HostDsaKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 120
KeyRegenerationInterval 3600
PermitRootLogin no

############################
##  Hack prevention  code  ######
############################

# After 3 unauthenticated connections, refuse 50% of the new ones, and
# refuse any more than 10 total.
MaxStartups 3:50:10
# Don't read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
KeepAlive yes

###############
##  Logging #####
###############

SyslogFacility AUTH
LogLevel VERBOSE

############################
## Host Authentication #########
############################

# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# RSA authentication
RSAAuthentication yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
ChallengeResponseAuthentication no

##############################
## Secure ftp and authorized users ##
##############################

Subsystem    sftp   /usr/libexec/sftp-server
AllowUsers username
UsePrivilegeSeparation yes

On the second to last line where it says "AllowUsers username", change "username" to be the username of your admin user.  They will be the only one allowed to login via ssh.  If you have more than one admin user, put in each username after the first separated by a space.  Now, the next thing you'll have to do to make use of the more secure ssh session is to generate a public key for logging in.  To do that, type the following:

* su - username (where "username" is the name of your admin user)
* ssh-keygen -d (you'll be prompted to setup a password for decrypting the key so as to prevent unauthorized use.  I highly recommend specifying at least a good strong 8 character password here)
* cd .ssh
* cat id_dsa.pub > authorized_keys

Now, what this has done is generate your public and private key pair for secure login into the server.  The secure ssh configuration file I listed above is designed to work with this key pair.  You'll want to backup your key pair onto an external storage device such as a floppy or a pen drive.  If you want to back it up to a floppy, you'll need to log out of your admin user and go back to your root login.  Next you'll need to do the following steps:

* mkdir /mnt/floppy (this will create a folder where you can mount your floppy disk)
* mount -t msdos /dev/fd0 /mnt/floppy (floppy disk must be dos formatted)
* cd /mnt/floppy
* cp /home/testuser/.ssh/id_dsa* . (this will copy your files over to the floppy disk.)

Now you can type "ls" to make sure the files are there.  After this, type "cd .." to get back to root's home directory and then type "umount /mnt/floppy" to unmount the floppy so you can take it out and store it somewhere.  

Now, to do this with a pen drive, you'll need to do the following steps.

* Insert the pen drive into a usb port.  You'll also need to be on tty0 to ensure that you see the USBD mount message when USBD has successfully seen your pen drive.  It will also alert you in the event that USBD can't load your drive.  When USBD reports your pen drive as successfully seen and added as a device, take note of what device it's listed as.  Look at the second line of the output from the USBD system message.  It should look something like this:

da0 at umass-sim0 bus 0 target 0 lun 0

Looking at this entry, you see "da0" as the first column.  That's your pen drive's device ID when dealing with partitions.  Write that down.
* Type "mkdir /mnt/pendrive" to create a directory where we can mount our pen drive.
* Type "mount -t msdos /dev/da0 /mnt/pen drive" and hit enter.
* cd /mnt/pendrive
* cp /home/testuser/.ssh/id_dsa* . (this will copy your files over to the pendrive.)

Now type "ls" to make sure the files are there.  After this, type "cd .." to get back to root's home directory and then type "umount /mnt/pendrive" to unmount the pendrive so you can take it out and store it somewhere.  When you remove the pen drive, you should receive another message from USBD stating that the device was lost and is now detached.  You can ignore that as that's a standard message indicating that the usb device was removed.  Now hit enter to see your command prompt again.  Next, do "cd /home/username/.ssh" to get to your admin user's ssh directory.  Type "rm id_ida*" to remove the two secure key files.  They should not remain on the machine for security purposes.  Now, from here on out, if you'd like to continue managing your server with ssh, feel free to.  It's best to set up the ssh clients you'll be using on whatever machines you'll be managing the server from.  Also, get used to doing it this way as that's how you'll be doing any management of your server from now on, save for emergency maintenance of any kind.  I say this because once we're done, you'll end up with a headless server that'll sit in a corner by itself connected to nothing but a power cord and an Ethernet cable.  That's essentially what a headless server is.  One that has nothing but power and Ethernet going to it.  It allows it to be tucked out of the way, out of sight and out of mind, but still fully usable by everyone on the network.

Now, the next step we need to do is to setup our extra drive(s).  If you only have one drive, you may skip this step.  To begin, we first have to create the directories where the drives will be mounted.  I prefer naming the directories after their purpose, or their use in the system.  For example, if it's going to be a drive for use as part of your file server where files will be stored, then "/samba" or "/storage" would be appropriate names.  If you want them to be designated by their place within the system, then use "/drive2" or "/driveb" or something similar.  For this tutorial, I'll be using the latter.  Type "mkdir /drivename" to create this.  Replace "drivename" with the name you've chosen for your second drive.  Repeat for any additional drives you'll be adding.  

Now to get started formatting and slicing these drives, type "/usr/sbin/sysinstall" and hit enter.  This will take us into a screen that looks very much like the setup screen we had during our initial install.  That's because it's the same sysinstall program that's found on the install disk.  If you've worked with freebsd before and remember this program being in /stand/sysinstall, you would be right.  In the 6.x line the developers removed the /stand directory and moved all its applications into other directories.  Hence why sysinstall is now under /usr/sbin.  Now back to the configurations.  Arrow down the list here and select "configure".  Hit enter.  Arrow down and select "Fdisk".  Hit enter.  You should be presented with two or more square checkboxes and several devices here.  We'll ignore ad0 because that's our primary drive.  Doing anything with that now would cause some rather unpleasant things to happen to our main system drive which would kill our install and force us to repeat all our previous steps.

So, select ad1 (or whatever your next drive ID is) and hit enter.  Partitioning at this point is the same as mentioned earlier for the main drive.  Just one gigantic partition.  Once you're done here, you'll need to do something a slight bit different than you did before.  Instead of typing "Q" immediately, you'll need to type "W" instead.  This writes the changes.  Before this sysinstall did it for us.  But that was because we were installing the system and that's the preferred way to do it.  This time you have to do it yourself.  Once it's done writing the partition, hit "Q" to exit.  Select "none" for the boot record and hit enter.  Repeat for each of your other drives if you have more than one extra drive.  If you have several drives built as a hardware raid, then all of the drives in that raid array will be seen by Freebsd as one drive and will be treated as such.  So no worries there if you have raid.  The next step is to create slices.  Arrow down one line to where it says "label" and hit enter.  Type "C" and hit enter.  This will select the entire drive as one huge slice.  Type "/drivename" where "drivename" is the folder name you picked for where your second drive will be mounted.  

Now, type "W" to write the changes, and "Q" to quit.  Rinse and repeat if you have more than one secondary drive.  DO NOT touch the primary system drive at any point during this install.  If you're unsure whether you're in that drive or not, be sure to take note of the size of each drive in your system and verify by size in each of the windows that the drive you're working with is in fact the correct one.  Available space on each of the drives is always listed in each of the windows.  Also be sure to note the part ID for each drive.  The part ID will typically be next to the name and will say something like "/dev/ad1s1a" or something like that.  Write that down for each drive as we'll need it for later  Once you're done slicing each drive, arrow up to "exit" and hit enter.  Now right arrow and select "exit install", and then hit enter.

Now, we need to insert each of these drives into our file system configuration file so that they're automatically mounted at boot.  The first thing we need to do is test and find out if each of your drives mounts right.  For each drive, type "mount -t ufs /dev/partid /drivepath" where "partid" is the part ID the system gave you when you created your slice for that drive.  /drivepath of course is the folder name you created earlier for that drive.  Now, if all goes well, you shouldn't see any errors.  If you type "df -h", you should see your newly mounted drive in the list of available slices in this screen.  To verify that, look under the "Mounted On" column for the directory path it should be mounted on.  If you hit any errors, go back and correct them before continuing.

Now, once you're sure each drive is working, unmount them by typing "unmount /drivepath".  Next, type "pico /etc/fstab".  This will take you into your filesystem configuration file.  One thing to note is to be sure that you don't make any mistakes in here because ugly things can happy if you do.  It won't break your system beyond recovery, but it will force you to go through the bad boot recovery process to fix it.  And believe me, that's no fun at all.  Now, the first thing you will want to do is arrow down to the bottom of the file and put your cursor on the first available free line.  To add in each drive you'll first want to type the device id.  That'll be like we had before where it was "/dev/devid" where "devid" is the part ID that was shown to you in the label editor.  Next, you'll want to hit tab until your cursor lines up with the "MountPoint" column.  This will be the folder name you wanted to mount your drive on, such as the "/drive2" example I gave before.  Now tab over to the "FStype" column and type "ufs" since your file system is UFS.  Hit tab and type "rw" so that your drive is both readable and writable.  Tab over to the "Dump" column and type "2", then tab over to the "Pass#" column and type "2".  Hit enter and repeat for any other drives you need to add.

Now, save and exit.  If you've done your work right, you should be able to type "mount /drivepath" for each drive and it should mount successfully.  After this you shouldn't need to manually mount the drives anymore.  If you encounter any errors, go back and look in the file and correct any errors or typos you might have left behind.  

Now we need to configure our hosts file.  To get started, type the following command:

* pico /etc/hosts

Now in this window we'll need to make one addition to the hosts file so that when sendmail starts trying to send mail to local users, it doesn't get confused as to where to send it.  Go to the bottom of the file, create an empty line, and type the following:

* x.x.x.x       myserver.domain.com

Replace x.x.x.x with the IP of the server and "myserver.domain.com" with the hostname of the machine.  Now save your work and exit.

Now, the next thing we need to do to finish preparing our system is to upgrade it to the latest version of everything.  The first thing you'll want to do is to verify that cvsup is finished with its work as we can't continue till it is.  Press "ctrl-f1" to switch back to the first terminal and check on it.  If it's back to a command prompt, we're ready.  If not, let it run until it does.  Once it's finished, we can then move on to the next step.

When it's finally finished, type the following commands:

* cd /usr/ports/ports-mgt/portupgrade
* make install
* Tab down to the "OK" button and hit enter.

This will install the latest version of portupgrade from the ports collection.  Since it has to compile, it's going to take a little bit of time to complete, so go grab something to eat or drink at this point.  The whole install should take about 5-15 minutes depending on the speed of your machine.  Once this is done, type "portupgrade -r -all", then walk away again.  Depending on how much needs to be upgraded on your system, it could take anywhere from 20 minutes to 4 hours as it will have to build and compile each item from source code.  Be sure to check in on it about every 15-20 minutes in case it prompts you to select some options.  Unless you have a specific reason to choose something other than the default options on any of the configuration prompts, just tab down to OK and hit enter to continue on each.  You likely won't see any of these screens along the way, but if you do, you'll need to address them in order to continue.  

Once this is done and all upgrades have completed successfully, you are ready to move onto the last step which is a kernel rebuild.  But before you do, be sure everything upgraded correctly under portupgrade.  To do this, type "pkg_version -L=" and see if it reports anything.  If it does, rerun portupgrade until nothing appears when you run that command.  Entries will look something like this:  "ruby    <" indicating it's an out of date version.  If a port fails to build, find out why and try rerunning the install manually by changing directories to the port in question (the directory path will be listed in the error message) and running the install manually by typing "make install".  If you're unsure of how to fix an error, do a little google diving.  Just take part of the error message and type it into google.  You'll usually find a quick fix or an answer to why it's not compiling.  Although I don't expect this to happen, since there is a small chance of it occurring, I thought to mention it just in case.  

Once all your ports are upgraded, type the following commands to rebuild your kernel.

* cd /usr/src
* echo "KERNCONF=GENERIC" >> /etc/make.conf
* make buildworld
* make buildkernel
* make installkernel

Since we don't need to customize our kernel, we'll just be using the generic Freebsd kernel configuration file for this.  What the kernel rebuild does do however is it takes us up to the latest kernel version for added security.  Total rebuild time will vary between 20 minutes and an hour depending on your system.  In extreme cases it may take as much as two hours.  Once this is completed, reboot your computer by typing "shutdown -r now".  Once it's rebooted, login as root again so that you're ready for the next steps.  At this point our post install setup is done.  This will have all your drives in place and your system secured.  Now we move on to the next part.  Setting up the file server.  At this point I recommend setting up the server where it's supposed to be and doing the remainder of your configurations via ssh.  To do this, just power down the system by typing "shutdown -p now" and hit enter.  Once it powers down, unplug everything, move it to its final home, plug in the power and Ethernet, and then power it back on.  After this you'll be able to connect to it with your favorite ssh client.  To connect from Linux, BSD or another unix style ssh client, type the following command:

For standard ssh configuration:
* ssh -l username x.x.x.x (you'll be prompted for the

For ultra secure ssh configuration:
* ssh -i /path/id_dsa x.x.x.x

In the above examples, "x.x.x.x" is the ip of your server, "username" is your admin user's username, and "/path" is obviously the path where you put the ssh keys on the machine you're using.  I typically recommend putting it into the .ssh folder under your admin user's home folder so as to keep everything related to ssh in one neat and tidy place.  For windows or mac, you'll need to enter the IP, username, and password for the standard configuration, and you'll need to specify the IP and use "PublicKey" as the authentication type for logging in.  You'll also need to set "SSH2" as the protocol for both.  Now, let's move on to setting up the file server.
File Server

Setting up Samba is pretty simple.  Since the latest version of any application tends to be the most secure, and since packages tend to be somewhat dated, we'll want to build all our current applications from ports rather than installing from packages.  This might take longer, but since we're shooting for security to be the top item in our design, it's the better approach.  To get started, you'll want to do the following commands:

* cd /usr/ports/net/samba3
* make install

After the install completes, you'll want to configure samba.  The first place we want to go is to setup the smb.conf file itself.  Since this is Freebsd and it's file system is structured slightly differently than Linux or some other systems, the smb.conf file is not going to be where you expect it (if you're a user coming from Linux or another operating system).  To get started, you'll want to:

* cd /usr/local/etc
* pico smb.conf

Now once you get into this file, you'll notice that it's empty.  That's because there's no default smb.conf file in this directory.  You'll have to make your own.  Here's an example configuration file:

#========== Global Settings ============
[global]

# Microsoft Windows workgroup
  workgroup = mygroup

# Custom server share name
  server string = FileServ1

# Hosts samba should allow
hosts allow = 192.168.10. 127.

# this tells Samba to use a separate log file for each machine that connects
  log file = /var/log/log.%m

# Put a capping on the size of the log files (in Kb).
  max log size = 50

# Security mode.
  security = user
  guest account = nobody

#=========== Share Definitions ===========

# This is for Mother
[mom]
  comment = Mom's Files
  path = /drive2/mom
  read only = no
  public = no
  writable = yes

# This is the common share directory.
[public]
  comment = Shared Public Directory
  path = /drive2/public
  public = yes
  writable = yes
  read only = no
  guest ok = yes
  force directory mode = 0777
  force create mode = 0777
  force group = nobody
  force user = nobody

Now you can always use the existing configuration file as an example if you'd like, but you don't have to.  If you'd like to view this file, just switch to another console (or if you're ssh'ed in by now, just open a second copy of your ssh program and start a second connection to the server) and type:

* pico /usr/local/share/examples/samba/smb.conf.default

That'll give you the example file to look at with lots of examples of extra things you can do with Samba.  While this isn't all of them, it's a start and will allow you to get a general idea of what options are available.  To find out more, simply go online and search for "samba configuration".  There's tons more you can do with Samba if you'd like.

Now, back to our example configuration file.  Here's a breakdown of what each part does for you.  The "Global Settings" section are settings that apply to everyone.  The first three are self explanatory, with one exception.  The IP's that Samba should allow should be formatted in a simple one, two, or three octet format.  For example, up above, I want anyone with a 192.168.10.x address to connect to the server.  So any of the 256 addresses within that octet can connect.  Same with 127.x.x.x, which of course is localhost.  While you may not think you'd need it, it is advisable to have it so as to keep Samba happy.  The forth line, dealing with the separate log files, may or may not be something you want.  Personally I think it's a good idea, because it isolates any problems you have to a single IP and allows easier troubleshooting.

Item five is optional.  What it does is it keeps log files small and rolls them over if they exceed a given size.  This is only needed if you don't want to fuss with huge log files.  If you never expect to be in the log files, leave this at 50k.  If you plan to be in them often, or at some point, set it at anywhere from 150k to 500k.  But never leave the logs set at unlimited.  If you don't roll over the log file at some point, you will fill up your drive with logs.  If you're unsure of how big to make it, leave it at 50.  If that proves too small at some point, you can always increase it.  Line six is for the security modes.  This is very important.  For the first line labeled "security = user", that's best left as is.  To understand this better, you'll need to realize that there are two basic security modes.  They are "user", which restricts everything to user logins and personal file space.  The second is "share" which opens up a particular directory you specify to be open to everyone without requiring a login.  You can also set user directories to be publicly accessible without a password this way too, which isn't good security practice and thus is not recommended.

The second option is "guest account".  This should only be used if you plan to have an open, public directory with no password required for access.  Now, the next section is the share.  This is the individual shares in Samba.  The first one you want to do is the one I've labeled "Mom".  That label serves two purposes.  One, it gives a name to the share on the network, and two it gives you an identifier to work with.  The comment line below it does nothing for Samba, but it does give you a place to note what this is for.  Supposedly it's also supposed to be viewable over the network as part of the share info, but I've never seen where it's supposed to show up.  The next part is the path.  This is where the files are to be stored.  As you can see in my example, since "drive2" is our storage drive that we have attached to the system, that's where I've decided to put all my users.  At least for this example.  Each user has their own folder in /drive2 and thus are named accordingly with the title I put them under.  So mom has the "mom" directory, dad would have the "dad" directory and so on.  The titles, as stated above, would work in approximately the same way.  Keeping your naming conventions consistent will also help you a lot later on down the road and will help avoid confusion.

Say for example, if I had a roommate who wanted space on the file server, I'd create an entry for him and put his name on the folder accordingly.  This just makes later troubleshooting easier to do and allows you to more quickly isolate any offenders who might be trying to store every file in existence on your file server.    Now if that does get out of hand, setting quotas is a bit more involved and requires a kernel rebuild as quotas aren't configured by default.  If you're interested in doing this, you may want to create a custom kernel and follow [url=this guide]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/quotas.html[/url] to setting up quotas in Freebsd.  It's not that hard, but it does involve some extra work, and since most people won't be using them, I've skipped that step in this guide.

Now, moving on.  "read only" allows you to set a specific share to be read only.  This allows an admin to put files into there through other means (such as through the console, ssh, or another share attached to this one) and allow other users to download it, but not modify it.  The "public" option allows you to set the share as publicly viewable.  Since we don't need that, we'd set that to no so that it doesn't appear as one of the available shares on the network.  It's still accessible, but you'd need to know the access path to get to it.  Typically that would be "//servername/sharename".  For example, "//fileserv/mom" would be one valid example.  The last option is complimentary to the "read only" option and allows you the user to write files to the folder or delete them.  If you want users to be able to write to the directory, you can safely leave out the "read only" option in your configuration.

Now the "public" share is the common shared directory for the entire system.  Anyone can get into here without a password.  The kicker here is, if you want this kind of unsecured directory, you have to change your security from user to share, or else you won't be able to use this directory without a login.  As you can see, all the options here are pretty much the same, but "public" is set to yes (thus allowing public access to the folder by anyone) and "guest ok" is set to yes.  The last four options you see on this section are required for this kind of login.  It allows files to be handled properly in the directory so as to keep Samba, and Freebsd, happy.

Once you're done with this, save the file and exit.  If you decide you want to change something, you can come back later and edit this file anytime.  You can also add printers into your samba conf if you want, as well as locking down shares to one specific user, and one user only.  But that's up to you if you want to do that.  A simple browsing of the smb.conf example file will give you plenty of examples on how to do this.  Now, the next thing we need to do is to create users.  The first step is to create the user in Freebsd.  This can be done either from the command line, or from sysinstall.  Since the second is quicker and easier, since it's a graphical install, we'll use that.

Type "/usr/sbin/sysinstall" to get into the configuration program for Freebsd, then select "configure" and scroll down to "user management".  This should look familiar to you as it's the same interface that was used to add your admin user.  Just select "user" and hit enter.  Fill in the login ID and password, change the full name to something you remember, and then set the home directory to be whatever their share directory will be.  If they're going to be allowed to ssh into the box, then let sysinstall set a default directory for them under /home and set their samba directory as something different.  So for example, if I was to add mom to the system and I wanted her to have samba access, but not system access, I'd put "/drive2/mom" for the home directory and "/sbin/nologin" in for the login shell.  If I did want her to have that kind of access, then I'd leave the home directory untouched and put in an appropriate shell such as "/usr/local/bin/bash" under the shell field.  If you use the shell of "/sbin/nologin", it'll give you the error message that no such shell exists when you click ok.  Just tell it that's ok and then add any other users you want to.  Lastly, we'll need to add these users into the samba password file.  Samba uses its own separate password file separate from the system, so you'll need to setup an entry for each person wanting to have a login on the system so that they can get into their shared directory.  To do this, type:

smbpasswd –a username

It'll ask you for the password twice, then it'll add the user.  After you're done here, go ahead and test your shares to make sure they work.  Don't forget to restart samba anytime you make any changes to the smb.conf file or else they won't take.  To do this, you'll need to type these commands:

* /usr/local/etc/rc.d/samba.sh stop
* /usr/local/etc/rc.d/samba.sh start

This will stop and restart Samba so you can begin using it with your new configuration changes.  You don't need to do this if you add more users.  Only if you make changes to the configuration file.  Next, open up /etc/rc.conf and add the following line at the bottom:

samba_enable="YES"

This will enable samba at startup.  Now at this point we'll move on to the mail server.
Mail Server

Getting started with the mail server part is easy.  Since this is a fetching mail server, we won't need to replace sendmail and can use it exactly as is to do what we need.  If this were a receiving mail server, sendmail would have to be replaced for security reasons.  But since it's not, we don't.    The one thing you'll want to note about this is since this is both a mail and a file server, you'll want this tucked behind a firewall or a router running nat (the server will need to be put on a private IP range behind the router in order to be protected by nat) and inaccessible by the internet, save maybe through ssh, and even then, ssh should be run on a port other than the standard port 22 if you're going to allow ssh access to the machine over the internet.  Now, the first program we'll want to install is Qpopper.  It's a very dead simple and extremely handy little pop3 program.  To install it do the following commands:

* cd /usr/ports/mail/qpopper
* make install

When the general configuration window comes up, be sure to select "standalone_mode".  It should be second from the bottom and will be needed to make qpopper run as a daemon.  Otherwise you'll need to run it from inetd, and we'd like to avoid that.  Once it's installed, to start it automatically, you'll need to create a simple sh file to do that.  Do the following commands to create this file:

* cd /usr/local/etc/rc.d
* pico qpopper.sh

Once in the file, type "/usr/local/libexec/qpopper", then save the file and exit.  Next you'll want to set permissions of 755 on the file to allow it run.  To do that, type "chmod 755 qpopper.sh" and hit enter.  To test this and see if it works, do "./qpopper.sh".  If it drops straight to the command line with no errors, you did your job right.  Now that that's done, we'll need to setup sendmail to allow you to send mail properly.  The first thing we'll need to do is setup relaying.  Type the following to get started:

* cd /etc/mail/
* pico relay-domains

If you notice, the file is empty.  That's because it doesn't exist and we need to create it.  Doing what we're doing does that.  Now you'll want to put the following two lines into your relay-domains file:

192.168.10
127.

Notice I left off a few numbers?  The first example assumes you're using a subnet of 192.168.10.0/24, so therefore the last dot and last octet are left off the ip address to allow that whole block to connect and relay mail.  The 127. indicates that any local address on your network or the machine can send mail through your server.  If you make it just 127.0.0.1, then only the local machine can, but nothing else with a 127 address can.  Now save and exit.  The next thing we would typically setup is the access list.  Since this is a fetching mail server and not a receiving, we don't want to set that up because sendmail will get real unhappy with us if it's fetching mail and it hits a blocked sender.  Now, after this we'll want to go and install fetchmail.  This will be the program we'll use to download our mail.  It's what gives this type of mail server its name.  

To install fetchmail do the following:

* cd /usr/ports/mail/fetchmail
* make install

Now we'll want to setup fetchmail.  To do this, do "cd" and hit enter to get back to your root directory.  Now type "pico .fetchmailrc" and hit enter.  You'll start with a blank file.  You'll want to insert the following lines:

set logfile "/var/log/fetchmail.log"
set postmaster "root"
set no bouncemail
set syslog

defaults no dns, protocol pop3, options fetchall, no keep

poll mail.youdomain.com no dns
       user 'username' there with password 'password is
       username here

That's your basic fetchmail configuration file.  The only lines you have to touch are the last three.  So let's look at each of these three.

* poll mail.youdomain.com no dns

This tells fetchmail to connect to an outside mail server of your choice.  Say for example, your mail went through Joe's Internet Service and their primary incoming mail server was "mail.joesisp.com".  Then that line would look like this:

* poll mail.joesisp.com no dns

The "no dns" part is there to save fetchmail some time and not bother with looking up anything that's coming in.  It makes things download faster and helps keep sendmail happy.  Next, you'll want to setup your login info for the mail server.

* user 'username' there with password 'password is

This sets up your username and password in the configuration file for getting mail.  Just put your username and password here, then we move on to the next line.

* username here

If you notice, this is technically a continuation of the previous line.  I only keep it on a separate line because it makes it easier to keep things organized, because this way I know that the first line is for the mail server, the second for the login info, and the third is for where mail is to be delivered.  You can repeat these three lines with different info for each mail account you need to download mail for.  Note, if you have no valid user for delivering mail to locally, no mail will be delivered and fetchmail will throw a fit.  So whatever you set your "username" field for in the third line, be sure there's a valid, active user on the system with that name.  That's also the name they'll use to get their mail.  If they don't have an account yet (you should have created samba space and logins for everyone wanting/needing to access the file server by now) then you'll need to add it when you're done adding them to this file.  You'll want to be sure to create one fetchmail entry for each user retrieving mail via your server.

Now, save and exit.  The next thing you'll need to do is to first make sure that you secure the file, then make sure fetchmail can read it.  To do this, change the permissions to 740 by typing "chmod 740 .fetchmailrc", then type "fetchmail –c".  If it returns no errors, then you're ok.  If not, you may have to either slacken the permissions on the .fetchmailrc file or add fetchmail to the wheel user group.  To add fetchmail to the wheel group so that it can view the fetchmailrc file, type this command:

* pw usermod fetchmail –G wheel

At this point, fetchmail should be able to read the file without a problem.  Now, we need to add procmail.  This is a program that will serve two purposes.  The first is to help filter mail locally that is fetched, and the second is to help spam assassin do its job when we get it installed.  So to install procmail, do the following two commands.

* cd /usr/ports/mail/procmail
* make install

While it's installing, we can go ahead and make our procmail configuration file.  Go into another console (if using ssh, just change windows or open a new session and login.  If still working from the console, remember, use ctrl-f1 through ctrl-f8 to switch between ttys), login if needed, then type "pico .procmailrc".  Since this file will be empty, you'll want to add the following example file and tweak it.

# The ever wonderful logfile
LOGFILE=$HOME/procmail.log

# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 8000000
# | /home/user/bin/spamassassin
| /usr/local/bin/spamc

# flag all spam messages.
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
{
:0
* ^Subject:[    ]*\/[^  ].*
{
  :0hf
  | formail -I "Subject: [Spam!] $MATCH"
}
}

# All mail tagged as spam (eg. with a score higher than the set threshold)
# is moved to "probably-spam".
:0:
* ^X-Spam-Status: Yes
{
:0
* ^Subject:[    ]*\/[^  ].*
{
  :0hf
  | formail -I "Subject: [Possibly-Spam] $MATCH"
}
}

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped.  This will re-add it.
:0
* ^^rom[ ]
{
 LOG="*** Dropped F off From_ header! Fixing up. "

 :0 fhw
 | sed -e '1s/^/F/'
}

Now that we've done this, the next step is to put a copy of this into each user's home directory.  Now if everyone's mail is delivered to a single mail account, you'll need to do things slightly differently.  What I mean by this is that all the email accounts on a given domain will be redirected to one single mailbox through the use of forwards.  So for example, if they had an alias setup to forward mail from "bob@domain.com" to "centralmbx@anotherisp.com", the mail would first go to the "bob@domain.com" address and then be handed off to "centralmbx@anotherisp.com" which is the valid, live email address while the first address is simply a forward that handed mail off to another email address.  If ten, twenty, thirty or more users are all dumping mail into that one mailbox via forwards or other means, life can get a bit problematic when you want to download and deliver those messages to individual users.  Normally a mail program would be assigned to sort out each message into a separate mailbox for each user based on the different email addresses in the "TO:" mail field.  But if you want everyone to have their own separate mail programs and accounts, things get a bit trickier.  So once again, procmail comes to the rescue!

To sort all mail coming in through this one mailbox into individual user mailboxes locally, you will need to add the following lines for each user:

#----------Mail for username ---------
:0
* ^X-Envelope-to:.*user@yourdomain.com
! localuser

The "user@yourdomain.com" would be the email address of one of the people you're receiving mail for.  In our example above, we used "bob@domain.com".  We'd use that again here.  "localuser" would be the local username that each message addressed to "bob@domain.com" needs to be delivered to.  Once it lands in their mailbox, it's there for them to check whenever they want.  Once you're done adding each of these, save your work and then switch back to your first console.  (ctrl-f1 if by console, or alt-tab if using ssh) to check and see if procmail is done installing.  If it is, then we can move onto the next step, which is to install spam assassin for spam filtering and clamav for virus filtering of email.  To do that, type the following:

* cd /usr/ports/mail/p5-Mail-SpamAssassin
* make install
* touch /var/log/clamav/clamd.log
* chown clamav /var/log/clamav/clamd.log
* cd /usr/ports/mail/p5-Mail-ClamAV
* make install

Now, we just need to setup spam assassin to run with sendmail.  But to do this, we actually need to tell it to pass the mail through procmail first.  To get started, type "pico /etc/mail/sendmail.cf" and hit enter.  You'll then need to search for "Mlocal".  To do this, press "ctrl-w", type "mlocal", then hit enter.  You should find a set of lines that look a lot like this:

Mlocal,                P=/usr/libexec/mail.local, F=lsDFMAw5:/|@qPSXfmnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
              T=DNS/RFC822/SMTP,
              A=mail.local -l

You'll want to comment out those three lines and replace them with this:

Mlocal,         P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
               T=DNS/RFC822/SMTP,
               A=procmail -Y -a $h -d $u

Save and exit.  Now, type "pico /etc/mail/freebsd.mc" and hit enter.  You'll want to scroll to the end of the file and add these three lines:

INPUT_MAIL_FILTER(`spamassassin',`S=local:/var/run/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
INPUT_MAIL_FILTER(`clmilter', `S=local:/var/run/clamav/clmilter.sock, F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clmilter,spamassassin')dnl

Save and exit.  Now, if everything worked right, your mail server should be setup.  To test it, type "pine" and hit enter.  You'll be greeted by a welcome screen. Just hit E to exit this screen.  Now, to compose a test email, press C, then type the username of your admin user and tab down to the subject line.  Put something in there, then tab down and put something in the body.  Just putting the word "test" in the subject and the body should be sufficient.  Now, type "ctrl-x" and "Y" to send.  Now switch to your second console (ctrl-f2), type "su – username" (username = your admin user), and enter your password to login as your admin user.  Now type "pine" to view your mail for this user.  If everything worked right, a message should be there waiting for you.  If not, open pine and see if a bounce message is in there.  If not, check your regular email account where root's mail is forwarded to.  If there's any errors, you can take the diagnostic messages created by the bounce mail and make the adjustments necessary to fix them.  But if all went well, you have one last test.  Open an email client and set it up to receive mail for your admin user.  

The settings you'll use will be the following.  For the incoming and outgoing mail servers, put in the IP address of your mail server.  For the user and pass, put in the username and password for your admin user.  Now, check the mail.  You should receive one message.  If you open it up and view the headers (there are numerous ways to do this depending on the mail client) you should see two key trademark items.  The one that tells you if spam assassin is working is several lines with "X-SPAM" at the beginning.  The second will be to look for some lines starting with "X-Virus".  If both are there, then your spam and virus filtering is working.  

Now that we've achieved all of this, you have a couple last steps to do.  First, type "fetchmail" to run fetchmail from the console.  If there's any mail to be downloaded for the accounts specified in your fetchmail configuration, it should do this right now.  If you have any accounts that are drastically important and you can't afford to loose any mail in them, don't include them in the fetchmail file just yet.  I recommend working with one account that you can afford to make mistakes with.  This will mean removing all the other entries temporarily until you're sure everything is working.  If you don't care what happens to the mail in the other accounts, then you should be ok to proceed without any further tinkering.  Now, once fetchmail finishes running, just type "pine" and see if anything arrived.  Since we're doing testing, I recommend setting the admin username as the delivery location for at least one of the email accounts to help in troubleshooting   Especially if the other users on your server don't have ssh access or local login privileges.  If there's mail in the inbox when you open pine, (to see if there is, just type "i" to see the index of the inbox) then fetchmail is working.  

If you don't see any, try sending an email to the account which you're using for testing, wait a few minutes for it to be delivered, type fetchmail again, and then check pine again.  If it still isn't there, then you may have other issues.  One of these may be that your ISP doesn't allow you to use any other mail server except their own.  If that's the case, then you will need to specify their mail server as the outgoing mail server in your email client and try again.  You'll also need to change the entry for root in the aliases file to point to your local user account instead so that your daily logs and all root mail is delivered locally so that it can be properly sent and received.  If you've received mail in that account and all is good, we'll need to automate this for the future.

To do this, we need to add fetchmail to the crontab so it's run on a regular basis.  Type the following command to begin:

* pico /etc/crontab

Now, go to the bottom of the file and find an empty line.  You'll want to put in an entry like this:

* */10    *       *       *       *       root  /usr/local/bin/fetchmail -s

What this does is it checks for mail every ten minutes.  In this example, the "*/10" signifies to cron that you want to run this command every 10 minutes.  If you want this to run more often, you can lower this number to whatever you want, or you can raise it too if you like.  I really wouldn't go much lower than 3 minutes though unless you have a reason to, such as having to always be on top of mail as soon as it comes in.  If you keep it set to at least ten minutes, your ISP will thank you as it helps to lessen the load on their pop3 servers.  Due note that each star or entry is separated by a tab.  You can use the entries above yours as an example when putting your entry in.  Now save and exit.  

At this point, all your work is done.  Now all you need to do is add any other users you haven't already added, and then logout.  
Last Steps and Conclusion

I hope this guide has been very useful to you.  Once you have completed this tutorial, you may then enjoy your brand new mail and file server to your heart's content.  Just don't forget that you are now the admin of it.  Be sure to read your daily logs each time they come in and stay on top of any issues that may show up.  Typically this won't involve much, if anything.  But things do pop up from time to time.  If you do encounter something, be sure to check it out.  The internet is a great source for answers if it's something you don't know about.  Also, be sure to watch how much space is being used on each drive and try to address any space issues should any of the drive's reach above 80% capacity.  The only exception to this is the "devfs" entry.  That's going to say 100% right off the bat.  That's fine because it's supposed to say that.  The others shouldn't.

Also, if you plan to use your new server as your outgoing mail server as well, you have a couple more steps to complete.  However, if you never plan to use this server to send mail, then you have nothing else left to do.  But if you do, you'll first need to make sure your internet connection has a static IP.  Some broadband ISP's give them out by default.  Some don't.  If yours doesn't, then you'll need to request one.  Some ISP's charge extra for this, so be aware of that.  If they still refuse to give you one, then there's nothing else you can do.  If you can get one, the next step is to add your server into DNS.  In doing so, you will need to have two DNS entries created.  A pointer and an "A" record.  To do this you'll first need to add the server to a domain zone file.

If for example, you have your own domain name, I'd use it for part of the hostname so that it can easily be associated with your domain and added to DNS.  So if for example you had "tomscompany.com" as your domain name, your server could be named "fileserv.tomscompany.com".  You would then only need to add the following line to your domain's zone file to complete the first part of your two requirements:

fileserv        IN A             x.x.x.x
(replace the x.x.x.x with the IP of your internet connection)

If you don't own a domain, you may choose to use your ISP's domain instead.  While tricky and problematic, it is doable.  I say this because not all ISP's are nice enough to do this for you.  If they won't do at least this much, you're sunk.  If they will, then see if they'll do both entries for you.  Again, if they won't, you're sunk.  The reason is, if you plan to send mail with this server, you need both entries.  The first is a forward lookup, the second is a pointer record.  If they agree to do both for you, you'll need to have them add the following line into DNS for you.

x.x.x.x          IN PTR      hostname.domain.com

Now, within about 24 hours after they do this, DNS should have completely propagated and you should be able to resolve both the IP and the name without a problem.  After this you'll be able to send mail without any issues.  In the future, you may also have to add an SPF record in order to continue sending mail.  Since it's not pressing or required at this point to implement this system, you don't need to add this at this point if you don't want to.  But keep it in mind for the future.

Well, this ends my tutorial on setting up a Freebsd mail and file server.  Again, I hope it has been very useful to you and I hope that you can make great use of this in the future!  As time goes on and things change that will render this tutorial obsolete, I'll either update it, or write another article as an amendment with the necessary updated information.  If you have any questions about this tutorial, please feel free to ask in the forums.  Thanks.