Frequently Asked Questions:
- Setting up a Web Based Email with Auto Account Creation system

No. 1 question:
How do I set up a 'HotMail' type system?


  1. How do I setup WaddUser? (Technical Details)
  2. What is the Maximum number of users the system can handle?
  3. How do I add extra fields to wadduser?
  4. How can I have some users who can connect direct to DPOP but others who can only connect with DMailWeb/CWMail?

Relevant questions in the Miscellaneous FAQ (may have different titles):


    How do I setup WAdduser? (Technical details on WAdduser)

    For general information on 'HotMail' type systems see, Setting Up a Web Based Email System
    technical details for WAddUser are below.

    Yes, using wadduser instead of NetAuth you need:

    • CWMail (web to mail interface)
    • DMail (dsmtp,dpop)
    • NWAuth (external authentication module for dmail)
    • wadduser (example web cgi for adding users using nwauth)

    Note: You no longer have to use NWAuth with our new product NetAuth (but it is still a good option).

    DMail comes with source and binary examples of NWAuth and wadduser, you should examine the source and modify wadduser.htm so that it only allows the users to automatically create their own accounts (it has extra functions which you would not want them to be able to do)

    Technical details:

    1. Fetch the source for nwauth/wadduser. This should come with DMail but if you have an earlier version you can download it from
    2. Make any changes to the source that you want (not required)
      See How do I add extra fields to wadduser? for some more information on this.
    3. Building wadduser.cgi and nwauth  (only needed on UNIX)

      gcc wadduser.c nwauth.c -DNOAUTHMAIN -o wadduser.cgi
      rm nwauth.o (so you can build it without NOAUTHMAIN defined)
      gcc nwauth.c -o NWAuth
      Note: if you get crypt errors you may need to add, -lc -lcrypt to the end of each gcc line.

      Create two console (command line) projects,
      1 builds nwauth.exe from nwauth.c,
      2 builds wadduser.cgi from both wadduser.c and nwauth.c but you need to define NOAUTHMAIN as a preprocessor definition.
      NB:In both projects you will probably need to add wsock32.lib to the list of standard linked libraries.

    4. Install the cgi script and the html form

      copy wadduser.cgi \inetpub\scripts    (or wherever your web server cgi directory is)
      copy wadduser.htm \inetpub\wwwroot

      Unix platforms:
      cp wadduser.cgi /home/httpd/cgi-bin    (or wherever your web server cgi bin directory is)
      cp wadduser.htm /home/httpd/htdocs

    5. Test the cgi, use netscape and reference your web site:
      Fill out the form and press one of the buttons. If it fails, you will probably need to modify the 'action' in wadduser.htm

    6. Tell DMail to use NWAuth for user authentication, add or change in dmail.conf (/etc/dmail.conf or \winnt\system32\dmail.conf)

      authent_method external
      (unix)   authent_process /usr/local/dmail/nwauth
      (NT)   authent_process c:/dmail/nwauth.exe
      authent_number 1

    7. Modify wadduser.htm so it only allows the actions that you want users to be able to perform, (e.g. not delete or search)

    8. On UNIX you will need to set some file protections:

      touch ..../cgi-bin/adduser.log
      chown nobody .../cgi-bin/adduser.log
      touch /usr/local/dmail/nwauth.txt
      chown nobody /usr/local/dmail/nwauth.txt

    9. If you wish add a bulletin message to DPOP that welcomes all new users.

    10. You can add a file, added.htm, in your cgi directory and wadduser will display the contents of the file when a user has been successfully added - underneath the 'Adding User' title.

  1. What is the Maximum number of users the system can handle?

    This depends on your system hardware and the setup of our products.

    Each of the products involved in our solution for a Web Based Email system can be registered on an Unlimited User License. Therefore, our software need not limit the number of users your system can have.

    As for performance, we currently have customers operating successfully with tens of thousands of users (POP mail accounts), and the bigger ones are fast approaching 100,000 users. We know that our products perform well with these sort of numbers.

    As far as larger systems go, we can only say that we are commited to producing efficient software and as part of this we are eager to work with any customer to help them run our products on larger systems.

    It must be said that our products have been designed to be scaleable and we would anticipate that on systems over 50,000 users you would seriously be looking at running our products on multiple servers.

    We are endeavouring to do more testing on larger test setups, and we will add any results to those already on our DMail performance page,

  2. How do I add extra fields to wadduser?

    To add extra fields in wadduser.htm for storing more information about the user, you will need to do the following:

    • Add the input text boxes and their appropriate variables in HTML to wadduser.htm (or the pages that you want them on)
    • Modify the source of the CGI wadduser (wadduser.c) so that it records the information given
    • Recompile wadduser.c (which requires linking to nwauth.c)
    • Replace wadduser.exe in your cgi or scripts directory with your new version

    The page that calls the wadduser CGI (wadduser.htm) has a form on it that calls the CGI as its action to perform when it is submitted, i.e when one of the buttons is pressed. E.g. action="" calls the wadduser cgi from the scripts directory on the web server. The CGI works out which of the buttons on the page was pressed and carries out the appropriate action.

    The function below web_add (from wadduser.c) is called when you click on the "add" button on the example wadduser.htm page.

    The form also has a number of variables that are passed to the CGI as part of the action of submitting the form, e.g. name, username, password. To add more fields, you will need to add more such input fields to the web page, in this form,
    <input type="text" name="username" size="20">

    So to add a field to get the person's hobby, you could add to wadduser.htm
    <input type="text" name="hobby" size="20">

    Then you need to decide what you want the CGI to do with the information in the fields that you add.

    The three lines in the function below,


    search the form that is submitted by the wadduser.htm page for the fields, phone, fax and comments, and if it finds them then it prints them into the log file, adduser.log. If it cannot find them, for example, if there is no such input field on the web page (this is the case with the example wadduser.htm - there are no input boxes for phone, fax and comments) or the user has not entered anything in the box, then it will simply enter an empty string.

    So to make wadduser log the person's hobby entry, you could add this line below the three above,

    The function below ONLY writes the username, password and name entries to the nwauth.txt password file, but it writes to the log file, adduser.log, a whole bunch of input fields that don't exist. Note that NWAuth only takes three fields, 'username', 'password' and 'other'. It is the 'other' field into which you can add your own fields. The function below adds the field 'name' into the 'other' field in the following format,
    name="the person's full name"
    The 'other' field can take as many fields as you want (until the information reaches the BFSZ definition, when you will get buffer over flows!) simply make sure that each field has the correct format and that they are separated by a space.

    So, to make the CGI write the hobby field onto the end of the 'other' field in nwauth.txt you should change the line in the function below from,
      sprintf(bf,"name=\"%s\" hobby=\"%s\"",name,form_find(hobby));

    This will result in nwauth.txt lines like,
    bob:a234h6:name="Bob Smith" hobby="ping pong"
    for the username bob, which has a password of something we cannot read as it is encrypted, and a full name of 'Bob Smith' and a hobby of 'ping pong'.

    int web_add(void)
    FILE *f;
    char username[BFSZ],password[BFSZ],name[BFSZ];
    char bf[BFSZ];
    /* Check the user has filled in the required fields */
    if (!check_value("Name","name","")) return 0;
    if (!check_value("Username","username","")) return 0;
    if (!check_value("Password","password","")) return 0;

    f = fopen("adduser.log","a");
    if (f==NULL) { printf("Could not write file\n"); return 0;}
    /* These are optional form elements to record */


    strlwr(username); /* Only allow lower case usernames */
    do_header("Adding user");
    if (auth_exists(username)) {
      printf("Sorry, a user by that name already exists\n");
    } else {
    return 0;

  3. How can I have some users who can connect direct to DPOP but others who can only connect with DMailWeb/CWMail?

    Q:I want to have two different types of users. I want one group to have both pop and web access to their mail, and I want the other group to have web access only. How would I set this up? Would I need to run two seperate servers? I plan to authenticate using an external authentication module (talking to a MS SQL 6.5 database).

    A:Yes, you can run two separate servers, or you can make an external authentication module flag some users as being only allowed web access.

    The trick is that DPOP only has the ip_address that the user connected from to know whether the user has connected from CWMail or with another email client direct to the POP server. DPOP passes this ipaddress to the external authentication module.

    1. If you run two separate servers then you can use the user_ip_address setting on one of the servers to only allow connections to that server from the ip address of the CWMail machine. Each server then either needs its own authentication database or you need an external authentication routine for each server which cannot 'see' the other server's group of users in the database.

    2. The nicer way is to make your user database have a flag for each user to say whether they are allowed to connect directly to the POP server or not, and then make your external authentication routine check this flag, and reject the connection if they have not connected from the appropriate IP address. The IP address that the user connects from is given in the authentication request by DPOP, e.g.
    check username password ipaddress

    So your authentication routine needs to check the "direct dpop connection allowed" flag and, if it is false, it should check the ipaddress passed against your CWMail server(s)'s ip address and only allow the connection if it does not match. This is an example - you do not necessarily have to do it this way. The fact that the connection from IP address is passed to the external authentication module is the important point.

    If I have not pointed it out before we also have the source code to another customer's SQL authentication module which I can give to you if it would help.

    For more information contact