1. If you are running multiple DPOP servers accessing shared drop files, you must contact DMail Support to find out what version of DMail to run.
2. Are there any special things that I should be setting in dmail.conf?
3. List of load sharing and redundancy options
4. How can I share the load across multiple servers?
5. I want to run multiple servers, how can I route the mail to them?
6. Can I share the load across NetAuth and CWMail as well?
7. What is your recommendation for scaling our system?
8. Can I share the majority of dmail.conf across multiple servers?
9. Do you suggest setting use_flock to false on linux??
10. Virtual Domains on a large system in DMail, CWMail and NetAuth overview

On other FAQ pages ...

• Miscellaneous FAQ: Does CWMail and DMail server support multi-threading?
• Miscellaneous FAQ: Authentication for DMail and NetAuth on Clustered machines and Network Drives

1. Are there any special things that I should be setting in dmail.conf?

   In general, you should not need to modify anything much in dmail.conf for a system of this size - a normal installation of DMail tries to perform to its best for all sized systems!

   The only exception to this is that you should definitely make sure that you have directory hashing turned on with the hash_spool setting. For more than 20,000 users we recommend hash_spool 2 so that there are 2 extra levels of directories.

   Here is a list of other things that we recommend you look at:

   • Logs: You should increase the size and number of your log files - aim to have at least the last 2 hours of activity available in the log files. The settings to use are: max_loglen, rotated_logs and max_log_size.
   • min_space (in mbytes): You should set this setting to something like 30 mbytes, so that you are notified well in advance of disk space problems. When this minimum amount of space is reached, DSMTP will alert the system administrator and then stop accepting connections after the disk space gets below about 90% of that value. So if the value is larger, there is a longer warning time between the alert and the offline state.
2. List of load sharing and redundancy options

   Here is a list of most ways in which you can share the load across multiple SMTP and/or POP servers. Some are beneficial in terms of backup servers for redundancy and some are not. See,
   How can I share the load across multiple servers?
   for more discussion of the options.

   1. One main server and secondary SMTP server(s): (recommended first approach)
      Secondary SMTP server(s) give redundancy by holding incoming/outgoing mail if main server goes off line. SMTP server(s) can share the same user database, or use mirrored user databases.
   2. One DPOP server and multiple SMTP server(s):
      All mail delivery shared mail collection always from just one machine. SMTP servers share drop_path and user database.
   3. Multiple DPOP servers with separate bin files and multiple SMTP servers:
      Users must always connect to the same DPOP server or always remove mail from POP server. Servers share drop_path and user database but not bin_path.
   4. Multiple DPOP servers and multiple SMTP servers:
      Full load sharing where users can access any machine. Servers share: drop_path, bin_path and user database.

   NB: with all options where the user database and/or the mail storage area is shared, access to these resources obviously becomes the weak point of the system.

   We don't currently have any way to mirror server where there is no physical connection between the two servers by way of a shared network drive.

3. How can I share the load across multiple servers?

We generally suggest that you start with a single mail server as a first step, as it is simple to set up and allows you to see how just one DMail server performs. It is not until you have run one of our servers that you will get a real feel for what your load sharing requirements are. This is a sensible approach as it lets you identify where the real load bottle necks are for your system, after which you can address them specifically, which may or may not include running multiple servers.

However, whether you want to do that to start with or not, read on ...

DMail does support running multiple servers, which share both the user database and the mail storage area. In the manual, we term this a 'server farm' arrangement.

You can run multiple SMTP servers and have just one POP server, or you can run multiple of both.

You simply add one extra setting into each server's configuration file in order to enable the sharing of the mail storage area,
lock_id xxx
where xxx is a unique ID for each server.

You then point the setting,
authent_process path_to_authent_module
at the same authentication process on each server, and the setting,
drop_path path_to_storage_area
to a shared mail storage area.

Don't forget to RESTART both DMSTP and DPOP on each machine after doing this.

On UNIX platforms, the shared storage area would normally be a shared NFS drive. Our lock_id code turns on our own file locking system which enables the file sharing on an NFS drive. You might also need a shared drive for the authentication module files, e.g. for our NWAuth module you do need to share the directory where you place the NWAuth executable.

NB: We have recently made improvements to our file locking code so you should contact DMail Support to find out which version you should run if you are setting up a 'server farm'.

On Windows platforms, you need to use UNC style names (e.g. \\serverA\shared_drive\dmail) to specify paths for the settings above between the server machines for the mail storage area. You may also need to use a UNC name for the authentication module, e.g. our NWAuth module requires this. You can map network drives instead of using UNC names but UNC names have the advantage that if the server reboots then the path specified with the UNC name will be accessible, whereas a mapped network drive is not accessible until someone logs on and the mapping is created. Whether you use UNC names or mapped network drives, you MUST enable sharing on the folders that the servers are to share AND ensure that the correct permission for that shared resource is given - see the note below.

NB: the DMail servers are spawned by the DWatch service on NT, which will be running as the user 'system', so that is the user that the servers and the authentication module will also be running as. You cannot give access permission to a mapped network drive for the 'system' account, so you must change the NT DWatch service so that it runs as a specific user (in Control Panel, Services, Startup) and then give read/write permission for that user on the shared directories.

4. I want to run multiple servers, how can I route the mail to them?

   The answer to this question is slightly different for POP and SMTP. Often you may just want to run multiple SMTP servers and just one POP server.

   In general, the easiest way to do this is by using the DNS server lookup to share out the load. You can also do it by using a router in front of your mail servers.

   Below are some suggestions based on feedback from our customers...

   (NB: We don't have much experience with routers, so if anyone is using such a setup then they might like to contribute some general information here??? )

   Rotating DNS MX Lookup:
   For the DSMTP servers you can set up a rotating DNS MX lookup. A rotating lookup works by responding with a different answer from a list of responses on each consecutive DNS lookup. For example,
   person one looks up domainx.com and gets back mail1.domainx.com
   person two looks up domainx.com and gets back mail2.domainx.com
   etc.

   In this way the load gets distributed

   One POP server for each group of domains:
   For the DPOP servers it can be easy to share load on the basis of domains. In order to do this, you ask users from one domain or a group of domains to connect to one of the POP servers, e.g. mail1.domainx.com and another group to connect to another POP server, e.g. mail2.domainx.com and so on.

   NB: if you are running web based mail then you can set CWMail or DMailWeb to connect to a specific POP server - so you can do the above without the users needing to know about the separate POP servers.

   If you use this method then you can actually get away with quite separate POP servers, provided that the group of users always connect to the same POP server (which is easy to ensure if users always access their mail via CWMail).

5. Can I share the load across NetAuth and CWMail as well?

   Yes, NetAuth just duplicates on multiple systems, needs shared access to external authentication module.

   CWMail needs to share workareas and template files.

   These will be updated with proper FAQs shortly ...:-) In the mean time, contact NetAuth Support or CWMail Support for details.

6. What is your recommendation for scaling our system?

   We recommend that you start your mail system at Step 1 below. You will then be able to scale it up as it grows through the other steps that are applicable to your situation.

   Step 1: Start with just one box running DMail + NetAuth + CWMail + WebServer, no matter what your size system.

   We also recommend that you setup 3 separate domains for each of the mail servers and for the web server, e.g.
   smtp.domain.com
   pop.domain.com
   www.domain.com
   for DSMTP, DPOP and CWMail (on the web server) respectively.

   Also, where you have virtual domains, get your users using the virtual domain equivalents,
   smtp.vdomain.com
   pop.vdomain.com
   www.vdomain.com

   To start with, all of the above domains can resolve to the same box.

   Once you have users using these domains in their email client settings and web page bookmarks then it is easy for you to redirect them to separate boxes at a later stage, simply by altering your DNS records.

   NB: if you are worried about mail delivery redundancy, you should ask someone else (e.g. an ISP) to act as a 'secondary SMTP server' for your system. This is easily done by simply pointing your secondary DNS MX entry at their smtp server. All they have to do is ensure that mail for your domain will be accepted (by their anti relay settings) and that their server will continue trying to send it for a reasonable amount of time until your server can come back online.

   Then, when needed, here are our recommended possible further steps...(in a rough order)

   ... greater than 100k users ...

   • Move the WEB server to another box (away from the POP and SMTP servers).
   • Move the DPOP server to another box (away from the SMTP server).
   • Add a second DSMTP server on another box. Load share with a rotating DNS MX entry.
     You will need to add a rotating DNS MX entry that moves between your first and second DSMTP servers on alternate lookups.

     You can also use the second SMTP server just for outgoing mail or for mailing lists only.

   • Add further CWMail (web) servers. Try to move virtual domains to separate web servers.
     Often you can easily split load across multiple CWMail servers by dividing based on domain, e.g. you may put just 2 or 3 domains on each server.
   • Add further DPOP servers. Try to move virtual domains to separate DPOP servers.

   ... greater than 500k users ...

   • Add a router, so that you can add further POP, SMTP and WebServers easily

     Once you have a router on the front of your email system you can easily load share between any of the servers by running them on separate boxes.

7. Can I share the majority of dmail.conf across multiple servers?

   Yes. There should not be any problem with having,
   machine a dmail.conf:

   lock_id 1
   #include /share/dmail.share

   machine b dmail.conf:

   lock_id 2
   #include /share/dmail.share

   where /share/dmail.share is the main common config file settings (with its own #includes) on a shared NFS drive. Provided the root of both machines can read the #included file.

   The dmail.conf file is only ever read by the DMail servers, so does not need locking of its own.

   NB: The following settings need to be in either /etc/dmail.conf or \winnt\system32\dmail.conf. i.e. the following programs parse /etc/dmail.conf themselves for the following,

   dwatch:
     manager_ip_address (if not there still accept from local)
     timezone (not really needed)
     dmserver_port (not needed)
     work_path
     log_path
     dlist_path
     dwatch_path

   tellsmtp:
     work_path
     smtp_port (can be set on command line)

   So you would need these set in dmail.conf on each machine.

8. Do you suggest setting use_flock to false on linux??

   No, not unless you get a specific problem. It is a new setting (version 2.8d) added for use if flock does not work (i.e. causes stop errors for DPOP, rather than simply failing to get a lock) on your type of NFS.

9. Are there any problems with clients that directly access the drop file??

   (We use a commercial fileserver from Network Appliance, does the linux flock (on the client end) cause any problems?

   Theoretically yes, there is a problem. A linux client who accesses the drop file directly could think that they have a flock on the drop file when they don't, and hence a mail message could arrive into the drop file when a user was reading their mail. The consequences could be that the mail message gets lost. However, the chances of this are very small, and even smaller if the number of customers using direct drop file accessing clients is small.

   The problem is that we can't think of any way to stop this - let us know if you have any ideas :-) However, our general feeling is that it is not really an issue.

10. Virtual Domains on a large system in DMail, CWMail and NetAuth overview

    > Thank you for your prompt reply. In your response, can you also give me some
    > indication of how NetWin handles multiple virtual domains? We are planning to give
    > our users the choice of up to 3 domain names.

    Netwin's products have good support for multiple virtual domains. If anything, it can be a little confusing because of all the options available.

    Firstly, note that if you just want to allow the user to use all of 3 addresses, e.g.
         tam@domain1.co.nz
         tam@domain2.co.nz
         tam@domain3.co.nz

    i.e. all of those addresses are valid and are the same user, then you should add domain2.co.nz and domain3.co.nz as 'domain aliases' of domain1.co.nz, rather than as full virtual domains.

    E.g. ,
         host_domain domain.co.nz
         host_domain domain2.co.nz
         host_domain domain3.co.nz
    in dmail.conf and in CWMail, no extra settings would be needed. You would only have to ensure that the different URLs reach the same CWMail cgi.

    Given that you do want separate virtual domains, i.e. where the same username is re-used on each of the vdomains, then these are also easily added.

    Virtual Domains in DMail:

    In dmail.conf you add your main domain with a host_domain setting,
         host_domain main_domain.co.nz
    (you probably have already done this)
    and then add the other domains as virtual domains with vdomain settings,
         vdomain a b vdomain1.co.nz c
    where a,b and c are specific values for that domain. Most importantly, the vdomain line sets a separate mail spool directory for each domain, so that the mail is kept completely separate.

    The DMail manual has details on the vdomain setting in section 8.

    Virtual Domains in CWMail and NetAuth:

    In CWMail and NetAuth, the settings which you currently have in their ini files are all for your 'main domain'.

    You can choose to run separate CGIs for each virtual domain, or you can add 'vhost-vend' sections to their ini files for the virtual domains.

    The vhost sections allow you to simplify maintenance for the vdomains. They are sections of the ini file which allow you to specify any 'over rides' of the main domain for the virtual domain.

    So long as you use the vhost sections to separate out the stored mail and folders for each domain, it is easy to split to separate CGIs on separate web servers at a later date if you want to.

    In order to keep the stored mail separate, you must specify a unique workarea setting for each vhost section.

    Also, you should use the domain name for the pophost setting rather than an ip address. The pophost setting is used to form the user's directory name, so in general it should not be changed once you have added users (although it can be done). Using the domain name means that you can change the DNS record for that domain later to point to a different box without upsetting CWMail.

    Also, if you use a subdomain for the pophost setting, e.g.,
         mail1.vdom1.co.nz
    rather than just,
         vdom1.co.nz
    , you can easily make separate domains use totally separate pop servers at a later date as an easy way of distributing load.

    E.g. here is a simplified cwmail.ini file showing a main domain and two virtual domains (all sharing the same set of templates) which will be easy to separate out at a later stage if needed:

    #******************
    pophost main_domain.co.nz
    domain main_domain.co.nz
    workarea /usr/local/cwmail/main_domain/
    templates /usr/local/cwmail/tpl/

    vhost www.vdom1.co.nz
    domain vdom1.co.nz
    pophost vdom1.co.nz
    workarea /usr/local/cwmail/vdom1/
    vhost www.vdom2.co.nz
    domain vdom2.co.nz
    pophost vdom2.co.nz
    workarea /usr/local/cwmail/vdom2/
    vend
    #******************

    NetAuth's vhost sections are just like CWMail's. Here are the links to both of the manuals, which have full details, http://www.netwinsite.com/dmailweb/cwmail.htm http://www.netwinsite.com/netauth/netauth.htm