| The following cover more complex setups of WebMail. The first section
explains the main setups that are possible. There are other methods
of setting up WebMail, and this only explains the main ones.
If you have any questions or need to know more about any aspect of WebMail, please Email:
If you are using SurgeMail, all the below has been taken care of for you. When you add a new domain to SurgeMail it will pass on the information to WebMail. Only if you set up WebMail outside SurgeMail do you need to consider the options below.
WebMail can be set up in many different ways. It all depends on how you want your users to login to WebMail. Here is a list of things that you need to consider:
If you have only 1 domain the base installation should be what you are after.
The following is presuming that you have multiple domains (2 or more) that you want your users to access via WebMail. The list that follows is not a complete list, but shows the most common options that are available. Throughout this section I am going to be using 2 domains, 'domain.com' and 'this.com'
The list below is not a complete list of setup options within WebMail. If none of the below suit your options please email support at firstname.lastname@example.org. Please provide the setup options or solution you require.
Multiple WebMail CGI's
Multiple URL's but 1 CGI
Single URL with 1 Mail Server
Single URL with User Stated Mail Server
Single URL with Mail server specified by Domain Suffix
Single URL with Mail server specified by Domain Suffix using Sub Domains
|Setup Large Sites|
When setting up WebMail for a large system including multiple computers, there are a few things that need to be checked.
When you are setting up WebMail on mutiple machines the workarea of each computer MUST point to the same location. This is to ensure that no matter what computer the user is going to, the CGI will still have access to the users' information.
The WebMail templates and images do not have to be set up on a network drive and we suggest that, since these are accessed often, to have these local to each machine. This will save network load.
There are also a few ini setting that you should also set up whch will help with large systems.
The first two settings are to reduce the amount of email 1 CGI cycle will download. If the user accesses a folder that hasn't been downloaded before and there are 1000 emails, the CGI will ONLY download the lastest 200 emails. Next time the folder is accessed the next 200 emails will be will downloaded and so forth. This helps ensure that the user gets a faster response back.
The next 2 ini settings are to do with WebMail locking, which is very important on large systems. More noticeable with nfs serves, but if two CGI processor were run at the same time without locking, both could be reading and changing the same file, which can cause data to become lost or damaged. The locking ensures that each user has only 1 CGI at a time processing data. The 'mylock_wait' is the time in seconds that the CGI will attempt to get the lock before giving up and displaying a 'Server Busy' error to the user. The 'mylock_timeout' is the time that any lock will expire automatically.
NOTE: The locking ini settings have no effect on Windows systems.
|NFS Server Setup|
When using WebMail on an NFS server, you should be using v3.1a or greater and will need to add the following to your ini file:
This will ensure that only one CGI at any time will have access to the user information..
You should also see server farming (running WebMail on more than 1 machine).Another webmail.ini setting that you might need to setup for nfs servers is:
On some nfs server setups the above setting is required to ensure that the creating and deleting files within 1 CGI call don't happen too fast for the nsf caching. If you have no nfs caching then this setting is not needed.
WARNING: This setting can affect performance, it is much better to disable nfs cache for webmail directories.