There are five major parts involved in an email exchange. They are: the user program, the server daemon, DNS, a remote
or local mailbox, and of course, the mailhost
itself.
This includes command line programs such as mutt, pine, elm, and mail, and GUI programs such as balsa, xfmail to name a few, and
something more “sophisticated” like a WWW browser. These programs simply pass
off the email transactions to the local “mailhost”, either by calling one of the
server daemons available, or delivering it over
TCP.
FreeBSD ships with sendmail by default, but also support
numerous other mail server daemons, just some of which include:
The server daemon usually has two functions--it is responsible for receiving incoming
mail as well as delivering outgoing mail. It is not responsible for the collection of mail using protocols
such as POP or IMAP
to read your email, nor does it allow connecting to local mbox
or Maildir mailboxes. You may require an additional daemon for that.
Warning: Older versions of sendmail have some
serious security issues which may result in an attacker gaining local and/or remote
access to your machine. Make sure that you are running a current version to avoid these
problems. Optionally, install an alternative MTA from
the FreeBSD Ports Collection.
The Domain Name System (DNS) and its daemon named play a
large role in the delivery of email. In order to deliver mail from your site to another,
the server daemon will look up the remote site in the DNS to determine the host that will
receive mail for the destination. This process also occurs when mail is sent from a
remote host to your mail server.
DNS is responsible for mapping hostnames to IP
addresses, as well as for storing information specific to mail delivery, known as MX
records. The MX (Mail eXchanger) record specifies which host, or hosts, will receive mail
for a particular domain. If you do not have an MX record for your hostname or domain, the
mail will be delivered directly to your host provided you have an A record pointing your
hostname to your IP address.
You may view the MX records for any domain by using the host(1) command, as
seen in the example below:
% host -t mx FreeBSD.org
FreeBSD.org mail is handled (pri=10) by mx1.FreeBSD.org
Receiving mail for your domain is done by the mail host. It will collect all mail sent
to your domain and store it either in mbox (the default method
for storing mail) or Maildir format, depending on your configuration. Once mail has been
stored, it may either be read locally using applications such as mail(1) or mutt, or remotely accessed and collected using protocols such as
POP or IMAP. This
means that should you only wish to read mail locally, you are not required to install a
POP or IMAP
server.
In order to access mailboxes remotely, you are required to have access to a POP or IMAP server. These
protocols allow users to connect to their mailboxes from remote locations with ease.
Though both POP and IMAP allow users to remotely access mailboxes, IMAP offers many advantages, some of which are:
-
IMAP can store messages on a remote server as well
as fetch them.
-
IMAP supports concurrent updates.
-
IMAP can be extremely useful over low-speed links
as it allows users to fetch the structure of messages without downloading them; it can
also perform tasks such as searching on the server in order to minimize data transfer
between clients and servers.
In order to install a POP or IMAP server, the following steps should be performed:
-
Choose an IMAP or POP server that best suits your needs. The following POP and IMAP servers are
well known and serve as some good examples:
-
qpopper;
-
teapop;
-
imap-uw;
-
courier-imap;
-
Install the POP or IMAP daemon of your choosing from the ports collection.
-
Where required, modify /etc/inetd.conf to load the POP or IMAP server.
Warning: It should be noted that both POP
and IMAP transmit information, including username and
password credentials in clear-text. This means that if you wish to secure the
transmission of information across these protocols, you should consider tunneling
sessions over ssh(1). Tunneling
sessions is described in Section
14.11.8.
Mailboxes may be accessed locally by directly utilizing MUAs on the server on which the mailbox resides. This can be
done using applications such as mutt or mail(1).
The mail host is the name given to a server that is responsible for delivering and
receiving mail for your host, and possibly your network.