Electronic mail: servers

Configuring Postfix

Postfix requires only one configuration file, /usr/local/etc/postfix/main.cf. This file contains a large number of comments: with a little experience you can configure it without any outside help. In this section, we'll look at some of the entries of interest.

#The mail_owner parameter specifies the owner of the Postfix queue
#and of most Postfix daemon processes. Specify the name of a user
#account THAT DOES NOT SHARE ITS USER OR GROUP ID WITH OTHER ACCOUNTS
#AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM. In
#particular, don't specify nobody or daemon. PLEASE USE A DEDICATED USER.
#
mail_owner = postfix

Older MTAs used to run as root, which made it easier to write exploits transmitted by mail. Modern MTAs use a dedicated user ID. As we saw above, the postfix user gets added to your password files when you install it. sendmail uses another user ID, smmsp. Don't change this entry.

Host and domain names

A signifycant portion of the configuration file defines host names. By default, the variable myhostname is the fully qualified host name of the system, for example freebie.example.org. You should normally leave it like that; it's not identical to the name that will appear on outgoing mail.

The next variable is mydomain, which defaults to the domain name of the system. Again, you won't normally want to change it.

Then comes the variable myorigin, which is the name that appears on outgoing mail. It defaults to myhostname, which is probably not a good choice. As suggested above, a better name would be the domain name mydomain. Make the following changes to main.cf:

#The myorigin parameter specifies the domain that locally-posted
#mail appears to come from. The default is to append $myhostname,
#which is fine for small sites. If you run a domain with multiple
#machines, you should (1) change this to $mydomain and (2) set up
#adomain-wide alias database that aliases each user to
#user@that.users.mailhost.
#
#myorigin = $myhostname
myorigin = $mydomain

In the original configuration file, the last line is present, but it is "commented out": it starts with the # character. Just remove this character.

The next variable of interest is mydestination. This is a list of host and domain names for which the MTA considers itself the final destination (in other words, it accepts mail for final delivery). By default, it accepts mail addressed to the name of the machine ($myhostname in postfix parlance) and also localhost.$mydomain, the local host name for this domain. In particular, it does not accept mail addressed to the domain, so if you sendmail as fred@example.org, any reply will bounce. To fix this, add $mydomain to the list.

You might also want to accept mail for other domains. For example, if you also wanted to accept mail for beispiel.org, you would add that name here as well. The result might look like this:

#mydestination = $myhostname, localhost.$mydomain
#mydestination = $myhostname, localhost.$mydomain $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain,
   beispiel.org

For the mail for beispiel.org to actually be delivered to this machine, the lowest priority MX record for beispiel.org must point to this host.

Further down, we'll see a feature called virtual hosting. This is a way to allocate email addresses to people without a UNIX account on this machine. It works at the user level, not the domain name level.

Relaying mail

One of the favourite tricks of spammers is to send their mail via another system to give it the aura of respectability. This is doubly annoying for the "other" system: first, it gives it the reputation of being a spammer, and secondly it often incurs expense, either for data charges or simply from congestion. Postfix has a number of tricks to help. The first specifies which networks to trust: Postfix will relay mail coming from these networks. You could consider this to be "outgoing" mail, though the methods Postfix uses don't make this assumption. By default, postfix trusts your network and the localhost network 127.0.0.0/8, in other words with a net mask 255.0.0.0. But how does it know the net mask for your network? There are two possibilities: you tell it, or it guesses.

Postfix is pretty simplistic when it comes to guessing. It takes the default net mask for the address class, so if your IP address is, say, 61.109.235.17 (a "class A" network), it will accept mail from any network whose first octet is 61. I know of at least 20 sources of spam in that range. In almost every case, you should specify the network and mask explicitly:

mynetworks = 223.147.37.0/24, 127.0.0.0/8

This is a good choice where you know the name of the originating networks, for example systems that expect you to handle the mail connection to the outside world. But what if you want to accept mail from anywhere addressed to specific domains? Consider this "incoming" mail, though again that's not the way Postfix looks at it. For example, maybe you're a backup MX for beispiel.de, so you want to accept any mail sent to that domain. In that case, you want to relay mail to this domain no matter where it comes from. For this case, use the relay_domains variable, a list of domain names for which Postfix will always relay. You might put this in your main.cf:

relay_domains = $mydestination, $mydomain, beispiel.de

You can also use the permit_mx_backup variable to accept mail for any domain that lists you as a secondary MX. This is very dangerous: you don't have any control over who lists you as a secondary MX, so any spammer could take advantage of this setting and use you for a relay.

Aliases revisited

On page 484 we looked at how to set up individual aliases for use with mutt. Postfix and sendmail also have an alias facility, this time at the system level. The system installs a file called /etc/mail/aliases. It's there by default, so there's no particular reason to move it. The default /etc/mail/aliases looks like:

#Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root

#General redirections for pseudo accounts
bin:     root
daemon:  root
games:   root
ingres:  root
nobody:  root
system:  root
toor:    root
uucp:    root
#Well-known aliases -- these should be filled in!
#root:
#manager:
#dumper:
#operator:

root: grog

Each line contains the name of an alias, followed by the name of the user who should receive it. In this case, mail addressed to the users bin, daemon, games, ingres, nobody, system, toor and uucp will be sent to root instead. Note that the last line redefinesroot to send all mail to a specific user.

You must run the newaliases program after changing /etc/aliases to rebuild the aliases database. Don't confuse this with the newalias program, which is part of the elm MUA.

A couple of other uses of aliases are:

frednospamplease: fred

By default, Postfix doesn't have a specific alias file. main.cf contains:

#alias_maps = dbm:/etc/aliases
#alias_maps = hash:/etc/aliases
#alias_maps = hash:/etc/aliases, nis:mail.aliases
#alias_maps = netinfo:/aliases

The texts dbm, hash and netinfo describe the kind of lookup to perform. For sendmail compatibility, we want hash. Assuming you also want to run majordomo, add the line:

alias_maps=hash:/etc/mail/aliases,hash:/usr/local/majordomo/aliases.majordomo

Rejecting spam

One of the biggest problems with email today is the phenomenon of spam, unsolicited email. Currently the law and ISPs are powerless against it. Hopefully the community will find solutions to the problem in the future, but at the moment keeping spam to manageable proportions is a battle of wits. There are a number of ways to combat it, of course:

Received: from femail.sdc.sfba.home.com (femail.sdc.sfba.home.com [24.0.95.82])
   by wantadilla.lemis.com (Postfix) with ESMTP id BCBFF6ACC0
   for <webmaster@lemis.com>; Tue, 19 Jun 2001 13:50:57 +0930 (CST)
Received: from u319 ([24.21.217.142]) by femail2.sdc1.sfba.home.com
   (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
   id <20010619042005.FBWM26828.femail2.sdc1.sfba.home.com@u319>;
   Mon, 18 Jun 2001 21:20:05 -0700
From: britneyvideo1234@yahoo.com
To:
Subject: stolen britney spears home video!!!
Date: Thu, 19 Jun 2025 13:52:44 -0200

Received: from web11207.mail.yahoo.com (web11207.mail.yahoo.com         [216.136.131.189])
   by mx1.FreeBSD.org (Postfix) with SMTP id 4079E43E65
   for <freebsd-arch@freebsd.org>; Mon, 7Oct 2002 10:39:14 -0700 (PDT)
   (envelope-from gathorpe79@yahoo.com)

So how do we use this information to combat spam? Postfix helps for the first three, but we need other tools for the last.

The rules for blocking unwanted messages are not included in /usr/local/etc/postfix/main.cf. Instead, they're in /usr/local/etc/postfix/sample-smtpd.cf. Copy those you want to the bottom of your /usr/local/etc/posfix/main.cf. Specifically, the variables of interest are smtpd_helo_restrictions (which relates to the sending MTA, which could be a relay), and smtpd_sender_restrictions, which relates to the (claimed) original sender. See sample-xmtpd.cf for details of all possible restrictions. The more interesting ones are:

Rejecting known spam domains

If you have identified domains that you would rather not hear from again, use the form check_sender_access maptype:mapname. By default, the map is stored in /usr/local/etc/postfix/access.db. Add the following text to main.cf:

smtpd_sender_restrictions = hash:/usr/local/etc/postfix/access

Note that the .db is missing from the name. Now add this line to the file /usr/local/etc/postfix/access, creating it if necessary:

spamdomain.com 550 Mail rejected. Known spam site.

This form rejects messages from this domain with SMTP error code 550 and the message that follows. As we have seen, postfix reads the file /usr/local/etc/postfix/access.db, not /usr/local/etc/postfix/access. Use the postmap program to create or update /usr/local/etc/postfix/access.db:

# postmap /usr/local/etc/postfix/access

The changes to /usr/local/etc/postfix/main.cf depend on other items as well, so we'll look at them at the end of this discussion. To judge by the name, spamdomain.com is probably a hard-core spam producer. But there are others, notably large ISPs with little or no interest in limiting spam, and they also have innocent users who will also be blocked. If you find out about it, you can make exceptions:

spamdomain.com          550          Mail rejected. Known spam site.
innocent@spamdomain.com OK

Don't forget to re-run post map after updating alias. One way is to create a Make file in /usr/local/etc/Postfix with the following contents:

access.db: access
    /usr/local/sbin/postmap access

Then add the following line to /etc/crontab:

1****root (cd /usr/local/etc/postfix; make) 2>/dev/null >/dev/null

This checks the files every hour and rebuilds /usr/local/etc/postfix/access.db if necessary.

Rejecting sites without reverse lookup

A very large number of spam sites don't have reverse lookup on their IP addresses. You can reject all such mail: after all, it's misconfigured. Just add the reject_unknown_sender_domain keyword to the smtpd_sender_restrictions. Unfortunately, some serious commercial enterprises also don't have reverse lookup. It's your choice whether you want to accept mail from them and open the food gates to spam, or to ignore them. The FreeBSD project has chosen the latter course: if you don't have reverse lookup, you will not be able to send mail to FreeBSD.org.

Rejecting listed sites

Another alternative is to reject sites that have been listed on a public list of spam sites, sometimes referred to as an rbl (Realtime Blackhole List). The example given in the configuration file is http://www.mail-abuse.org/, but there are others as well. They maintain a list of spam sites that you can query before accepting every message.

I don't like these sites for a number of reasons:

If you want to use this kind of service, add the following two lines to your main.cf:

smtpd_client_restrictions = reject_maps_rbl
maps_rbl_domains = rbl.maps.vix.com

The name rbl.maps.vix.com comes from the sample file. Replace it with information from your rbl supplier.

Recognizing spoofed messages

There's only so much that postfix can do to restrict spam. The Ports Collection contains a couple of other useful tools, procmail and spamassassin, which together can reject a lot of spam. It involves a fair amount of work, unfortunately. Take a look at the ports if you're interested.

Sender restrictions: summary

The restrictions above are interdependent. I would recommend rejecting senders based on address and lack of reverse lookup. To do that, add just the following lines to your main.cf:

smtpd_sender_restrictions = reject_unknown_sender_domain,
      hash:/usr/local/etc/postfix/access

Running postfix at boot time

By default, the system starts sendmail at boot time. You don't need to do anything special. Just set the following parameters in /etc/rc.conf:

sendmail_enable="YES"
sendmail_flags="-bd"
sendmail_outbound_enable="NO"
sendmail_submit_enable="NO"
sendmail_msp_queue_enable="NO"

The fags have the following meanings:

Talking to the MTA

The Simple Mail Transfer Protocol, or SMTP, is a text-based protocol. If you want, you can talk to the MTA directly on the smtp port. Try this with telnet:

$ telnet localhost smtp
Trying ::1...
telnet: connect to address ::1: Connection refused attempt to connect with IPv6
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’?]’.
220 freebie.example.org ESMTP Postfix on FreeBSD, the professional’s choice
ehlo freebie.example.org      say who you are
250-freebie.example.org name
250-PIPELINING                and list of available features
250-SIZE 10240000
250-ETRN
250 8BITMIME
mail from: grog@example.org   who the mail is from
250 Ok
rcpt to: grog@example.org     and who it goes to
250 Ok
data start                    the message body
354 End data with <CR><LF>.<CR><LF>
Test data The message
.                            End of message
250 Ok: queued as 684F081471
quit                         and exit
221 Bye
Connection closed by foreign host.

This rather cumbersome method is useful if you're having trouble with postfix.

Downloading mail from your ISP

As we discussed before, the Internet wasn' t designed for dialup use. Most protocols assume that systems are up a large proportion of the time: down time indicates some kind of failure. This can cause problems delivering mail if you are not permanently connected to the Internet.

If you have an MX record that points to another system that is permanently connected, this doesn't seem to be a problem: the mail will be sent to that system instead. When you connect, the mail can be sent to you.

How does the mail system know when you connect? Normally it doesn't. That's the first problem. Most systems set up their MTA to try to deliver mail every 30 to 120 minutes. If you are connected that long, the chances are good that the mail will be delivered automatically, but you don't know when.

One possibility here is to tell the remote MTA when you're connected. You can do this with the SMTP ETRN command. Telnet to thesmtp port on the system where the mail is queued:

$ telnet mail.example.net smtp
Trying 139.130.237.17...
Connected to mail.example.net.
Escape character is '"]'.
220 freebie.example.org ESMTP Sendmail 8.8.7/8.8.7 ready at Mon, 5 May 1997
12:55:10 +0930 (CST)

etrn freebie.example.org
250 Queuing for node freebie.example.org started
quit
221 mail.example.net closing connection
Connection closed by foreign host.

The mail starts coming after the message Queuing for node freebie.example.org started. Depending on how much mail it is, it might take a while, but you don't need to wait for it.

Another alternative is the Post Office Protocol, or POP. POP was designed originally for Microsoft-style computers that can't run daemons, so they have to explicitly request the other end to download the data. POP is an Internet service, so you need the cooperation of the other system to run it. We'll look at POP in the next section.

POP: the Post Office Protocol

The Post Office Protocol is a means for transferring already-delivered mail to another site. It consists of two parts, the client and the server. A number of both clients and servers are available. In this discussion, we'll look at the server popper and the client fetchmail, both of which are in the Ports Collection.

popper: the server

Install popper from the Ports Collection in the usual manner:

# cd /usr/ports/mail/popper
# make install

popper is designed to be started only via inetd. To enable it, edit /etc/inetd.conf. By default, it contains the following line:

#pop3 stream tcp nowait root /usr/local/libexec/popper popper

This line is commented out with the # character. Remove that character to enable the service. Then cause inetd to re-read its configuration file:

# killall -1 inetd send a SIGHUP

To test the server, telnet to the pop3 port. You can't do much like this, but at least you can confirm that the server is answering:

$ telnet localhost pop3
Trying : :1…
telnet: connect to address : :1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '"]'.
+OK QPOP (version 2.53) at freebie.example.com starting. <11755.1028797120@freebie.
example.com>
quit
+OK Pop server at freebie.example.com signing off.
Connection closed by foreign host.

fetchmail: the client

Install fetchmail from the Ports Collection. To run it, just specify the name of the server from which you want to load the mail.

$ fetchmail hub
querying hub
Enter mailserver password: doesn’t echo
QPOP (version 2.3) at hub.freebsd.org starting. <27540.876902406@hub.freebsd.org>
5 messages in folder, 4 new messages.
reading message 1...
flushing message 2
reading message 2....
flushing message 3
reading message 3...
flushing message 4
reading message 4...
flushing message 5
reading message 5....

fetchmail and popper are relatively simple to use if you have to, but they add another level of complexity to the mail system, and they require additional work in a system that is designed to be automatic. In addition, fetchmail is not a speed demon: if you have a lot of mail to transfer, be prepared to wait much longer than an SMTP MTA would take.

Mailing lists: majordomo

majordomo is a mail list manager. If you run mailing lists, you probably want to use majordomo: it saves you manually modifying the mailing lists. As usual, you can find majordomo in the Ports Collection, in the directory /usr/ports/mail/majordomo. When installing, you'll notice a message:

To finish the installation, ’su’ to root and type:
           make install-wrapper
If not installing the wrapper, type
           cd /usr/local/majordomo; ./wrapper config-test
(no ’su’ necessary) to verify the installation.
./install.sh -o root -g 54 -m 4755 wrapper /usr/local/majordomo/wrapper

With the exception of the last line, this comes from the original majordomo installation procedure. The last line is the port performing the make install-wrapper for you. You don't need to do anything else, and you can ignore the messages.

After installation, you still need to perform some configuration:

majordomo-owner: root

alias_maps=hash:/etc/mail/aliases,hash:/usr/local/majordomo/aliases.majordomo

# postfix reload

That's all you need to do. You don't need to start any processes to run majordomo: it gets started automatically when a mail message is received.