Desktop FreeBSD Part 4: Internet Mail Setup

By Ed Hurst | Posted at 3:40 AM

The one thing that really fired up the development of the Internet as we know it today was e-mail. The protocols were designed back when the system itself was highly difficult to access, and security wasn't a significant issue. Since then, even your average household pet has heard of Internet security problems.

How many times have we read popular pronouncements not to use a certain popular e-mail program that is highly vulnerable to attacks hidden in messages? Those attacks are possible because the program is designed to make things so easy. It does everything for you. It's too easy for folks to forget the danger, because that's the software that came with their systems. That sort of large, do-it-all software takes up lots of resources, too.

There is a better way. It requires changing how you view Internet mail, going back to the original intent. In this case, it also means using what came with your system -- your FreeBSD system. However, be aware, if you do not have a mail server account with your ISP, or some other provider, you will probably have a difficult time using a built-in system mail server to send mail across the Net. Most mail services to whom you try to send mail will probably be blocking mail from dialup and DSL connections. If you cannot work this out, while you may learn a lot, you'll still be stuck using a regular mail client.

We will install Postfix and Fetchmail. You should already have Mutt for console email. None of these work directly from the graphical user interface (GUI), so we will spend some more time getting used the command line interface (CLI) environment. Recall the previous lesson on installing software from ports. Login as root and navigate to /usr/ports/mail/postfix. Follow the procedure for installing and running cleaning. Be sure to select the SASL2 option (not plain SASL) when the build options window comes up. When the installer asks, say "yes" to setting things up automatically. Then do the same for /usr/ports/mail/fetchmail.

To make sure Postfix is ready to run, we'll follow the instructions from the configuration file itself. Using Joe, open /etc/rc.conf and add these lines:


Then type these commands:

/usr/src/etc/rc.d/sendmail stop
/usr/local/etc/rc.d/postfix start

Hopefully, you'll see some messages about Sendmail stopping after the first one, and Postfix starting up after the second.

By the way, there is a reason we users of FreeBSD love the CLI. Aside from all the elitist talk of "pure computing" there is a very practical issue involved. If there is one thing likely to crash on any computer system, it is the GUI. GUI hardware is more likely to work poorly than any other hardware, so the software for it is much more difficult to write. Since we know Open Source systems run the GUI on top of the real heart of the computer, it is important that every computer user be able to work a little bit without the GUI, because you can still get most of your work done. It just requires knowing some things you haven't bothered to learn yet. If something in your system breaks, your best chance of getting by until it's fixed is to be ready to work in the CLI. Even better, some of the best software that exists works only in the CLI. And you may be surprised to learn that the mail server software in FreeBSD takes less power, and works better and more safely, than those big bloated GUI e-mail programs.


There are three parts to a proper e-mail system:

  • the mail handler or mail transfer agent (MTA)
  • the mail retriever which gets it from other machines
  • the e-mail reader and writer, called the e-mail client

Nowadays, you can add to the list a filtering agent if you need to deal with lots of different kinds of messages or have lots of spam. However, the main three can do that to some degree internally. The first two in our list above are the backbone of what mail servers all over the world do. We've already discussed how you shouldn't run Open Source systems without using the MTA, so it is built into every one of them. The system depends on it.


We've already done a few things to make sure Postfix runs for us internally, but not to make it work with the Internet. Here's where Postfix shines as being simple to setup: you need to change only one thing to make it work "out of the box."

It's been my experience that whatever configuration you get when you install Postfix is ready to go, but it needs only to know the name of your ISP's mail server. You see, Postfix is a mail server on your machine, and it speaks the same language as almost every other mail server out there on the Internet. Unless your ISP does really weird things, it should quite willingly accept your outgoing mail just like it came from within their own internal mail system in their office.

Login as root, and navigate to /usr/local/etc/postfix. Open the file named with your favorite editor. A good editor will allow the display of a line number for each line of text, either in the right margin or somewhere in the display. Go down to about line 308, where you should see this:

#relayhost = $mydomain
#relayhost =
#relayhost = uucphost
#relayhost = [an.ip.add.ress]

These lines are examples that you can copy, but the hashmark (#) at the front of each one prevents Postfix from reading those lines as something it needs to use. The second one is your model for most connections. Your ISP should be able to tell you the specific name of the computer that handles mail on their system. Most of them use "" or a similar name. Recall from the installation tutorial that this is the usual nomenclature for giving a computer an identifiable name for the Internet. At any rate, whatever your ISP tells you is what goes here. If they just give you an IP number, you can use that, too, by using the last line as your model. Just replace the letters with the digits, keeping the square brackets. For now, all IP addresses are a series of numbers divided into four sections by periods or dots.

It's probably a good idea for your own sake simply to add a new line below these four, but without the hash mark. Finally, for dialup connections, we have to tell the mail system to hang on to outgoing mail until there's a live connection. At the the bottom of your put this line:

defer_transports = smtp

Save the file and close.

If it turns out you need to authenticate with your mail server in order to send anything, such as ATT/Yahoo and most other providers now do, use the following model. Be sure to ask your provider which mail relayhost is correct.

1. Note the relayhost here in brackets. At the bottom of your add the last three lines:

relayhost = []
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/usr/local/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

2. Create a file called sasl_passwd in /usr/local/etc/postfix/. In this file you'll need this line:


With many providers, you'll have to make sure to use the full email address as your authentication name. Now change permissions so others can't read it, and run postmap to create a database Postfix can read:

chmod 600 /usr/local/etc/postfix/sasl_passwd
postmap /usr/local/etc/postfix/sasl_passwd

Now, at the command line type:

postfix reload

It should tell you that it has reloaded and restarted. If it says anything else, you'll need to find out why. When there is a problem, usually you'll get something like fatal error, postfix not running or a similar message. Try typing

postfix start

If that gets you a good response, then you'll need to find out why it wasn't running already. Since the process of finding out is too complicated to put in this tutorial here, I'll invite you to google for keywords in your error message (don't forget that "freebsd" is one of your search terms), ask questions on a forum, or someone you know who runs FreeBSD. In the meantime, you can always login as root and start Postfix manually on those rare occasions when you have to reboot.

At this point, your system should know where to hand off any mail you address for a recipient outside your system. But, be aware there are other complications possible. For example, if you attempt to send mail with a "From" address different than the relayhost, most receiving mail servers will reject it as probable spam. Such issues are far more complicated than can be covered here.


I recall reading an article on the Internet where a technician wrote something like this: "Fetchmail has retrieved my mail under the worst circumstances, when nothing else could." Dialup connections can be rather fragile. If anything can get your mail, Fetchmail will do it.

You can set up Fetchmail to work automatically, and for the whole system. However, that is more complicated than necessary. Since you as the user control when you are logged in, you might as well control when and how your personal mail is fetched. Rather than change settings for the whole system, you need only create a single file -- another dot file normally hidden from view -- in your home directory.

First, a word about protocols. I've never dealt much with a mail system on the Internet that didn't use the standard known as POP3, aside from webmail. With webmail, you read your e-mail by logging on to the provider's machine, and you use their software from your web browser. With POP3, you are pulling that e-mail down to your machine. This allows dialup users to disconnect after you get it and read it later.

Create a file named .fetchmailrc and put three lines in it. We will format it according to a customary practice that makes it easier to read. The first line will be the instruction where to call for you mail. The line has three elements: command, the mail server's name, and what protocol to use. The command is poll -- this tells fetchmail to go ask for your mail. The server name is the same as above, usually similar to The protocol we've already discussed: protocol POP3. If you want to know more about mail protocols, there are numerous articles on the Internet written at all different levels of interest. If your ISP doesn't use POP3, they should tell you. Most of them will understand what you need if you tell them you are running Fetchmail. That first line should resemble this:

poll protocol POP3

Next, you need to tell Fetchmail to match your user account name on your personal machine with the user account name you have on the remote mail server. Hopefully, you are not in the habit of using the same or a similar nickname everywhere you go. It's a security risk, though slight. You don't have to be paranoid to realize the value of being hard to find unless you want to be found. Ordinary people like me have been harassed more than once. So you start this next line indented somewhat (about 8 spaces will do) and tell Fetchmail that user so-and-so on the distant machine is the same as you on this machine. It will look like this:

user joe is user jeh

In this case, my example says that I am "joe" on the server where my mail comes in, and "jeh" on my machine at home. This way, Fetchmail will give my login name to the remote machine, and deliver to me on my machine. If your identity is something odd, such as all numerals, then you may need to put double quotation marks around it, so Fetchmail doesn't confuse it with a command. This is a standard practice in Unix software; double quotation marks tells the software: "Pass this exactly as it is."

I hope your distant mail server requires a password, too. We discussed in the Install lesson how to devise your passwords, and that they should be different everywhere you have an account. If like me you have lots of accounts at places all over the Internet, there's nothing wrong with keeping a cue-card at hand. You'll have to decide for yourself how to guard that card from prying eyes physically where you keep your computer. For sites where it really doesn't matter, where no significant personal information is kept, I do use the same password for all of them. For e-mail, don't do that.

Keeping the same indentation as the identity line, type in the command password followed by the password itself. Again, if you use unusual characters in your password, you may need to put double quotation marks around it:

password "G,H,P.321"

The whole file together might look like this:

poll protocol POP3 user joe is user jeh password "G,H,P!321"

If you want to grab mail from more than one source, leave one blank line, then another set of instructions like the first. When you're done, save the file. Then you must protect it by making sure no one else can read it. Fetchmail is a little paranoid on your behalf, so using your Konqueror file browser, right click on the icon for that file, select "Properties" and click the boxes under the "Permissions" tab until it matches only the "User" line with "Read" and "Write". The other two should say "Forbidden". Click "OK". You may need to enable viewing "hidden" files in Konqueror by selecting the "View" menu, then "Show Hidden Files" -- turn it on and off as you see fit.

Now whenever you are connected to the Internet, you can go to a Konsole window and type fetchmail and watch as it connects to your remote mail server, gets a message count, the size, then downloads each one by showing dots running across the screen (each representing roughly 1KB of data), and erasing it from the other machine. When finished, it will come back to the prompt, and you will have mail in your system with your user's name on it. That's because Fetchmail only fetches it; then it hands mail off to your internal mail server, Postfix. Postfix holds it until you call for it -- that's what the e-mail client does. Should Fetchmail complain a great deal about DNS or certificates, or leaves mail on the server because it can't verify the sender domain, you can add no dns to the end of the first line of your .fetchmailrc (after the POP3) and try again.


It's quite possible to setup Kmail to do this, or just about any other GUI mail software you want to use. However, in keeping with our plan to be ready to run in the CLI, we'll use Mutt. I've already mentioned that Mutt can be setup with all sorts of nice options. For example, you can tell Mutt to display everything in colored text. Until you are ready to read up on all the variations possible, I'll recommend you copy these lines below into a file named .muttrc:

# Color definitions

color normal white default
color header red black "date: "
color header white black "from: "
color header white black "subject: "
color header green black "cc: "
color header green black "to: "
color hdrdefault red default
color quoted green default
color signature yellow default
color indicator brightyellow black
color error brightred default
color status brightyellow blue
color tree magenta default
color tilde magenta default
color message brightcyan default
color markers brightcyan default
color attachment brightmagenta default
color search default green
color header brightred default ^(From|Subject):
color body magenta default "(ftp|http)://[^ ]+" # point out URLs
color body magenta default [-a-z_0-9.]+@[-a-z_0-9.]+
color underline brightgreen default

There are so many other options it is impossible to cover here. I recommend The Woodnotes Guide to the Mutt Email Client as a simple place to start. From that guide, I decided to add these lines to my .muttrc:

set signature=.signature
set from="" set envelope_from my_hdr From: Ed Hurst
source /usr/home/jeh/.muttalias
set alias_file=/usr/home/jeh/.muttalias
set reverse_alias
set copy=yes #keep copies of outgoing mail.
set record="/usr/home/jeh/Mail/sent-mail' "
set implicit_autoview
auto_view text/html application/x-pgp-message
set mailcap_path="~/.mailcap"

You'll need to create your own .muttalias file, a sort of address book using the following format, tabs between each item:

alias   Nickname   Real Name   
alias   Joe     Joe Fish   

You'll also need your own .mailcap file:

text/html; lynx -dump -force_html %s; needsterminal; copiousoutput
application/pdf; kpdf %s
image/jpeg; kuickshow %s
image/gif; kuickshow %s
image/GIF; kuickshow %s
image/JPG; kuickshow %s
image/jpg; kuickshow %s

The first item assumes you have the Lynx web browser installed, which will be explained in more detail later (/usr/ports/www/lynx). For now, you need to know that first line in my mailcap allows Mutt to display HTML formatted mail directly in Mutt. The other lines allow for a popup window to display the attachment.

Save these files in your home directory. Also, if you like using Joe as your standard console editor, you can use it in Mutt by adding this line to your .bashrc (create it if you don't have one already):

export EDITOR="/usr/local/bin/joe"

Note: this won't apply until you close Konsole and restart it. Finally, if you have a favorite signature block you want inserted at the bottom of all your outgoing mail, create a file named .signature and Mutt should insert it into the editor for you. You can read more about the huge collection of options for Mutt in the user manual. You'll find a copy on your machine by typing this command:

less /usr/local/share/doc/mutt/manual.txt

When you are finished with setting options for Mutt, give it a try by sending a test message to yourself as root. Type the command to start Mutt by indicating the "To" address:

mutt root

Normally you would need the entire email address, but without a domain following an @ symbol, Mutt assumes it's a user on the local system. It will ask you to confirm the address by hitting ENTER. Then it will ask for a subject line; type and hit ENTER again. The most common commands are shown on the top line of the display. If you can't figure out what you need, open a second terminal window and view the manual.

For dialup users, if you are online at that moment, Postfix should send it right away. If you are not, it will wait. On some systems, as soon as you connect to the Internet, your machine will attempt first thing to send all the mail in the queue. If this doesn't happen, you can go to the command line and type:

/usr/sbin/sendmail -q

which tells Postfix to pass on your out-going mail.

Congratulations! You are now ready to use e-mail the way it was meant to be, according to all the best standards. It is virtually impossible for anyone to send you something that will harm your machine, because this combination of software isn't likely to react to viruses, worms, etc.

Ed Hurst is Associate Editor of Open for Business.

Join the Conversation

4 comments posted so far.

Re: Desktop FreeBSD Part 4: Internet Mail Setup

before putting the line’s sendmail_enable=”NO” sendmail_submit_enable=”NO” sendmail_outbound_enable=”NO” sendmail_msp_queue_enable=”NO” postfix_enable=”YES” postfix_pidfile=”/var/spool/postfix/pid/” postfix_procname=”/usr/local/libexec/postfix/master” into /etc/rc.conf, first run

/usr/src/etc/rc.d/sendmail stop

it will not stop if you have placed the line sendmail_enable=”NO” into /etc/rc.conf

regards, Johan

Posted by Sylhouette - May 20, 2007 | 7:34 AM

Re: Desktop FreeBSD Part 4: Internet Mail Setup

I haven’t installed postfix yet, but I assume that you want to disable sendmail completely, if so you can replace all sendmail options in rc.conf with ‘sendmail_enable=”NONE”’. If you use sysinstall, it suggests this. See also the corresponding rc script.

And you can stop sendmail after you have placed the above in rc.conf, try using ‘/etc/rc.d/sendmail onestop’. AFAIK all rc scripts that source ‘/etc/rc.subr’ have this functionality.

And why do you use the scripts in ‘/usr/src/etc/rc.d/’? This could lead to unexpected behavior if you upgrade the base system from source. My recommendation is to use the scripts in ‘/etc/rc.d’.

regards, Tim

Posted by tim - Jun 01, 2007 | 12:22 AM

Re: Desktop FreeBSD Part 4: Internet Mail Setup

Last time I looked sendmail was part of the base system.

Posted by FreeDumbo - Oct 11, 2007 | 8:19 AM

does anybody

know how to change on a freebsd server a interent and email connection only. I seem to have setup a new server 6.2 FBSD and even on vexim i log out people from internet they still can log in a browse. thanks for help Harald

Posted by harald - Feb 10, 2008 | 9:52 AM