Sendmail relay configuration on AIX
This document describes how to set up a Sendmail e-mail gateway or relay which will be able to process incoming mail and route it to different mail servers based on domain information. The routing table is based on the Sendmail mailertable feature instead of the usual MX record based routing. This will come handy when there is a need to route mail internally in a different way than externally.
AIX configuration
Make sure "bos.net.tcp.adt" is installed.
The file /usr/samples/tcpip/sendmail/cf/aixsample.mc describes a minimal sample configuration. That can be used as the basis of your configuration. Please note however that there are some dangerous default settings in that file which must be changed before deployment.
Sendmail configuration: the sendmail.mc
I made my /etc/mail/sendmail.mc look like this:
divert(0)dnl OSTYPE(aixsample)dnl FEATURE(`mailertable',`dbm /etc/mail/mailertable')dnl FEATURE(virtusertable)dnl FEATURE(domaintable)dnl FEATURE(no_default_msa) FEATURE(relay_hosts_only)dnl FEATURE(access_db) FEATURE(`greet_pause',5000)dnl DOMAIN(generic)dnl define(`confSMTP_LOGIN_MSG', `$j Sendmail $b') define(`confPRIVACY_FLAGS',`authwarnings,novrfy,noexpn,noverb')dnl define(`confBAD_RCPT_THROTTLE', `1')dnl define(`confCONNECTION_RATE_THROTTLE', `100')dnl MAILER(local)dnl MAILER(smtp)dnl MAILER(uucp) DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
To process the .mc file into a proper Sendmail configuration file, sendmail.cf, use the following commands:
cd /usr/samples/tcpip/sendmail/m4/ m4 cf.m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Security
I removed three lines and added one to the sample configuration file for security before deploying it.
I removed the lines:
FEATURE(accept_unresolvable_domains)dnl FEATURE(accept_unqualified_senders)dnl FEATURE(promiscuous_relay)dnl
promiscuous_relay
This is important! Leaving the promiscuous_relay feature on will make your server an open relay and thus a good host for spammers to do what they do. It *being a default setting is quite unbelievable. **So remember to remove it.*
There is usually no need to keep the other two options, accepting unresolvable domains or unqualified senders. Those will just close some holes form spammers.
The lines I added to the sample configuration are:
FEATURE(relay_hosts_only)dnl FEATURE(access_db) FEATURE(`greet_pause',5000)dnl define(`confPRIVACY_FLAGS',`authwarnings,novrfy,noexpn,noverb')dnl define(`confBAD_RCPT_THROTTLE', `1')dnl define(`confCONNECTION_RATE_THROTTLE', `100')dnl
greet_pause
The greet_pause feature makes sendmail wait for a specified amount of time at the beginning of an incoming connection, before greeting the connecting party. A value of 5000 means 5 seconds. Proper mail clients will wait for the greeting, while many spambots start flooding immediately. They will be discarded by this rule.
authwarnings
The authwarnings privacy flag tells sendmail to insert X-Authentication-Warnings: headers into the mail whenever it suspects that the message is not authentic.
novrfy
The novrfy privacy flag will deny email address verification queries (the VRFY allows anyone to check if a user exists in your mail server - this will prevent it).
noexpn
The noexpn privacy flag will deny mailing list queries (the EXPN allows anyone to check who belongs to your mailing lists - this will precent it).
noverb
The noverb privacy flag will deny requests for verbose mode, which might reveal information about your installation to an outsider.
BAD_RCPT_THROTTLE
The BAD_RCPT_THROTTLE setting will add an additional annoyance for spammers. If a specified number of recipients in a single SMTP transaction have been rejected, sendmail will sleep for one second after each subsequent RCPT command in that transaction. That will make it impractical to try and guess usernames. Legitimate mail will get delivered, though.
CONNECTION_RATE_THROTTLE
The CONNECTION_RATE_THROTTLE Sets the maximum number of connections permitted per second per daemon. After this many connections are accepted, further connections will be delayed. It will protect agains denial-of-service attacks and spammers opening hundreds of connections to your server.
Allow incoming mail relay
Add the domains you wish to serve to /etc/mail/local-host-names:
targetdomain1.com targetdomain2.com targetdomain3.com
Domain-based routing: the mailertable
This is a feature that allows you to route mail to certain domains via given mail gateways.
The /etc/mail/mailertable could look like this (please edit before deploying):
targetdomain1.com smtp:targethost1.example.com targetdomain2.com smtp:targethost2.test.net targetdomain3.com smtp:[192.168.0.1]
Allow incoming relay: the access
The mail domains your server is allowed to relay from outside (the Internet) must be listed in the /etc/mail/access
To:targetdomain1.com RELAY To:targetdomain2.com RELAY To:targetdomain3.com RELAY
This feature needs the access_db feature to be enabled in sendmail.mc.
Don't put these domains in the /etc/mail/local-hosts file (you should put there only the mail domains your host will receive itself).
Allow outgoing relay (optional)
This part is optional but useful. If you want hosts in your internal network to be able to use the server as an outgoing relay, add the hosts to the file /etc/mail/access:
192.168.0. RELAY 192.168.1.1 RELAY 192.168.1.2 RELAY
Other configuration files
Also, create some files sendmail wants to see in /etc/mail:
touch /etc/mail/domaintable touch /etc/mail/virtusertable touch /etc/mail/local-host-names
Make the configuration files readable by everybody:
chmod 644 /etc/mail/*
Make sure your /etc/syslog.conf includes a line like:
mail.debug /var/log/maillog
That will put mail related entries into their own log file.
Updating configuration with make
To keep configuration files and Sendmail database files up to date, I usually create a Makefile which includes the rules to compile all changed configuration files. This is what I used here. The contents of /etc/mail/Makefile look like this:
all: access.db access.dir access.pag \
aliases.db aliases.dir aliases.pag \
domaintable.db domaintable.dir domaintable.pag \
mailertable.db mailertable.dir mailertable.pag \
virtusertable.db virtusertable.dir virtusertable.pag \
sendmail.cf
access.db: access
makemap hash /etc/mail/access </etc/mail/access
access.dir access.pag: access
makemap dbm /etc/mail/access </etc/mail/access
aliases.db: aliases
makemap hash /etc/mail/aliases </etc/mail/aliases
aliases.dir aliases.pag: aliases
makemap dbm /etc/mail/aliases </etc/mail/aliases
domaintable.db: domaintable
makemap hash /etc/mail/domaintable </etc/mail/domaintable
domaintable.dir domaintable.pag: domaintable
makemap dbm /etc/mail/domaintable </etc/mail/domaintable
mailertable.db: mailertable
makemap hash /etc/mail/mailertable </etc/mail/mailertable
mailertable.dir mailertable.pag: mailertable
makemap dbm /etc/mail/mailertable </etc/mail/mailertable
virtusertable.db: virtusertable
makemap hash /etc/mail/virtusertable </etc/mail/virtusertable
virtusertable.dir virtusertable.pag: virtusertable
makemap hash /etc/mail/virtusertable </etc/mail/virtusertable
sendmail.cf: sendmail.mc
cd /usr/samples/tcpip/sendmail/m4; \
m4 cf.m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
That way, after you make changes to configuration files, just go to /etc/mail and run make. That will update all configuration files as needed. Give the sendmail process a kill -HUP after that to make it read its configuration again.
cd /etc/mail make kill -HUP
Running Sendmail
Start command:
startsrc -s sendmail -a "-bd -q30m"
Stop command:
stopsrc -s sendmail
Update configuration (see section above):
cd /etc/mail make kill -HUP
See the queue:
sendmail -bp
Watch your mail log:
tail -f /var/log/maillog
Watch while Sendmail processes the mail queue:
sendmail -q -v
Routing your mail: the DNS records
When your new relay server is up and running, and verified to work correctly, it is time to update the DNS records of the domains to route mail through your new server(s).
targetdomain1.com. IN MX 10 mail1.koo.fi. targetdomain2.com. IN MX 10 mail2.koo.fi.
The second part is needed only if you configured two servers. The number "10" there is priority. By giving both servers the same priority, incoming mail will be split somewhat equally between them.
Also make sure your own domain has A records for the mail server:
mail1.koo.fi. IN A 192.168.1.1 mail2.koo.fi. IN A 192.168.1.2
And third, it is also crucial to add your servers to your IP network's reverse lookup DNS zone. In this example case it would be the 1.168.192.in-addr.arpa domain:
1.1.168.192.in-addr.arpa. IN PTR mail1.koo.fi. 2.1.168.192.in-addr.arpa. In PTR mail2.koo.fi.
A reverse mapping is needed, because a lot of Internet's mail servers are configured to check for its existence. This, once again, to make life harder for spammers.