Today I’d like to describe setup of sendmail that allows to establish receiving of e-mails for certain domain and sort incoming messages between virtual users. Those users must be able to fetch received e-mails via POP3 or IMAP protocols with or without TLS encryption. The key aspect of this kind of setup is that we will make sendmail working with virtual users which aren’t present in /etc/passwd so once it’s necessary to create new mailbox it’s not required to add new Unix/Linux account into system. Also, unlike similar configurations based on postfix we will not run mysql or postgres databases to store list of users, their settings, mail routing etc. — everything is stored in text files.
Whole setup relies on the following components: sendmail – receives mails from MTAs around the Web and sorts incoming mails between users of mail system, procmail makes it possible to apply various custom configurations for selected users e.g. set up autoresponder, filter e-mails etc., spamassassin is well known spam filter, dovecot — POP3 and IMAP service daemon.
1. Sendmail installation procedure depends on your Linux distribution but in most cases it is enough to install corresponding binary package e.g. sudo yum install sendmail or sudo apt-get install sendmail. But it is also natural idea to compile sendmail from sources to get the most fresh version — this is perfectly covered at sendmail.org.
2. If you run one of major Linux distributions you should just execute something like below in command line to get all other required components installed:
sudo apt-get install procmail spamassassin dovecot
or
sudo yum install procmail spamassassin dovecot
The possibility to install all the components from sources is still open [for geeks only].
3. Sendmail’s configuration is stored in /etc/mail directory and by default it is configured not to receive mails for any domain. We should change by adding ‘example.com’ domain to /etc/mail/local-host-names file. Please notice that MX DNS entry for your domain e.g. “example.com” should point to server where you’re trying to set up sendmail.
4. There is another key configuration file /etc/mail/virtusertable that holds all mail routing information, e.g. below line tells sendmail that all incoming mails to test@example.com should go to user ‘user1.virtual’:
test@example.com user1.virtual
The following line routes rest incoming mails to user2.virtual:
@example.com user2.virtual
5. As it comes from their names user1.virtual and use2.virtual are virtual so they shouldn’t be present in /etc/passwd. In order to make sendmail to deliver mails to virtual users it is required to specify them in /etc/alias file. E.g. if we plan to route mails destined to test@example.com to user1.virtual we should add the following line to /etc/alias:
user1.virtual: |/etc/smrsh/user1.virtual
This line tells sendmail that it should execute script /etc/smrsh/user1.virtual to deliver mail to user1.virtual. Please notice that if you place the script to ther directory than /etc/smrsh setup wont’ work. Now let’s see the contents of /etc/smrsh/user1.virtual, it contains one line including the path to procmail binary and procmailrc script for user1.virtual user:
[root@server ~]# cat /etc/smrsh/user1.virtual
/usr/bin/procmail /etc/procmail.d/user1.virtual
/etc/procmail.d/user1.virtual file includes all custom settings for user1.virtual virtual user, e.g. below is an example that will receive mails to test@example.com, check them for spam and store into user1.virtual’s inbox:
[root@server ~]# cat /etc/procmail.d/user1.virtual
PATH=/bin:/usr/bin:/usr/contrib/bin:/usr/sbin:/usr/local/bin:/sbin
MONTHYEAR=^Date +%y%m
VHOME=/var/spool/virtual/example.com/mail/user1.virtual
LOGFILE=/var/spool/virtual/example.com/logs/user1.virtual/log
LOGABSTRACT=all
VERBOSE=on
# Spam filter
:0fw
| /usr/bin/spamc
:0:
* ^X-Spam-Status: Yes
$VHOME/spam
:0:
$VHOME/inbox
As you can see spam mails will be stored in inbox while spam e-mails will be forwarded to file named ’spam’. Later on you will be able to access inbox using POP3 and spam using IMAP service. In order to prepare user1.virtual’s inbox you should do the following:
mkdir -p /var/spool/virtual/example.com/mail/user1.virtual
mkdir -p /var/spool/virtual/example.com/logs/user1.virtual
chown mail.mail /var/spool/virtual/example.com/mail/user1.virtual -R
chown mail.mail /var/spool/virtual/example.com/logs/user1.virtual -R
As for spamassassin, it is comes configured by default so in order to start it you should start spamd daemon e.g. by command service spamd start or /etc/init.d/spamd start. You can get more information about how to configure it at SA’s website.
From this point you may try sending mails to test@example.com and see log entries in /var/spool/virtual/example.com/logs/user1.virtual/log and incoming mails in /var/spool/virtual/example.com/mail/user1.virtual/inbox. If something goes wrong it makes sense to look into /var/log/maillog sendmail’s main log file.
5. Default configuration of dovecot is rather useful and makes it possible to establish POP3 and IMAP services for virtual users in seconds. Let’s imagine you’re running dovecot 2.x version, here are some configuration keys you should add into dovecot’s config, e.g. /etc/dovecot/dovecot.conf:
protocols = pop3 imap
service pop3-login {
inet_listener pop3 {
port = 110
}
}
service imap-login {
inet_listener imap {
port = 143
}
}
ssl = yes
ssl_cert = </etc/dovecot/keys/server.crt #server's self signed certificate generated by openssl
ssl_key = </etc/dovecot/keys/server.key # server's private key generated by openssl
default_login_user = mail
default_internal_user = mail
first_valid_uid=8 #this is UID of mail user that you can see in /etc/passwd
auth_mechanisms = plain login cram-md5 digest-md5
mail_location = mbox:/var/spool/virtual/example.com/mail/%u/
userdb {
driver = passwd-file
args = username_format=%n /etc/dovecot/passwd
}
passdb {
driver = passwd-file
args = username_format=%n /etc/dovecot/passwd
}
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot-info.log
debug_log_path = /var/log/dovecot-debug.log
Once you make sure your dovecot’s configuration includes mentioned lines you’re welcome to try starting dovecot either by service dovecot start or by just ‘dovecot’. In case of success you will see 110 and 143 ports in output netstat -lnp or errors in dovecot’s log file /var/log/dovecot.log. Let’s imagine it started without problems 
Now it’s time to set up the password for user1.virtual user, according to dovecot’s configuration suggested above the passwords are stored in /etc/dovecot/passwd. This is a text file, here is example line from it:
user1.virtual:{PLAIN}pass123:8:12
In this example user1.virtual has password pass123 stored in plain text, 8 is UID of mail user in your /etc/passwd, 12 is GID of mail group (you can also check this in /etc/passwd).
Fin.
Some time ago I found it pretty useful to configure Nagios monitoring system to send me a phone call in case of some critical problem. If some mission critical application goes down at night most probably you’ll miss an e-mail or sms notifying about that but won’t miss a telephone call to your cell phone. Honestly a telephone call is much more notorious rather than IM message notification or, again, e-mail/sms. You’re welcome to see below how to configure your Nagios for that.
