Virtual email domain Introduction 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 in the same machine: A linux premiere! 11.. PPrriinncciipplleess Virtual email domains is a way to manage independant lists of users on the same server. Each virtual domain has its own password file, its own spool directory and its own user aliases file. For each virtual email domain, _L_i_n_u_x_c_o_n_f will setup · /etc/vmail/passwd.virtual_domain · /etc/vmail/shadow.virtual_domain · /etc/vmail/aliases.virtual_domain · /var/spool/vmail/virtual_domain/ · /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 fill a single dialog. There are other tasks to do related to the DNS and IP alias and they are described in other section of this help. We will describe here the main dialog. 22..11.. AA nnaammee You must give a domain name. This is all that is required. 22..22.. FFaallllbbaacckk ddeessttiinnaattiioonn This is an optionnal field. Normally, when an email message is sent to an account of a virtual email domain, the following processing is done. · 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. · 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 no alias and no user do match, the message is rejected and the sender will receive an error message. If the fallback field is defined, the email will be sent to the fallback address instead. The fallback address may be EEmmppttyy The is the default case. The message is rejected. aannootthheerr__uusseerr@@aannootthheerr__ddoommaaiinn The message is sent to a specific user of another domain @@aannootthheerr__ddoommaaiinn The message is sent to the same target account, but 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. 22..33.. AAlliiaasseess ffiilleess Each virtual domain has implicitly an aliases file named /etc/vmail/aliases.domain where domain is the domain name. You can define up to two more. They will be used by the vdeliver program. The implicit one has the highest priority. vdeliver looks in the first one and then in the second one until a match is found. Note that, like normal aliases (/etc/aliases) processed by sendmail, alias definition may point to another alias and so on. Mailing list may be defined etc... Aliases files are maintained by the same dialog as normal sendmail aliases and as such, offers the same capabilities. 22..44.. AAlliiaasseess ffoorr tthhiiss ddoommaaiinn It is possible to provide several domain name pointing to the same user pool. You can add as much as needed. For example, one may define the virtual domain foo.ca and later register foo.com. By using domain alias, both domains will be equivalent. 33.. AA nnoottee bbeeffoorree ssttaarrttiinngg Virtual email domain are a supplement to the normal email capabilities of your mail server. Normal email domains are still managed properly and the emails 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 in one box, we don't want to tell everyone about it :-) 44..22.. HHooww ttoo iinnssttaallll tthhee sseerrvveerr The trick to read the mail is exactly the same as with virtual WWW: You need IP addresses. Mostly here is the setup. Suppose we want to create 3 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 3 independent servers, each serving one single email domain. This is what we will describe here and at the end, we will show how these 3 servers can be merged in 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 · va.foo.com -> mailhost.va.foo.com · vb.foo.com -> mailhost.vb.foo.com · 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 1 server (real one) per email domain (The current state of affair before virtual email domain). 44..22..22.. IInnssttaalllliinngg tthhee sseerrvveerrss To continue the setup (be it real or virtual), we go in 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. · mailhost.va.foo.com -> 172.16.0.1 · mailhost.vb.foo.com -> 172.16.0.2 · mailhost.vc.foo.com -> 172.16.0.3 Then we could go and install 3 linux servers with those IPs and tell _S_e_n_d_m_a_i_l on each one to accept one of the three domains. 44..22..33.. GGeettttiinngg vviirrttuuaall Instead of installing 3 linux servers, we install a single one. For each virtual email domain, we must · Define it using _L_i_n_u_x_c_o_n_f, which involves only naming the domain. · Define an IP alias (again with _L_i_n_u_x_c_o_n_f) so the machine will answer query for this IP number also. This is done in _L_i_n_u_x_c_o_n_f in the menu "networking/IP aliases for virtual hosts" · Install /usr/lib/linuxconf/lib/vpop3d as a replacement for /usr/sbin/in.pop3d in /etc/inetd.conf. vpop3d is a dropin 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. 44..22..33..11.. HHooww ttoo iinnssttaallll vvppoopp33dd Is vpop3d is a replacement for the standard POP daemon you are using on your distribution ? Maybe not. Various distribution ships with different pop3d supporting NIS, PAM and other authentication features. The best way to support all this easily is to let the native pop3d daemon handles the _m_a_i_n email domain: vpop3d only manage the virtual ones. To get this result, simply pass as an argument to vpop3d the path of the native pop3 daemon. vpop3d will give it 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 btw. 55.. HHooww ttoo ddeebbuugg aa ccoonnffiigguurraattiioonn Most errors done when setting virtual domains are related to the DNS. Here are some tests you can do to verify that your setup is done properly. One advise: Using a POP clients (email program) is not that helpful to test that kind of setup. Those program are not informative at all for such a task. They either work or they don't. 55..11.. CChheecckkiinngg tthhee DDNNSS For each virtual domain, you must have done 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 obtain with its IP address. This is either mailhost.va.foo.com, or the official name of the server. The name obtain need not be in the va.foo.com domain. It must point to the proper physical server though. 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. Further, 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 at all. 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 you have both queries (with nslookup) successful, you have 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 Do the following command to see if vpop3d is properly installed. If this command is producing the proper greating, 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. 55..11..55.. AA ttooooll ttoo ddoo aa qquuiicckk cchheecckk The script /usr/lib/linuxconf/lib/checkvdomain may be use to do a quick check of the vpop3d installation for a vir­ tual domain. Run it without argument to learn more. The script /usr/lib/linuxconf/lib/testalldomain reads the file /etc/named.boot and extract all domain defined in it. It then run the script checkvdo­ main (assuming that there is a virtual host mail for each vdomain) on each domain. It reports if the domain is properly configured or not. Useful for admin managing tons of vdomains. 66.. OOnnccee ooppeerraattiioonnnnaall 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 or edit new accounts to it. 66..22.. CCoo--aaddmmiinniissttrraattoorr For each virtual email domain, there is a new privilege 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 operationnal using the html interface also. 66..33.. HHooww ddooeess aa uusseerr mmaayy 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 changed their own password. Linuxconf provides a neat solution to this problem. This is only available with the html interface. And it fully support virtual email domain. 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 its own password. "your_server" may be anyone of the virtual POP server 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 page of your server (it is a little bit odd to type). 77.. SSoommee pprroobblleemmss 77..11.. AAllll oouuttggooiinngg eemmaaiill ffrroomm vviirrttuuaall ddoommaaiinn aarree mmaassqquueerraarreedd This is caused by a bad DNS configuration. Mostly any mail leaving the server and originating from a virtual domain is rewritten so it looks like it comes 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 name 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 point to a domain name instead of a host of this domain. Linuxconf will not let you do this mistake 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 to IP aliases point to a host of a domain, not a domain itself. Restart your DNS and your sendmail and all will be fine. 88.. CCoonncclluussiioonn After setting the proper IP aliases, a POP user can't tell if there are 3 servers or a single one. This could become a key aspect. If the load on the server grows, you may want to distribute few virtual email domains to another server. For everyone (the users, the DNS), this will be completely transparent.