Configure Sendmail Users and Domains

There are two aspects to sendmail which we can configure. We can configure Sendmails behaviour such as queues, timeout intervals and additional features such as milters through sendmail.cf and submit.cf. We can also configure users, domains and relaying through the local configuration files such as aliases, access, local-host-names and relay-domains. This article shall endevour to familiarize the reader with the everyday configuration of Sendmail, users, virtual users, relays and domains. If you wish to change Sendmails behaviour or included options please read our article on Configuring Sendmail.

The most common location for the configuration files for sendmail is in the /etc/mail directory. The files you will likely find yourself editing the most are virtusertable, aliases, access, local-host-names and possibly relay-domains. Generally speaking, sendmail delivers mail to a local user account on the primary mail server and each individual mailbox needs a corresponding user account. To muddy the waters somewhat you can also have aliases and virtual addresses set up to map emails with different addresses to one local user account. Using aliases you can even map emails with one particular recipient to several different local user accounts so that more than one person will receive it.

That probably all sounds more confusing than it actually is. Let start by examining a reasonably simple mail server set up, a mail server that receives mail for one particular domain. This will get a lot of readers mail servers running in the space of a few paragraphs then we can focus on a mail server that receives mail for multiple domains, uses aliases and virtual email addresses.

Quick Sendmail Setup for a Single Domain Sendmail must be made aware of the domains for which it receives mail. This is done through a file called local-host-names which is usually located in the /etc/mail directory on your Linux mail server. Older versions of Sendmail will use a file named sendmail.cw for this purpose instead that performs exactly the same task. Edit your local-host-names file with Vi, Pico or similar and add your domain or subdomain as below. yourdomain.com Once you have edited local-host-names restart sendmail for the changes to take effect and it will now attempt to deliver any emails @yourdomain.com to a local mailbox (user account). To create a user account that we can use as a mailbox use the useradd command or adduser command, depending on your chosen Linux distribution either or both of these commands will be available. We shall use useradd in our examples as it is slightly more widely distributed. In our example below the mailbox we have added is fred with a password specified using the -p option as cleverpassword. useradd -p cleverpassword fred You should now be able to send a test email to fred@yourdomain.com and it should be received and delivered to fred's mailbox. Mail awaiting collection is usually stored in a mail spool directory, usually /var/spool/mail, so in our example freds mail will be waiting in the file /var/spool/mail/fred. The finger command (finger fred) will allow you to check if your test email has arrived. Local-Host-Names Configuring Sendmail for multiple domains is not difficult but it does have some caveats that you need to be aware of as far as delivery is concerned, that may be a benefit or a problem depending on your perspective. Adding additional domains is as easy as editing local-host-names and entering the domains on a seperate line like the example below. Restart sendmail for the changes to take effect. yourdomain.com anotherdomain.com example.net

Now our Linux Sendmail server will accept mail for the above three domains, yourdomain.com, anotherdomain.com and example.net. And here is where one of Sendmail's caveats presents itself. Using our user fred that we added earlier as an example, if someone sends an email to fred@yourdomain.com, fred@anotherdomain.com and fred@example.net they will all arrive in the fred mailbox. This is because the default behaviour of Sendmail is to deliver mail to a matching local user account if a virtual user or alias that matches the address cannot be found. This can be very useful behaviour, I have many domains hosted on one mail server and an email to webmaster as an example will arrive in the one mail box. I only have to check one account to receive the mail to all of these addresses. This is easily changed by using the virtual user table if you host many domains and have many different freds (or any other user for that matter).

The Virtual User Table The virtual user table is a hash database that maps virtual addresses into real addresses, or more accurately into local user accounts. To create a virtual user you do not edit the database directly but a text source file instead. The text file is then used to build the virtual user table. In a default installation of Sendmail you can see amongst all of the files in the /etc/mail two in particular, virtusertable.db (the virtual user database) and virtusertable (the text file that you edit and use to build the database). So in our above example with three different Freds on three different domains we simply create a mail box for each Fred and edit virtusertable. Put the virtual address first, tab and then put the users mail box. Each virtual address should be on its own line. It is useful from the outset to have a convention for virtual addresses as it makes it easier to determine what addresses belong to which domain. If the user has a yourdomain.com address the user account for the address will start with yd_. Anotherdomain users start with ad_ and so on. fred@yourdomain.com               yd_fred fred@anotherdomain.com        ad_fred fred@example.net                       ex_fred bill@example.net                         ex_fred @example.net                              ex_tim It is quite possible to map many virtual addresses to the same mail box as demonstrated in the example above with bill@example.net being mapped to the same user account as fred@example.net. Below bill@example.net we can also see an example of a catchall address, any email that is addressed to any recipient @example.net that is not for bill or fred is sent to ex_tim. Catchall addresses can be very useful particularly for small enterprises however they may increase the amount of spam the recipient receives as any email to the domain will be delivered to the specified mail box. Spammers randomly generate emails to the domain they are targetting. Every time you change add or remove a virtual address from the virtual user table you must map the text file to the database file or the changes will not take place. This is done in the /etc/mail directory using the makemap command. # makemap hash virtusertable < virtusertable

Aliases

Aliases are another way to direct mail addressed to one recipient and deliver it to another. There are instances where there is overlap between the role of the virtual user table and aliases where you can use either to achieve a given end but aliases are more often used when manipulating mail boxes rather than virtual addresses. Aliases, like the virtual user table, have a text source file that is mapped to a database though its layout is slightly different. The makemap command should not be used to map your aliases database as this will cause erratic mail delivery and cripple your mail server. The newaliases command should be used instead. Lets have a look at the aliases text file below.

webmaster:            james abuse:                     peter sales:                      peter, paul, mary yd_sales:               yd_fred, yd_karen

The webmaster and abuse aliases are very straightforward, note that the format is alias then a colon then a tab and then the local account to which the mail should be delivered. The sales alias has three recipients Peter, Paul and Mary with a comma and a space between the local mail boxes. The final example here follows on from a virtual address, sales@yourdomain.com is directed to yd_sales in the virtusertable and then directed to yd_fred and yd_karen through aliases. There need not even be a local account yd_sales for this to work. After you edit the aliases file use the newaliases command to map the changes you have made.

# newaliases

The Access Map

By default Sendmail will receive mail from any sender but will only send mail if it is being sent from the localhost address. This is the ideal configuration to prevent spammers from using your mail server to relay their garbage to the world. The access map, like the virtual user table, is a hash database (access.db) and an accompanying text file (access) which is edited to control mail being sent and received by your mail server. The access file is edited and then the access database is mapped using the makemap command. Entries in the access map should be preceded with one of three tags according to its type-

Connect: connection information (${client_addr}, ${client_name})
From: envelope sender
To: envelope recipient

As a minimum you would require that your users can send mail through the mail server and this is accomplished by specifying the hosts or IP address ranges that your users are connected followed by the value RELAY. You may also elect to REJECT mail from particular senders or domains. Here are a few examples-

Connect:yourdomain.com             RELAY Connect:192.168.1                         RELAY From:viagra.com                             REJECT To:fred@yourdomain.com            REJECT

In the above example the mail server will relay mail from any yourdomain.com host and also from hosts on the 192.168.1.0/24 network. Any email from viagra.com or any email to fred@yourdomain.com will be rejected. Once you have edited access you need to map the access database by using the makemap command while in the /etc/mail directory.

# makemap hash access < access

Relay Domains - Acting as a Secondary Mail Server

Setting up a secondary mail server is really easy with sendmail. First ensure that your MX records are correct and the mail server has an appropriate weight for a secondary mail server then add the domain that you wish to provide secondary mail services for into the relay-domains file in /etc/mail. Make sure you restart sendmail for the changes to take effect. Note that your mail server can perform more than one role at once, it may be secondary mail server for several domains and primary mail server for several others without any issues.

yourrelaydomain.com