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.
DragonFly ships with sendmail by default, but also support numerous other mail server daemons, just some of which include:
exim;
postfix;
qmail.
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 DragonFly Pkgsrc 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 DragonflyBSD.org DragonflyBSD.org mail is handled (pri=10) by crater.dragonflybsd.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 10.10.7.
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.
Contact the Documentation mailing list for comments, suggestions and questions about this document.