This is an old revision of the document!
The aim is to put together a simple but secure mail setup for sihnon.net
.
The primary MX will be Shadow and the intention is to install a backup MX at a later date.
Set the following global USE flags:
For sending and receiving mail
For content filtering:
These configuration files are stored in subversion, under configs:/mail/primary/postfix.
The network_table
hash defines the list of local network addresses. Hosts in these ranges will be allowed to relay mail through postfix. According to http://www.irbs.net/internet/postfix/0709/1630.html, the format of this file requires a CIDR block on the left hand side, and any arbitrary comment on the right hand side:
/etc/postfix/network_table|<syntax lang="pf">
127.0.0.0/8 Localhost
10.0.0.0/24 Local
10.0.2.0/24 Wireless
10.10.0.0/24 VPN
10.10.1.0/24 VPN
78.86.202.79 Public
78.86.202.81 Public
78.86.202.83 Public
78.86.202.85 Public
78.86.202.87 Public
78.86.202.89 Public
78.86.202.91 Public
78.86.202.93 Public
</syntax>
The ldap-aliases.cf
file contains the configuration for reading aliases from LDAP:
/etc/postfix/ldap-aliases.cf|<syntax lang="conf">
server_host = ldap://ldap.sihnon.net ldap://ldap-slave.sihnon.net
server_port = 389
start_tls = yes
version = 3
bind_dn = cn=Postfix,ou=Services,ou=People,dc=sihnon,dc=net
bind_pw = ******
scope = sub
search_bash = dc=sihnon,dc=net
</syntax>
In order to have dovecot handle the mail delivery itself, we need to add a record to the master.cf
file so that postfix knows how to pass the mails on. Add the following line to the file.
user=mail:mail
defines the permissions to run the deliver program as.-d ${user}
defines the email address of the recipient.Then tell postfix to use the dovecot transport instead of local for mail delivery
To deliver mail using the recipient user's uid/gid, the deliver binary needs to be run as root using setuid. This carries a security implication, so the permissions must be changed so that only postfix can execute it. The user=mail:mail
option in the postfix master.cf
sets which user deliver will be run as; it's important that this group is not shared with any other users.
<code bash>
chown root:mail /var/libexec/dovecot/deliver
chmod 0754 /var/libexec/dovecot/deliver
chmod u+s /var/libexec/dovecot/deliver
</code>
Using procmail has the advantage that users can implement server-side mail filtering before mails are delivered to the inbox. The main disadvantage of using procmail alone is that the dovecot indexes won't get updated as new mail arrives. The solution is to have procmail invoke dovecot's deliver to put the mail in the right place after working out where it needs to go.
This requires a slightly different setup than the dovecot approach above: deliver is invoked by the user rather than mail
, and should not be setuid. This also means users will need the privileges to create their own maildir in /var/spool/mail/
.
Setup postfix to deliver through postfix: /etc/postfix/main.cf|<syntax lang="pfmain"> - Pass all mail to procmail; the -p ensures the user's procmailrc is consulted before the system default mailbox_command = /usr/bin/procmail -p -a "$EXTENSION" </syntax>
Setup the default procmailrc, which hands all mail straight off to deliver /etc/procmailrc|<syntax lang="procmail"> - Use dovecot to deliver mail to a maildir in /var/spool/mail/ SHELL="/bin/bash" SENDMAIL="/usr/sbin/sendmail -oi -t" DELIVER="/usr/libexec/dovecot/deliver" MAILDIR="/var/spool/mail/$LOGNAME/" DEFAULT="$MAILDIR/" - Remove the leading space on the next line, required for wiki formatting. :0 | $DELIVER -d $LOGNAME - vim: set filetype=procmail: </syntax>
Set appropriate permissions on /var/spool/mail
. The directory sticky bit ensures that a user may only delete his or her own maildir, and not anyone elses.
<code bash>
chgrp mailusers /var/spool/mail
chmod g+w /var/spool/mail
chmod +t /var/spool/mail
</code>
The mailusers
group is defined in ldap, and contains any user who should be able to receive mail.
Start postfix up, and make sure it starts on boot. <code bash> rc-update add postfix default /etc/init.d/postfix start </code>
We will set up SPF to ensure that other sites know which mail servers are allowed to send mail for the sihnon.net domain. All local machines will be configured to route mail through the mail gateways here, which will be marked as trusted. To set up SPF for the local network, add the following records to DNS.
We can also set up postfix to check SPF records for inbound mail too. Add the following configuration to postfix: /etc/postfix/master.cf|<syntax lang="conf"> policy unix - n n - - spawn user=nobody argv=/usr/bin/policyd-spf </syntax>
Then configure postfix to reject mail from invalid mail servers by adding the following to smtpd_recipient_restrictions
>
/etc/postfix/main.cf|<syntax lang="pfmain">
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy
</syntax>
Then simply reload postfix for the changes to take effect: <code bash> /etc/init.d/postfix reload </code>
Every mail passing through the system will also be scanned for spam and viruses. Amavis is a mail content filter that handles talking to both SpamAssassin and ClamAV and dealing with mails as appropriate.
amavis has an incredibly long and slightly complex configuration file (~2500 lines of perl). That's too long to paste here, so this will only include the more interesting parameters. The full configuration is stored in subversion, under configs:/mail/primary/.
Also, go through the configuration file and enable/disable the virus scanners appropriately. We will be using clamd, but nothing else.
Amavis makes use of a list of local, “trusted” networks, and is configured above to read these from a file: /etc/amavisd-networks.conf|<syntax lang="conf"> - Loopback 127.0.0.1 - Local networks 10.0.0.0/24 10.0.2.0/24 - VPN 10.10.0.0/24 10.10.1.0/24 - Public networks 78.86.202.79 78.86.202.81 78.86.202.83 78.86.202.85 78.86.202.87 78.86.202.89 78.86.202.91 78.86.202.93 </syntax>
Start amavis up, and ensure it runs on boot: <code bash> /etc/init.d/amavisd start rc-update add amavisd default </code>
Edit the clam configuration files to include the settings listed below; these are fairly self explanatory but the comments in the file explain them well. The full configuration files are stored in subversion under configs:/mail/primary/.
Clamd runs under its own user account but will need access to the files processed by amavis; add it to the amavis group to ensure it can. <code bash> gpasswd -a clamav amavis </code>
Now start clam, and ensure it starts on every boot with the following: <code bash> /etc/init.d/clamd start rc-update add clamd default </code>
Certain plugins are disabled in spamassassin by default, so we will want to enable these. /etc/spamassassin/v310.pre|<syntax lang="conf"> loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::Razor2 </syntax> /etc/spamassassin/v312.pre|<syntax lanf="conf"> loadplugin Mail::SpamAssassin::Plugin::DKIM </syntax>
In order to use razor and pyzor, we need to configure them for the user account which will be running them - amavis
. Razor needs us to create and register an identity with the servers. It will use this to track a reputation, and revoke submissions if necessary. To use pyzor, we simply need to discover the available servers.
<code bash>
sudo su -s /bin/bash -l amavis
razor-admin -create
razor-admin -register -user=postmaster@sihnon.net
pyzor discover
exit
</code>
Dovecot is fairly simple to use, just install and configure it, then start it up.
Dovecot ships with a useful command shows which configuration options have been changed from the defaults values. This is useful for debugging, or documenting which options have been set. <code bash> dovecot -n </code>
These configuration files are stored in subversion, under configs:/mail/primary/dovecot.
Start dovecot up, and make sure it starts on boot: <code bash> rc-update add dovecot default /etc/init.d/dovecot start </code>
Roundcube is a pretty, AJAX based webmail client, which is pretty easy to install. Visit https://svn.roundcube.net/branches/ and find the branch for the latest release (this will be updated with security fixes only, you will need to change branches when a new version is released).
Check out a copy of the latest release above the webroot, then symlink it into the webroot itself: <code bash> cd /var/www/sihnon.net/webmail/ svn co https://svn.roundcube.net/branches/release-0.2.1 roundcube-svn ln -s roundcube-svn html/roundcube </code>
Use the installer to set up the configuration, at https://webmail.sihnon.net/roundcube/installer/, or edit the configuration file to contain the following: /var/www/sihnon.net/webmail/roundcube-svn/config/main.inc.php|<code php> $rcmail_config[['default_host']] = 'ssl://imap.sihnon.net:993'; $rcmail_config[['imap_auth_type']] = 'check'; $rcmail_config[['smtp_server']] = 'smtp.sihnon.net'; $rcmail_config[['smtp_port']] = 25; $rcmail_config[['smtp_user']] = '%u'; $rcmail_config[['smtp_pass']] = '%p'; $rcmail_config[['smtp_helo_host']] = 'webmail.sihnon.net'; $rcmail_config[['language']] = 'en_GB'; </code>
Change the current directory to the new branch, eg <code bash> svn switch https://svn.roundcube.net/branches/release-0.2.1 </code>
Then run the updater script to make sure the configuration file is up to date: <code bash> ./bin/update.sh </code>
pam_mail
alerts you to new (or indeed old) mail in your maildir when you log in (and sometimes after you shell has been inactive for a while). Disable these by commenting out references to pam_mail
in the /etc/pam.d/
configuration files.
<s>If you see errors like the following, the problem is related to the filesystem permissions - check that the users dovecot runs under has access to the mail directories.</s> Turns out this one is a bug in the 1.1 release, and is fixed in 1.1.14+. To work around the problem, set log_path
to log to a file instead of using syslog.
0@@