Mail server configuration
Sendmail is probably the most popular mail server in use on the Internet today and it's included in FreeBSD. In it's default configuration it's rather crippled though. It will only accept connections on the internal loopback interface for example. You can easily alter the configuration and turn Sendmail into a fully functional mail server. Some of the benefits are listed here:
- An unlimited amount of email addresses which is perfect to use for temporary registrations on various web sites.
- Can be configured not only to receive email for your DynDNS domain but also for additional free or commercial domains that you control.
- With the pf firewall guarding the mail server you can prevent spammers from delivering their crap at all. No need for the clients to filter mail afterwards.
The very first thing you have to do is to make Sendmail listen on all available interfaces.
# echo 'sendmail_enable="YES"' >> /etc/rc.conf # /etc/rc.d/sendmail restart Stopping sendmail. Starting sendmail.
Then there is a number of configuration files you need to either create or change to make this work so let's go through them one by one. Everything you need is located in /etc/mail so start off by changing to that directory.
# cd /etc/mail
This file controls who will be allowed to access this mail server and what they will be allowed to do. This file does not exist by default so create it and copy and paste the following lines:
localhost RELAY 127.0.0.1 RELAY 192.168.69 RELAY
The last line contains your internal network so it has to be adjusted to match whatever you're using. That same line will give any computer on your internal LAN access to send mail to anyone on the Internet through your mail server. You can restrict this by specifying complete IP addresses instead, pointing only to those computers you trust.
After updating this file you have to compile it.
# make cp freebsd.mc gatekeeper.pp.dyndns.biz.mc /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 gatekeeper.pp.dyndns.biz.mc > gatekeeper.pp.dyndns.biz.cf cp freebsd.submit.mc gatekeeper.pp.dyndns.biz.submit.mc /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 gatekeeper.pp.dyndns.biz.submit.mc > gatekeeper.pp.dyndns.biz.submit.cf /usr/sbin/makemap hash access.db < access chmod 0640 access.db
In the final two rows of the output you can see that your access file is converted to access.db instead. Don't worry about the output before that. It will be explained further down.
In this file you find a list of userids that are normally in use by various services on the server. It also contains userids that are expected to be found on the server regardless of whether they have actually been defined or not. If anyone sends an email to these users, you surely would like to catch them and have them forwarded to your own userid and this is the purpose of this file. Remember to change the occurrence of the userid pp below to the userid you created for yourself on the router.
Find the following rows in the file:
# root: firstname.lastname@example.org # webmaster: root # www: webmaster
Change them to:
root: pp webmaster: root www: webmaster
What you have done now is to redirect all system mails to your own user account. Note the remark symbols that you have to remove and don't mistake them for a command prompt symbol. After updating this file you have to compile it.
# make /usr/sbin/sendmail -bi -OAliasFile=/etc/mail/aliases /etc/mail/aliases: 30 aliases, longest 10 bytes, 306 bytes total chmod 0640 /etc/mail/aliases.db</pre>
Here you place the name of every domain you want this server to accept mail for. You can add as many as you like but you also have to make sure that those domains resolve to the IP address of your router or at least have an MX pointer that does. The file does not exist default so simply create it by adding your DynDNS domain.
# echo "pp.dyndns.biz" >> /etc/mail/local-host-names
After updating this file you need to restart Sendmail.
# make restart Restarting: sendmail sendmail-clientmqueue.
This file is similar to the aliases file. To use a new email address for your domain you don't really have to create a user for it. If all you're looking for is simply a number of temporary email addresses to use for registrations here and there, it would be a lot of job having to create a user for each and every one of them and then connect to every separate account to read the mail. A simpler way is to define a virtual user and point it to an existing userid, exactly as you did in the aliases file. There are two approaches here: You could define a "catch-all" address, one single line in this file that would direct any incoming mail for your domain to your own account unless it matched an existing user of course. However, sooner or later you will experience a spammer who will create false sender addresses for all his spam using the name of your domain. When the majority of all that spam bounces at the receiving mail servers, where do you think they send their notices that the mail couldn't be delivered? I'm talking from personal experience here and it's not very funny waking up one morning finding tens of thousands of mail delivery failure notices in your mailbox and just seeing them continue flooding in. Well, to be honest I might have provoked one or two spammers into this by using some nasty tricks while blocking them. :-) But from this experience I recommend you instead define every virtual user specifically in this file. It's still much quicker than creating physical accounts. Below you find an example of some content you can put in this file. It also shows how you can block individual email addresses if they start receiving a lot of spam. Again, this file does not exist by default either so you'll have to create it first.
email@example.com pp firstname.lastname@example.org pp email@example.com firstname.lastname@example.org email@example.com pp firstname.lastname@example.org error:nouser No such user here email@example.com error:nouser You can put any offensive message you like here
If you're brave and still want to try the "catch-all" approach, here is the syntax you'll use in the file instead.
You need to compile this file too after changing it.
# make /usr/sbin/makemap hash virtusertable.db < virtusertable chmod 0640 virtusertable.db
*.mc and *.cf
sendmail.cf and submit.cf are the two main configuration files for Sendmail. They are extremely versatile and modular and can alter many aspects of how Sendmail receive, process and deliver mail but the downside is that they're also extremely complex because of this. Like all other Sendmail configuration files these are compiled too and you never edit them directly. By default there is instead a sendmail.mc and a submit.mc which you edit and then compile to their respective .cf file. FreeBSD has chosen a slightly different naming convention though.
- sendmail.mc is called freebsd.mc and is compiled to freebsd.cf which in turn is copied to sendmail.cf during installation.
- submit.mc is called freebsd.submit.mc and is compiled to freebsd.submit.cf which in turn is copied to submit.cf during installation.
The first time you type make in /etc/mail you get another set of these files.
- freebsd.mc is copied to hostname.mc - in this example gatekeeper.pp.dyndns.biz.mc.
- freebsd.cf is copied to hostname.cf - in this example gatekeeper.pp.dyndns.biz.cf.
- freebsd.submit.mc is copied to hostname.submit.mc - in this example gatekeeper.pp.dyndns.biz.submit.mc.
- freebsd.submit.cf is copied to hostname.submit.cf - in this example gatekeeper.pp.dyndns.biz.submit.cf.
hostname.mc and hostname.submit.mc, named after your own domain of course, are the files you make changes to if you need to. Whenever you then type make install they will be compiled to their respective .cf files which are then copied to sendmail.cf and submit.cf respectively. What's the purpose of this complicated behaviour? Well, the FreeBSD template files, and possibly also the default configuration files, will most likely be overwritten every time you upgrade FreeBSD. If there weren't a set of intermediate configuration files you would loose your changes every time you upgrade. Instead it's up to you to merge any changes in the upgraded template files into your own configuration files and then compile new default configuration files for Sendmail whenever you perform an upgrade. Luckily it's not very likely you need to touch these files for a home router but I will show one change here that you probably will have to do.
Most ISPs that provide their services to home users usually block outbound traffic on port 25 which is used by mail servers to deliver mail to other mail servers. The intention is to prevent infected computers from becoming relay hosts for mail spam. This block effectively accomplishes that goal but it also blocks you from delivering your real mail directly to the receiving mail servers. Instead you have to tell Sendmail to deliver all outbound mail to your ISPs relay server and it will then make sure your mail reach its intended destination. If your ISP doesn't block port 25 you can skip to the next step.
Open your hostname.mc in your editor and locate the following row:
dnl define(`SMART_HOST', `your.isp.mail.server')
Change it to:
Of course you replace the relay server's name with that of your ISP's. Also take care when you erase the leading dnl on that row so you don't disturb anything else in the file. Exit and save the file and then type:
# make install /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 gatekeeper.pp.dyndns.biz.mc > gatekeeper.pp.dyndns.biz.cf install -m 444 gatekeeper.pp.dyndns.biz.cf /etc/mail/sendmail.cf install -m 444 gatekeeper.pp.dyndns.biz.submit.cf /etc/mail/submit.cf
After installing the new configuration files you have to restart Sendmail again:
# make restart Restarting: sendmail sendmail-clientmqueue.
You have to add a rule to your firewall to allow incoming mail from the Internet to reach your server. Find the rule allowing ssh in the section # Incoming to router and add this rule after it:
pass in log quick on $ext_if inet proto tcp from any to ($ext_if) port smtp flags S/SA synproxy state queue (q_p1, q_p2)
Reload the firewall rules in the usual manner.
# pfctl -nf /etc/pf.conf # pfctl -F rules ; pfctl -f /etc/pf.conf
Your Sendmail configuration is now finished and you now have your own fully functional mail server.
As a new owner of a mail server you need to be aware of open relaying. Your mail server will become a prime target for spammers and they will try many tricks to make your server distribute their spam for them in an effort to hide themselves and put the blame for the spam on you. An open relay is a mail server that accepts mail from users not belonging to your domain and delivers it to users that also don't belong to your domain. This was they way mail servers were configured by default a few years ago and it was heaven for spammers. This has of course changed but spammers have over the years figured out many ingenious ways to get around the tighter security in modern mail servers. Sendmail is as secure as it can be though and isn't vulnerable to any of the known attacks that exist. This doesn't mean that there won't be any security issues in the future but for now you can feel pretty confident in your server. If you wish to test your server against known attacks, and at the same time see how ingenious some of those attacks are, you can use this free service over at abuse.net.
Reading your mail
There are several pop3 servers to choose from in the Ports Collection. For a full featured pop3 server supporting encrypted connections and everything, you should probably go for qpopper but the installation involves many advanced concepts so for now I will show you the much simpler popa3d. As usual there is a configuration screen for the compile options but you can leave them at their defaults.
# cd /usr/ports/mail/popa3d # make # make install clean
Note the output.
1. Edit your /etc/inetd.conf to use popa3d. The line should look like this: pop3 stream tcp nowait root /usr/local/libexec/popa3d popa3d Note: when started via an inetd clone, the logging of connections is left up to that inetd clone or TCP wrappers. 2. Restart inetd by sending it a SIGHUP: # killall -HUP inetd
To save memory and other computer resources many services are not meant to run constantly. Instead they are executed only when they're needed and will exit as soon as they have provided whatever service was requested. For this to work you need some kind of mechanism to monitor the service ports and launch the correct application when needed. That mechanism is called inetd so you'll have to configure it to support popa3d. Load /etc/inetd.conf in the editor and find the following line:
#pop3 stream tcp nowait root /usr/local/libexec/popper popper
Remove the # at the beginning of the line and change the end of it to match what was written in the output.
pop3 stream tcp nowait root /usr/local/libexec/popa3d popa3d
Step 2 in the output is only applicable if you already have inetd up and running which you don't have at this point so you have to do this differently.
# echo 'inetd_enable="YES"' >> /etc/rc.conf # /etc/rc.d/inetd start Starting inetd.
Everything is now set up to retrieve your mail from the router but you have to configure your email client first. There's usually only four parameters you will have to enter: protocol - pop3; mail server - 192.168.69.1 (that should be your router's internal IP address); the userid and password you configured for yourself on the router. Since the logon procedure is sending your password unencrypted it's not advisable to read your mail from the Internet side. The firewall is not configured to let that traffic through anyway but if you still want that option you'll have to add the following rule to your firewall configuration, after the other q_p1 rules in the section called # Incoming to router.
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port pop3 flags S/SA synproxy state (q_p1, q_p2)
After that you have to reload the firewall rules again.
# pfctl -nf /etc/pf.conf # pfctl -F rules ; pfctl -f /etc/pf.conf
- Sendmail's configuration files are all located in /etc/mail.
- The start/stop script for Sendmail is /etc/rc.d/sendmail but Sendmail should rather be restarted with make restart in /etc/mail.
- Inetd is the super-server daemon that manages Internet services.
- The configuration file for inetd is /etc/inetd.conf.
- The start/stop script for inetd is /etc/rc.d/inetd.
Something I'm missing is a webmail interface to the server. An IMAP server is necessary and courier-imap seems to be the appropriate choice. But the installation is complicated with setup of encryption, changes to the sendmail.cf and creation of a folder structure for all user's mail and it's interaction with the day to day user administration. I haven't found a good source of information to explain all the concepts clearly enough to not risk messing things up.