Virtual email domain With the power of personal computers these days, the tasks done by several servers are now easily done with a single one. With the suc- cess of the Internet and the email system, we are pushed to manage more and more email domains. Here is a way to manage several indepen- dent email domains on the same machine: a Linux premiere! 11.. PPrriinncciipplleess "Virtual email domains" is a way to manage independent lists of users on the same server. Each virtual domain has its own password, spool directory, and user aliases file. For each virtual email domain, _l_i_n_u_x_c_o_n_f will setup +o /etc/vmail/passwd.virtual_domain +o /etc/vmail/shadow.virtual_domain +o /etc/vmail/aliases.virtual_domain +o /var/spool/vmail/virtual_domain/ +o /vhome/virtual_domain/ where virtual_domain is one domain, such as foo.com. 22.. VViirrttuuaall ddoommaaiinn ddeeffiinniittiioonn ddiiaalloogg To create a new virtual email domain, you must complete a single dialog. There are other tasks to do that are related to the DNS and IP aliases. They are described in other sections of this help tool. We will describe here the main dialog. 22..11.. AA nnaammee You must enter a domain name. This is all that is required. 22..22.. BBaassiicc iinnffoorrmmaattiioonn You enter the most common options here. 22..22..11.. FFaallll bbaacckk ddeessttiinnaattiioonn Normally, when an email message is sent to an account on a virtual email domain, the following processing is done: +o Check for an alias of that name. If there is one, send the message to each member of the alias list. (Aliases may point to other aliases.) +o If no alias is found, then the user list of the virtual domain is checked. The email is appended to the folder of the corresponding user if a match is found. +o If no alias or username matches the intended recipient, the message is rejected and the sender will receive an error message. However, if the fallback field is defined, the email will be sent to the fallback address instead. This is also known as a "catch-all" address since it will catch any messages that don't have an alias or username match. The fallback address may be: EEmmppttyy This is the default case. The message is rejected and the sender will receive a 'bounced' message. aannootthheerr__uusseerr@@aannootthheerr__ddoommaaiinn The message is redirected to a specific user of another domain. @@aannootthheerr__ddoommaaiinn The message is redirected to the same target account in another domain. For example, email sent to unknown@this_domain will be forward to unknown@another_domain. aaccccoouunntt The message is sent to another account of the same domain. This account may be an alias. || ssoommee ccoommmmaannddss aanndd aarrgguummeennttss The message is sent to the command. Token replacement is performed on the command. See below. 22..22..22.. AAllllooccaattee UUIIDD ffrroomm Normally, user IDs for virtual email accounts start at 60,000 for all domains. You can control the start of the allocation range if you wish. This is mainly used for people wanting to play with disk quotas. Note that the vdeliver program can limit the size of the user inbox as well. 22..22..33.. LLiimmiitt uusseerr iinnbbooxx ttoo ((kk)) Enter the limit, in kilobytes, for the user's inbox. This is the default for the entire domain. You can override it user by user if needed. The default is no limit. 22..33.. FFeeaattuurreess 22..33..11.. MMaaxxiimmuumm nnuummbbeerr ooff uusseerrss You can limit the number of accounts in a domain. Co-administrators won't be allowed to create more than this number. By default, there is no limit. 22..33..22.. MMaattcchh uusseerr ffuullll nnaammee When enabled, the delivery agent will try to match the user's full name. It replaces the spaces in the full name by dots and tries to match against this. So, user joe, with full name "joe who" may receive email as joe@domain.com or joe.who@domain.com. 22..33..33.. FFiilltteerr pprrooggrraamm ++ aarrggss ((oopptt)) You can specify an optional program which will filter the messages when they are appended to the user inbox folder. The filtering may be used to check for some bad content (perhaps a virus?). The filtering program receives the message on its standard input and writes the modified message (or nothing) on its standard output. You can specify some arguments as well. Specify the full path of the filter. 22..33..44.. IInnccoommiinngg mmaaiill aarree rreejjeecctteedd You can turn off incoming mail for the whole domain. Mail will be rejected and an error message will be returned to the sender. 22..33..55.. UUsseerrss ccaann''tt rreettrriieevvee tthheeiirr mmeessssaaggeess This locks the POP-3 and IMAP services for this domain. 22..44.. AAddmmiinniissttrraattoorr You can grant administrator privilege to any normal user (Linux users) of the server. Often, we do not want to create Linux accounts on the server at all. This section allows you to define a password allowing a pseudo-user called admin@the-domain to administer user accounts and aliases in this virtual email domain. This only works in WEB mode ( You need a linux account to use the other user interfaces anyway). So for a virtual email domain foo.com, the pseudo-account is admin@foo.com. 22..44..11.. EEnnaabbllee ccoo--aaddmmiinniissttrraattiioonn You can turn on an off co-administration privilege. This only affects the pseudo-user. Other linuxconf privileges are not affected (The ones granted to linux users). 22..44..22.. CCoo--aaddmmiinniissttrraattoorr ppaasssswwoorrdd You enter the password twice. If you leave the fields empty, the current password is preserved. 22..55.. EExxttrraa aalliiaasseess ffiilleess Each virtual domain implicitly has an aliases file named /etc/vmail/aliases.domain where domain is the domain name. You can define two more, if needed. They will be used by the vdeliver program. The implicit one has the highest priority. vdeliver looks in the first and then in the second until a match is found. Note that, like the normal aliases (/etc/aliases) processed by sendmail, alias definitions may point to another alias and so on. Mailing lists may be defined, etc... Alias files are maintained by the same dialog as normal sendmail aliases, and as such, offer the same capabilities. 22..66.. AAlliiaasseess ffoorr tthhiiss ddoommaaiinn It is possible to provide several domain names pointing to the same user pool. You can add as many as needed. For example, one may define the virtual domain foo.net and later register foo.com. By using a domain alias, both domains will be equivalent. 33.. AA nnoottee bbeeffoorree ssttaarrttiinngg Virtual email domains are a supplement to the normal email capabilities of your mail server. Normal email domains are still managed properly and the email is stored in /var/spool/mail. So if your machine is currently accepting email for domain foo.com and you wish to receive, separately, email for foo1.com and foo2.com, you just have to define those two domains as virtual email domains. The configuration for foo.com is unaffected. 44.. HHooww ttoo sseettuupp vviirrttuuaall eemmaaiill ddoommaaiinnss Here is a step-by-step explanation. 44..11.. HHooww ttoo aaddaapptt PPOOPP cclliieennttss There is nothing special to do on the POP user side, which is a good thing(tm): We want to merge several email servers into one box, we don't want to tell everyone about it :-) 44..22.. HHooww ttoo iinnssttaallll tthhee sseerrvveerr The trick to reading the mail is exactly the same as with virtual WWW: you need IP addresses. Here is most of the setup. Suppose we want to create three virtual email domains: va.foo.com, vb.foo.com, vc.foo.com. Think about it in the same way as you would do for installing three independent servers, each serving one single email domain. This is what we will describe here and at the end, we will show how these three servers can be merged into a single machine. 44..22..11.. OOnn tthhee DDNNSS From a DNS standpoint, we have one email server per domain. So the MX of each domain is +o va.foo.com -> mailhost.va.foo.com +o vb.foo.com -> mailhost.vb.foo.com +o vc.foo.com -> mailhost.vc.foo.com With the DNS, this is what we are telling the world. This is also what we are telling to email users. Mostly va.foo.com users, get your mail at mailhost.va.foo.com, vb.foo.com users, get your mail at mailhost.vb.foo.com and so on. So far, with such a setup, we could very well have one server (the real one) per email domain (The current status quo before the virtual email domain is set up). 44..22..22.. IInnssttaalllliinngg tthhee sseerrvveerrss To continue the setup (be it real or virtual), we edit the DNS and allocate an IP number for each server (this is the key). Here I am using private IP numbers as an example. One will see that I have allocated IP numbers from the same network. +o mailhost.va.foo.com -> 172.16.0.1 +o mailhost.vb.foo.com -> 172.16.0.2 +o mailhost.vc.foo.com -> 172.16.0.3 Then we could install three Linux servers with these IPs and tell _s_e_n_d_m_a_i_l on each server to accept one of the three domains. 44..22..33.. GGeettttiinngg vviirrttuuaall Instead of installing three Linux servers, we install a single one. For each virtual email domain, we must +o Define it using _l_i_n_u_x_c_o_n_f, which involves only naming the domain. +o Define an IP alias (again with _l_i_n_u_x_c_o_n_f) so the machine will answer queries for this IP number, too. This is done in em/linuxconf/ in the menu "networking/IP aliases for virtual hosts" +o Install /usr/lib/linuxconf/lib/vpop3d as a replacement for /usr/sbin/in.pop3d in /etc/inetd.conf. vpop3d is a drop-in replacement for the standard pop3d even if you don't use virtual domains. The IP alias is the key. The POP protocol has no way to identify the target of a request, except with the IP destination number. This is why POP clients must use a different name (a different IP in fact) to read the messages from different email domains. From their point of view, this is expected anyway. If you must share an IP address for multiple email domains, the user would still set up their POP client to connect to mailhost.va.foo.com but their username login would no longer be "joe" but "joe@mailhost.va.foo.com". This workaround is a little confusing to some users, but will avoid requiring a separate IP address for every email domain. 44..22..33..11.. HHooww ttoo iinnssttaallll vvppoopp33dd Is vpop3d a replacement for the standard POP daemon you are using on your distribution? Maybe not. Various distributions ship with different pop3d's, supporting NIS, PAM and other authentication features. The best way to support all these easily is to let the native pop3d daemon handle the _m_a_i_n email domain; vpop3d only manages the virtual ones. To get this result, simply pass, as an argument to vpop3d, the path of the native pop3 daemon. Vpop3d will give itself control when a POP request is made to the main domain. Here is an example of how to set /etc/inetd.conf: pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/lib/linuxconf/lib/vpop3d /usr/sbin/ipop3d So, to install it, do not replace the pop3d command, but simply insert /usr/lib/linuxconf/lib/vpop3d. The exact line varies a little from distribution to distribution. 44..22..33..22.. HHooww ttoo iinnssttaallll vvppoopp33dd oonn xxiinneettdd ssyysstteemmss ((RReeddHHaatt 77)) After installing the package imap, edit the file /etc/xinetd.d/ipop3 and modify the line server and disable, and insert the line server_args. The file will look like this: service pop3 { socket_type = stream wait = no user = root server = /usr/lib/linuxconf/lib/vpop3d server_args = /usr/sbin/ipop3d log_on_success += USERID log_on_failure += USERID disable = no } 55.. HHooww ttoo ddeebbuugg aa ccoonnffiigguurraattiioonn Most errors occur when virtual domain settings are related to the DNS. Here are some tests you can do to verify that your setup correct. One piece of advice: using a POP client (email program) is not that helpful to test this kind of setup. Those program are not informative for such a task. They either work or they don't. 55..11.. CChheecckkiinngg tthhee DDNNSS For each virtual domain, you must perform some DNS work. We will use the va.foo.com domain as an example. Here are the steps: 55..11..11.. TThhee MMXX The command nslookup -q=mx va.foo.com should print something useful. At least the name of the email server should be obtained with its IP address. This is either mailhost.va.foo.com, or the official name of the server. The name obtained need not be in the va.foo.com domain. However, it must point to the proper physical server. 55..11..22.. TThhee vviirrttuuaall mmaaiill sseerrvveerr The mailhost.va.foo.com must be defined in the DNS. Here I am using mailhost. It could be pop.va.foo.com, or whatever. The following command nslookup mailhost.va.foo.com should produce an IP number. Furthermore, the following command nslookup the_IP_number_you_got should print mailhost.va.foo.com. If you do not get this, then the virtual POP server won't work. Really! End of the game! You need to have proper reverse lookup on this IP number. Linuxconf does it magically if the special reverse lookup domain is defined on the same DNS as the virtual domain. So, if both queries (with nslookup) are successful, you have done the hardest part. 55..11..33.. IIss tthheerree aa sseerrvveerr lliisstteenniinngg?? Then you do the following command telnet mailhost.va.foo.com This should connect to the physical server. This proves that the IP alias is properly installed. 55..11..44.. IIss tthheerree aa vviirrttuuaall PPOOPP sseerrvveerr lliisstteenniinngg?? Execute the following command to see if vpop3d is properly installed. If this command is producing the proper greeting, not much can go wrong. telnet mailhost.va.foo.com pop-3 You should get +OK Virtual va.foo.com POP3 Server (Version 1.004) ready. The "va.foo.com" is the key here. If you are not getting this, then the virtual domain is simply not defined, or vpop3d is not installed in /etc/inetd.conf or /etc/xinetd.d/ipop3. 55..11..55.. AA ttooooll ttoo ddoo aa qquuiicckk cchheecckk The script /usr/lib/linuxconf/lib/checkvdomain may be used to do a quick check of the vpop3d installation for a vir- tual domain. Run it without arguments to learn more. The script /usr/lib/linuxconf/lib/testalldomain reads the file /etc/named.boot and extracts all domains defined in it. It then runs the script check- vdomain (assuming that there is a virtual host mail for each vdomain) on each domain. It reports if the domain is properly configured or not. This is useful for admins managing tons of vdomains. 66.. OOnnccee ooppeerraattiioonnaall 66..11.. HHooww ttoo aadddd PPOOPP uusseerrss Once a virtual email domain is working, you still have to add POP users to it. There is a menu entry in the User accounts menu called Virtual POP accounts (mail only) . It allows you to pick a virtual domain and add new accounts or edit accounts. 66..22.. CCoo--aaddmmiinniissttrraattoorrss For each virtual email domain, a new privilege is added to linuxconf. You can grant this privilege to any normal user. He will be allowed to manage the user list (POP users only) of the virtual domain. This is fully operational using the HTML interface also. There is also a global privilege allowing one user to administer all virtual email domain. 66..33.. HHooww ccaann aa uusseerr cchhaannggee hhiiss ppaasssswwoorrdd One problem with POP only users (and also PPP users) is that they don't have access to any shell account from which they can easily change their password. Linuxconf provides a neat solution to this problem. This is only available with the HTML interface, and it fully supports virtual email domains. If you point your browser to the following URL: http://your_server:98/htmlmod:userpass: you will access a simple screen allowing anyone to change their own password. "your_server" may be any one of the virtual POP servers or the normal name of your server. Linuxconf will manage the proper password file based on the IP number used to reach it. It is a good idea to _h_i_d_e this URL in one of the information pages of your server (it is a little bit odd to type). 66..33..11.. HHooww ccaann aa uusseerr cchhaannggee hhiiss ppaasssswwoorrdd ffoorr IIPPlleessss ccoonnffiigguurraattiioonnss The above URL relies on proper reverse mapping to identify the target domain. The following URL works without any particular IP. The target domain is encoded in the URL. http://your_server:98/htmlmod:vpass-THE_DOMAIN 77.. SSoommee pprroobblleemmss 77..11.. AAllll oouuttggooiinngg eemmaaiillss ffrroomm vviirrttuuaall ddoommaaiinnss aarree mmaassqquueerraaddeedd This is caused by a bad DNS configuration. Generally, any mail leaving the server and originating from a virtual domain is rewritten so it looks like it came from the main domain of the server. This problem originates from a new sendmail behavior. At startup, sendmail scans all network interfaces (and IP aliases) and retrieves the name associated with their IP number. It assumes, from now on, that all those names are equivalent to the main domain of the server. Any email originating from one of those names will be masqueraded as coming from the main domain. The DNS problem is simply that you have set the reverse mapping for an IP number so it points to a domain name instead of a host of this domain. Linuxconf will not allow this mistake to occur, as it never does a reverse mapping pointing to a domain name. Doing a DNS by hand does not prevent that though. So make sure that all IP numbers associated with IP aliases point to a host of a domain, not to a domain itself. Restart your DNS and your sendmail and all will be fine. 77..22.. II ddoo nnoott ccoonnttrrooll tthhee DDNNSS zzoonnee ffoorr rreevveerrssee mmaappppiinngg Another solution is to enter the proper definition in /etc/hosts. vpop3d looks there first anyway. So if you have mail.some-domain.com pointing to the IP x.y.z.w, just enter this line in the /etc/hosts file of the server running vpop3d: x.y.z.w mail.some-domain.com 77..33.. IIss tthheerree aann IIMMAAPP sseerrvveerr ssuuppppoorrttiinngg vviirrttuuaall eemmaaiill ddoommaaiinnss Yes. Check out http://vimap.sourceforge.net. It is a POP-3 and IMAP server derived from the imap package found on RedHat. 88.. FFeeaattuurreess 88..11.. AAuuttoo--rreessppoonnddeerr It is possible to create auto responders for virtual domains accounts. You do not need to create any accounts (but you are allowed to). The auto-responder mechanism works in parallel with normal account delivery. Whenever a message is sent to an auto-responder address, a file is returned to the sender. For a vdomain foo.com, if you create a file /var/spool/vmail/files/foo.com/somename.auto, it will be sent whenever a messages is directed to somename@foo.com. The file must contain a complete email messages including the header. Ideally, the header must contain a Subject: and Reply-To: entry. If the account somename exists, the messages will be also delivered. If somename is an alias, it will be resolved and the auto-responder mechanism will be executed. Using this, multiple email address may point to the same auto-reponder file. Bulk messages are ignored. 88..22.. VVaaccaattiioonn It is possible to setup a per-user vacation mechanism. The vacation mechanism relies on one text file and an index. The index records the address having already received the vacation text, avoiding to send over and over the same message to the same people. The vacation text is a complete email message, including the header. It must contains a Subject: tag. The index file acts also as a control. If the file does not exist the vacation service is off. So to turn it on, you have to create it empty. The vacation mechanism will maintain it. The vacation files may be located either in the user home directory or in the directory /var/spool/vmail/files/the-domain. The later is generally used by the system administrator when the users do not have any access to the system beside the imap and pop-3 services. In /var/spool/vmail/files/the-domain directory, the files are called user.vacation and user.vacation.db (user is the user account ID). In the user home directory, they are called .vacation and .vacation.db. 88..22..11.. AAlllloowwiinngg uusseerrss ttoo cchhaannggee tthheeiirr vvaaccaattiioonn mmeessssaaggee A special web entry allows any vdomain email user to control the vacation mechanism. It can be seen in the "Special entries to Linuxconf" page. The URL is "http://your_server:98/htmlmod:vacation:" 99.. TTookkeenn rreeppllaacceemmeenntt iinn ffaallllbbaacckk A message may be piped through a command specified in the fallback destination. The command may be setup using special tokens. They are replaced before executing the command. Here they are: %%dd is replaced by the target domain name. %%ff is replaced by the sender's address. %%uu is replaced by the user name. 1100.. CCoonncclluussiioonn After setting the proper IP aliases, a POP user can't tell if there are three servers or a single one. This could become a key aspect. If the load on the server grows, you may want to distribute a few virtual email domains to another server. For everyone (the users, the DNS), this will be completely transparent.