Adaptado por Félix Molinuevo, FMSI Sistemas de Informática
I wanted to run a complete mail server for my company. I decided to encrypt and authenticate connections for both sending and receiving mail, and to handle receiving mail with IMAP, rather than POP. The final setup can handle large amounts of both incoming and outgoing mail and is easy to use…
I had two basic options when selecting how to handle accounts. Either every valid mail account could be tied to a valid user account on the mail server, or I could set up a backend such as an SQL or LDAP database to handle authentication that wouldn't be tied to the server.
Based on my needs and relatively small number of potential users, I decided to go with mail delivery to local user accounts, while retaining support for virtual domains. This way I can support any domain with an MX record pointing to the mail server, and not just my own domain, but mail will be delivered to and authenticated against SASL user accounts.
Since most of our servers are running Debian Etch, I changed the former howto to reflect the changes. All packages except the SquirrelMail SIEVE plugin are straight out of the Debian package management system.
The software used is:
Before installing software make sure the current system is up to date:
aptitude update aptitude upgrade
At this point everything should be ready to go. The default MTA on debian, Exim, should be uninstalled by apt automatically when postfix is installed. Everything else is probably new software.
aptitude install postfix
This installs a postfix system that is ready to be setup for TLS (SSL) encrypted connections. I chose reasonable defaults to the questions the debian installer asks. Anything that needs to be changed can be changed later without much trouble. At this point local delivery probably works, but the system is far from complete. I didn't worry about it at this point, since the way the system will be set up I also need to tie postfix into SASL and IMAP, and probably send it to Spamassassin for filtering as well.
Next install all the needed packages from project Cyrus, namely the SASL library, the Cyrus admin and client programs, and the Cyrus IMAP daemon. Although it is available, I will not install the corresponding Cyrus POP3 server. This is an IMAP only setup.
aptitude install libsasl2 libsasl2-modules sasl2-bin aptitude install cyrus-admin-2.2 cyrus-clients-2.2 cyrus-common-2.2 cyrus-imapd-2.2
Start with configuring Cyrus-SASL for authentication in general. Both the SMTP server, postfix, and the IMAP server, Cyrus-IMAP, will authenticate using another piece of daemon software, saslauthd. Saslauthd will handle the actual authentication of users. With this in mind, start first by configuring SASL to authenticate against the system accounts using PAM.
Edit /etc/default/saslauthd to enable the daemon and set the authentication mechanism.
START=yes MECHANISMS="sasldb"
If you want to use another authentication mechanism, this is where you would set it. The system here authenticates against SASL accounts, so sasldb is the relevant method.
Start up the server now to test it.
/etc/init.d/saslauthd start
Now create some user account in SASL:
saslpasswd2 -c username
Then test it.
testsaslauthd -u username -p password
If it works, you should see
0: OK "Success."
as a result. If so, saslauthd works ok. Now shut it back down.
/etc/init.d/saslauthd stop
In order Postfix can communicate to SASL and Cyrus (check later configuration), you must mount /var/run/saslauthd and /var/run/cyrus inside the postfix chroot. This can be accomplished by using a bind mount. To implement this, add the following line to /etc/fstab.
/var/run/saslauthd /var/spool/postfix/var/run/saslauthd none rw,bind 0 0 /var/run/cyrus /var/spool/postfix/var/run/cyrus none rw,bind 0 0
Create the directory the mount will reside in as well.
mkdir -p /var/spool/postfix/var/run/saslauthd mkdir -p /var/spool/postfix/var/run/cyrus
And mount them.
mount /var/spool/postfix/var/run/saslauthd mount /var/spool/postfix/var/run/cyrus
The same location is now accessable outside the chroot at /var/run/saslauthd and inside the chroot at /var/spool/postfix/var/run/saslauthd (which postfix sees as /var/run/saslauthd). This avoids editing the saslauthd init script, messing with dpkg, and creating symbolic links. The only visible side effect is an extra listing from the df
command which doesn't know that the bind mount isn't an actual separate disk.
As an advice, don't change other things related to SASL authentication, as is written in some README.Debian in Postfix package, because we're using another method to make Postfix communicate to SASL.
There are a lot of steps necessary to get postfix up and running. It needs to be set up to connect to saslauthd, to use SSL, and to link with cyrus-imapd and Squirrelmail. This section will go over the first stages of configuring postfix, but later sections will cover the other parts.
Edit the file /etc/postfix/main.cf and add the following lines to the file.
# SASL Auth Settings smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Be sure to have the proper name for your server:
myhostname = host.domain.com
And the proper final destination, relay host and accept mails from your network, if you want it:
mydestination = host, host.domain.com, localhost.localdomain, localhost.localdomain, localhost, whatever.com relayhost = aaa.bbb.ccc.ddd mynetworks = 127.0.0.0/8 192.168.1.0/24
If you need SASL authentication on your relayhost/smarthost, add following lines:
# Authentication on smarthost smtp_sasl_auth_enable = yes smtp_sasl_security_options = smtp_sasl_password_maps = hash:/etc/postfix/client_passwords smtp_sasl_loglevel = 2
If you need this, you should add in /etc/postfix/client_passwords the pair username/password for your relayhost:
relayhost.domain.com username:password
and later execute postmap to compile such info:
postmap /etc/postfix/client_passwords
Also edit /etc/postfix/sasl/smtpd.conf and put in the lines:
pwcheck_method: saslauthd mech_list: PLAIN LOGIN
You also need to add postfix to the sasl group:
adduser postfix sasl
Reload postfix and check to see if auth is enabled.
/etc/init.d/postfix reload telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 dev.ev-15.com ESMTP Postfix (Debian/GNU)
Type in EHLO domain.com
. If the server responds with something like the following, then authentication is enabled in the server. Then type quit
to exit.
250-mail.domain.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME
Postfix should now tie authentication into itself using saslauthd. Note that the advertised authentication methods are only PLAIN and LOGIN, both of which are plain text based. To enable one of the shared secret methods, such as CRAM-MD5 or DIGEST-MD5, a different authentication method would need to be used. To avoid delivering these plain passwords over the internet, wrap everything up in an encrypted layer using SSL/TLS.
Note: this section is needed for Cyrus IMAP to support SSL.
Certificates are required to use TLS and SSL. There are generally two classes of certificates: self-signed certificates and certificates signed by one of the major certificate authorities. If you need implicitly trusted certificates that you can use and let your customers be comfortable with, you'll probably want to go to a CA and purchase them. With smaller sites and users who understand certficate warnings, self-signed certificates are easy to create and still allow encryption. They will throw up warnings in mail clients and web browsers, but the certificates can usually be permanently accepted by users.
If the primary goal is encryption and the trust issues are not major, then a self-signed certificate is adequate.
The following steps will create a new CA, certificate request, and certificate.
Start with making a new CA.
cd /usr/lib/ssl/misc ./CA.pl -newca
Answer the questions as they come with reasonable information. The value for CN (Common Name) should be the hostname of the server that the certificates will be used on.
Now make the server certificate request.
./CA.pl -newreq-nodes
Now sign it
./CA.pl -sign
Copy the files to /etc/ssl/certs
cp -iva newcert.pem /etc/ssl/certs/ cp -iva newreq.pem /etc/ssl/certs/ cp -iva newkey.pem /etc/ssl/certs/ cp -iva demoCA/cacert.pem /etc/ssl/certs/
Edit /etc/postfix/main.cf again and add the following lines to the file.
# TLS Information smtpd_use_tls = yes #smtpd_tls_auth_only = yes smtpd_tls_key_file = /etc/ssl/certs/newkey.pem smtpd_tls_cert_file = /etc/ssl/certs/newcert.pem smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom
Edit /etc/postfix/master.cf and uncomment the following lines.
tlsmgr fifo - - n 300 1 tlsmgr smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
This will enable TLS, the smtps port, and the dedicated port 587 for mail submission.
The line #smtpd_tls_auth_only = yes
will be uncommented later so that users are required to encrypt their connections. For now though leave it alone until testing is complete. To test, telnet in again, as above, and see if the line 250-STARTTLS
is there. If so then TLS should be available.
This guide uses Cyrus-IMAP, largely because it is high performance, and because of SIEVE server-side filtering. One thing to note about this package is that it takes the “black box” approach to IMAP mail delivery. Mail is never delivered to a user's home folder, but rather to a set of dedicated cyrus folders. If you would rather mail either be delivered to maildirs or mbox files, then the Courier- or UW-IMAP servers would be better choices. Later on SquirrelMail and a plugin to easily edit SIEVE scripts will be installed.
Open the file /etc/cyrus.conf for editing and choose which services to run. Unless POP access is desired, leave only IMAP, secure IMAP, and SIEVE. For extra security turn off IMAP to force users to connect over SSL. Under the SERVICES section, uncomment the line
imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100
and comment out the pop3 lines.
Uncomment following line, in order Squatter can index daily all mailboxes:
# reindex all mailboxes (fulltext) daily squatter_a cmd="/usr/sbin/squatter" at=0517
This setup uses LMTP. The default socket set in the file should be fine. The line for sieve should already be uncommented, but check it just to be sure. Everything else in the file can stay the way it was.
Now open the file /etc/imapd.conf. Most of the settings can be left the way they are, but there are a few more to set. As always, read the comments for the various settings in the file. The directive sieveusehomedir
should be set to false so that remote sieve management with SquirrelMail will work.
The way this setup is working, the following values should be set:
admins: cyrus allowplaintext: yes sasl_mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN sasl_pwcheck_method: saslauthd
Notes about sasl_mech_list: DIGEST-MD5 is the best mechanism. CRAM-MD5 is better than PLAIN and LOGIN. The last two are needed just in case.
Set the following values in imapd.conf, leaving the rest alone.
tls_cert_file: /etc/ssl/certs/newcert.pem tls_key_file: /etc/ssl/certs/newkey.pem tls_ca_file: /etc/ssl/certs/cacert.pem tls_ca_path: /etc/ssl/certs
Change ownership of files inside /var/lib/cyrus and /var/spool/cyrus:
chown -R cyrus: /var/lib/cyrus/* chown -R cyrus: /var/spool/cyrus/*
Restart cyrus.
/etc/init.d/cyrus2.2 restart
Then, start saslauthd again.
/etc/init.d/saslauthd start
The way things are set up, only the cyrus user can administer the cyrus server. Set a password for the user cyrus and then su to the cyrus user.
passwd cyrus su cyrus
You should create the user cyrus in SASL, too:
saslpasswd2 -c cyrus
Now add an IMAP user. Usernames are prefaced with user.
, followed by the login name of the user. For a user account jimmy, the mailbox would be named user.jimmy
.
Log into the cyrus admin tool and create a new mail user to match a local delivery name that postfix knows. Do this for each local account that receives mail, or postfix will throw errors.
$ cyradm localhost cyradm> cm user.username ... repeat for all users ... cyradm> quit
You can log into cyradm with user cyrus directly too, without using a cyrus system account (I prefer this way):
cyradm -u cyrus localhost
Additionally it's needed to add a mail alias for every mail account, because we're using users created in SASL, but not in system. So Postfix needs to know how to deliver mail.
Edit /etc/aliases adding for every mail account something like:
username: username
It's an alias for the same account. Later, execute “newaliases” command to compile the new aliases.
Edit the file /etc/postfix/main.cf and add the following line to the file, removing or commenting out any other mailbox_transport =
lines.
mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
That transport will work just if you mount /var/run/cyrus inside Postfix's chroot, as explained before.
Create the lmtp group and add postfix to that group.
addgroup lmtp adduser postfix lmtp
Fix the socket directory permissions and restart both mail servers.
dpkg-statoverride --force --update --add cyrus lmtp 750 /var/run/cyrus/socket /etc/init.d/postfix restart /etc/init.d/cyrus2.2 restart
Cyrus should now be linked to Postfix. All mail from Postfix will be handed off to the Cyrus server for delivery. This will fail if Postfix tries to deliver mail for a user Cyrus doesn't know about, so make sure that when new users are added to the mail system that the corresponding mailboxes are also added with cyradm.
If the mail server will handle more than one domain but deliver all mail to local users, then the following information will configure this behavior. This is based on the guide at http://www.postfix.org/VIRTUAL_README.html.
Create the file /etc/postfix/virtual and populate it with entries like the following
user1@domain1.com realuser1 user2@domain1.com realuser2 user3@domain2.com realuser1 # send all mail for domain3 to realuser3 @domain3.com realuser3
The left side maps to the email address people will send mail to, and the right side maps to the local system account that mail will be delivered to (through Cyrus IMAP). Once this file has been created, it needs to be hashed for postfix to use, so run the postmap command to do this:
postmap /etc/postfix/virtual
Edit /etc/postfix/main.cf and add the following lines.
# Virtual Domain Settings virtual_alias_domains = domain1.com, domain2.com, domain3.com virtual_alias_maps = hash:/etc/postfix/virtual
This tells Postfix which domains to deliver to, and what file to use to check where to deliver the mail. It's pretty simple to get going. Reload Postfix again and things should work. Basic system setup should be complete at this point.
The most useful information for troubleshooting is found in the /var/log/mail.log file. Open a console and use the command
tail -f /var/log/mail.log
to watch mail server activity. Send a few test mails to an address on the server, and use the server to send test mails to other accounts. If errors occur use the information in the mail log file to try to track them down.
After things are working well it is a good idea to uncomment the line “smtpd_tls_auth_only = yes” and change the value of “smtpd_tls_loglevel” to something lower, such as 2.
When you are testing, sometimes you need to deactivate “duplicate supression” feature of Cyrus. Do it adding in /etc/imapd.conf the following:
duplicatesuppression: no
aptitude install spamassassin spamc
No further tuning needed.
aptitude install rar unrar lha arj unzoo zip unzip bzip2 gzip cpio file lzop nomarch cabextract ripole \ rpm pax p7zip zoo ncompress aptitude install clamav clamav-base clamav-daemon clamav-freshclam clamav-docs
Libclamav and other packages will be automatically installed.
Make sure the directive 'AllowSupplementaryGroups' exists in the file /etc/clamav/clamd.conf.
aptitude install amavisd-new
Add the user 'clamav' to the group 'amavis':
adduser clamav amavis
Restart the daemons:
/etc/init.d/clamav-daemon restart /etc/init.d/clamav-freshclam restart
If our hostname in /etc/hostname is not a FQDN (Fully Qualified Domain Name), that is to say it's a name of the type “server” instead of a name of the type “mail.domain.com”, we will have to modify the file /etc/amavis/conf.d/50-user, adding:
$myhostname = "mail.domain.com";
so that Amavis has the right value of the variable $myhostname.
In the same configuration file, add the following two lines in order Amavis to send quarantine spam/virus to mail accounts:
$virus_quarantine_to = "virus-police\@mail.domain.com"; $spam_quarantine_to = "spam-police\@mail.domain.com";
Activate the use of ClamAV and the SpamAssassin spam filter in the Amavis config by editing the file /etc/amavis/conf.d/15-content_filter_mode and commenting out the following lines:
@bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re); @bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
If you wanna spam being blocked and sended to spam-police account, edit /etc/amavis/conf.d/20-debian_defaults:
$final_spam_destiny = D_DISCARD;
and comment the following line if you don't want Amavis to modify the subject of the emails marked as spam:
# $sa_spam_subject_tag = '***SPAM*** ';
If you wanna spam pass to user's accounts, edit /etc/amavis/conf.d/20-debian_defaults:
$final_spam_destiny = D_PASS;
add to /etc/amavis/conf.d/50-user the following line changing the names as needed in your system, and comment the line who says about mail for spam:
@local_domains_maps = ([ ".$mydomain", 'sub.example.net', '.example.com', 'localhost' ]); # $spam_quarantine_to = "spam-police\@mail.domain.com";
Finally, comment out the following line if you want Amavis to modify the subject of the emails marked as spam:
$sa_spam_subject_tag = '***SPAM*** ';
This way we let emails marked as spam pass and rely on the user using SIEVE filters (or the filters provided by his or her email client) to filter the spam by looking at the headers. Viruses are discarded.
Here you are my recommended configuration for allowed and banned attachments. You may want to evaluate the needs of your company and finetune it as needed. Comment out these lines:
qr'^application/x-msmetafile$'i, qr'^\.wmf$', qr'^message/partial$'i, qr'^message/external-body$'i, [ qr'^\.(Z|gz|bz2)$' => 0 ], [ qr'^\.(rpm|cpio|tar)$' => 0 ], [ qr'^\.(zip|rar|arc|arj|zoo)$'=> 0 ], qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|hta| inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|mst| ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs| wmf|wsc|wsf|wsh)$'ix, qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i, qr'^\.(exe|lha|tnef|cab|dll)$',
I configure next lines usually with following values (very strict spam filter):
$sa_tag_level_deflt = -1000; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 1.0; # add 'spam detected' headers at that level $sa_kill_level_deflt = $sa_tag2_level_deflt; # triggers spam evasive actions $sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent
Add these to /etc/postfix/master.cf:
smtp-amavis unix - - y - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - y - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
And add this to /etc/postfix/main.cf:
content_filter=smtp-amavis:[127.0.0.1]:10024
Restart Postfix:
/etc/init.d/postfix restart
In addition to basic mail service, it is also possible to provide webmail service using the SquirrelMail package, spam filtering with SpamAssassin, and server-side mail filtering with SIEVE.
To use webmail, first set up Apache if it is not already working. To install Apache:
aptitude install apache2 libapache2-mod-php5
Since users will log in to SquirrelMail using a web form it is a good idea to enable SSL on the web server. Apache uses a certificate of a slightly different form than has been used in this guide so far. It combines the site certificate with the private key from the certificate request. To create this file copy the private key from newreq.pem and the signed certificate from newcert.pem into a new file /etc/apache2/ssl/apache.pem.
Enable the SSL module.
a2enmod ssl
Copy the default configuration file in /etc/apache2/sites-available/default to a new file in /etc/apache2/sites-available, such as default-ssl. Edit the file. Change the <NameVirtualHost *>
line to <NameVirtualHost *:443>
the <VirtualHost *>
line to <VirtualHost *:443>
and add the following lines to the file inside the VirtualHost directive:
SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.pem
Edit the default site file and change the line <NameVirtualHost *>
to <NameVirtualHost *:80>
and the line <VirtualHost *>
to <VirtualHost *:80>
.
Now open the file /etc/apache2/ports.conf and add the following line to the file.
Listen 443
Enable the new SSL-enabled site.
a2ensite default-ssl
Restart Apache.
/etc/init.d/apache2 force-reload
Now that Apache is up and running, install the SquirrelMail package.
aptitude install squirrelmail
Run the configuration for SquirrelMail and adjust the settings for your system.
squirrelmail-configure
The configuration is quite straightforward. Once that is done try logging into the newly created squirrelmail site (The line Include /etc/squirrelmail/apache.conf
may need to be added to /etc/apache2/apache2.conf). If you can log in to the site then SM is up and running.
SIEVE is a simple yet powerful way to filter mail on the server side. In this setup it is part of the Cyrus IMAP server package, and runs on port 2000. I waited this long to introduce it, because I find the nicest way to build sieve scripts is with the AvelSIEVE plugin for SquirrelMail. First download the plugin from the SquirrelMail site and untar in in the SquirrelMail plugins folder. Copy the sample configuration to the real file and edit it to your configuration. If you're like me you didn't have to change anything.
Run the SquirrelMail configure script again and select plugins to view the list of available plugins. Type the number of the avelsieve plugin to enable it. Save your prefs and exit, and go back to your SquirrelMail web page to test it.
Click on the new filters link on the top bar. If you get an error about connecting, check /etc/cyrus.conf. If you get a connection refused error test sieve using sivtest. If you can connect to localhost but not your machines dns name, you'll have to edit that config file to fix the problem. I removed the “localhost” parameter from the sieve init line.
If you get a dialog that will let you add a new rule, congratulations. You're set. I usually create rules based on the X-Spam-Flag header to move mail to INBOX.Junk, and a few others to move mailing lists to their respective folders. Always make sure you save your rules before you leave the page though, or they will not take effect.
The nice thing about the sieve filters is that even though I set them up through squirrelmail, they run at the IMAP server level, and all mail you get through IMAP is filtered according to your rules.
That's pretty much it. The mail server can now send and receive mail, authenticate users, encrypt connections with SSL, and provide webmail and server-side mail filtering. Good luck with it.
Félix Molinuevo
FMSI Sistemas de Informática
Based on documentation written by Steve Block, 29 January 2005
This guide wouldn't be possible without the developers of all the software packages used here. I would like to extend my thanks to all of the developers. Thanks are also due to the Debian developers and package maintainers for their sensible setup of the base Debian system and its corresponding packages.
Thanks to Steve Block for teach me how to build my first mail server; and thanks to him again for show me DokuWiki, the wiki we're using now, simple, easy, and fast.