User Administration

To add users to your email system . . .

The DMail servers can use one of a number of systems for user authentication. Unfortunately this choice can make selecting an authentication system more confusing than it needs to be.

NOTE: by default the DMail servers use your system user database. So if you have just installed DMail try sending a message to a local user on your machine.

The choices for authentication:

You choose the authentication method with the configuration file,dmail.conf, setting, authent_method which can be one of:

  1. authent_method nt_user
    which means use the windows NT user database, this is the default on Windows NT machines.

    To add users you should run the User Manager (under Administrative Tools) and add users as if you were adding system accounts. Given that DSMTP and DPOP can autheticate a user, they will create a drop file for that user as necessary.

  2. authent_method unix_user
    which means use the /etc/passwd file and standard system calls (e.g. getpwnam())and is the default on UNIX based platforms.

    Add users as you normally would to the system, as system users automatically have email accounts on with this option. The DMail servers will create drop files etc. as necessary.

  3. authent_method external
    which means that the servers should spawn a specified external authentication program which can in turn be talking to any kind of database. External authentication programs are the link between the dmail servers and any type of user database you wish to use.

The next section covers external authentication extensively, but please note the following things which apply to any authentication method. (You should probably skip these for now but come back to them once you have read the more general material.)

  1. After changing any authentication setting you MUST stop and re-start the DSMTP and DPOP servers
  2. For your main (first)domain you can probably add simple usernames. Once you add any virtual domains you will need to decide how to re-use usernames on the virtual domains. See
    Username Re-Use and Adding users to your authentication module in the sections below.
  3. If you want users to be able to add themselves automatically, then see
    Setting Up a Web Based Email system with Auto Account Creation
  4. Notes on Case Sensitivity for all Platforms:
  5. Notes on UNIX Authentication
  6. Notes on NT Authentication



External Authentication of Users

DPOP and DSMTP allow the use of an external application for authenticating client connections. The servers run (spawn) multiple copies of the authentication application.

In this section:

  1. Choosing an external authentication module to run
  2. Telling DMail to use your chosen external authentication module
  3. Adding users to an external authentication module
  4. Creating your own external authentication module
  5. The External Authentication Protocol

  1. External Authentication Modules List

    You will have already downloaded some external authentication modules with DMail. If you wish you can write your own external authentication program (we suggest you modify nwauth).

    The following is a list of external authentication programs available from us. The links take you to detailed information.

    Ext. Auth. Program
    (click for details)
    Download FromComments
    NWAuthIn every DMail distribution setThis is our recommendation. Source provided. Please feel free to use it as a base if you are writing your own module.
    UNIXAuthIn 2.7 DMail distribution setThis is our module to talk to the UNIX system password file.
    NTAuthIn 2.7 DMail distribution setThis is our module to talk to the NT system user database.
    LDAPAuthUtilities Download Pageauthenticate with LDAP server
    DNAuthUtilities Download PageA version of nwauth which can check and lookup users from a DNEWS users.dat file.
    MySQLAuthIn 2.8e and above DMail distribution setOur own authentication module for talking to a MySQL server.
    ODBCAuth
    (READONLY, NT ONLY)
    Utilities Download Page Our own authentication module for talking to an ODBC Driver for a Database (e.g. MS Access, MS SQL Server, ORACLE)
    TCPAuth
    Utilities Download Page TCPAuth is a TCPIP client+server module that will take any other module as its backend. Allows easy authentication across boxes and across platforms.

    The following is a list of external authentication programs offered by our customers.

    Ext. Auth. ProgramLocatedComments
    MYSQLauthReplaced by our module above. For details email support-dmail@netwinsite.com Source of an authentication module which talks to a MySQL server.
    NiagaAuthUtilities Download Page Perl Script authentication module which talks to a MySQL server and others via DBI (both UNIX and NT).
    ODBC AuthenticatorUtilities Download Page Free module that talks to ODBC on NT. (source available for small fee)

     

  2. Telling DMail to use your chosen external authentication module

    Set the following TWO compulsary settings in the configuration file, dmail.conf,

    authent_method external
    authent_process executable_file

    (where 'executable_file' is the full path and filename of the executable to be run)
    AND then you must STOP and RE-START both DSMTP and DPOP.

    For example, for NWAuth which you will find in the DMAil distribution set,

    authent_method external

    and then

    authent_process \dmail\nwauth.exe
    or
    authent_process /usr/local/dmail/nwauth

    for Windows and UNIX platforms respectively (assuming default installation directories).

    Two recommendations:

    1. If you don't have any limitations on the your authentication database then we recommend that you use NWAuth.
    2. We also recommend the following setting,

      authent_domain true

      which forces user@domain to be passed to the external authentication process. This is a good way to distinguish between the same username in different domains in the user database.

    Here is the full list of authent settings you might want to set: (the links go to the reference section settings lists)
    authent_cache Number of authentication requests to cache.
    authent_domain true for 'user@domain' instead of 'user' to be passed to the authentication process. This is the suggested way to distinguish between the same username on different domains.
    authent_timeout Timeout (in seconds) for external authentication requests.
    authent_method sets the method used for user/password lookups
    authent_number number of concurrent authentication processes to run.
    authent_process Specifies the executable to use for external authentication process

     

  3. Adding users to your external authentication module

    The way to add users to your external database is hopefully known to you. However, all external authentication modules should adhere to the protocol so you should either be able to run the authentication program from the command line or use DMAdmin (windows GUI) or NetAuth(web admin) to add users as well.

    If you are using nwauth for example, then to add a user, username=bob and password=secret, run nwauth at a command prompt and enter,
    NT:

    cd c:\dmail
    nwauth
    set bob secret
    quit

    UNIX:
    cd /usr/local/dmail
    ./nwauth
    set bob secret
    quit

    The 'set' command above is the same for any authentication module.

    NB: the form of the username you add to the database will be one of the following,(using the username bob on a domain, domain1.com),

    1. set bob secret
    2. set bob@domain1.com secret
    3. set dom1_bob secret

    If you add the username to the database in the wrong form then users will not be able to login to the POP server.

    If you are working on your first 'main domain' then option 1 is probably correct. Option 1 is used for adding users to your main domain, except when authent_domain is set to true (more below).

    If you are adding a user to a virtual domain, then option 3 is probably correct. Option 3 is only used when adding users to a virtual domain, except when authent_domain is set to true (more below).

    Option 2, If you have set
    authent_domain true
    in the dmail.conf file then you MUST use option 2 on ALL domains.

    Having authent_domain true set, is our recommended option if you are doing a fresh install and you don't have existing users in your users database. NB: if you change this setting now then you should restart both dsmtp and dpop.

    (Use the tellsmtp command to check this setting,

    tellsmtp config authent_domain
    should respond that the setting has just one value 'true' if you have this setting set, otherwise it is not set.)

    If you are adding virtual domains, then you should see the Domains section of the manual for information on which form to use when adding users to the database.
     

  4. Creating your own external authentication module

    External authentication can be used for adding special connection restrictions. For example allowing email from laboratory computers only outside working hours. A sample authentication program is supplied with the distribution set, the C code for it is shown on this page, nwauth.c.   On NT use Visual C to build an authent process as pipes don't appear to work with some versions of Borland C.

    You must also provide a path to the executable you want to use. Let us assume you wish to use an application called myauth.exe for authentication. The application myauth.exe must read commands from standard in and write replies to standard out. The commands and replies defined allow the same system to be used by both DPOP and DSMTP. Note some parts of the reply are not needed for DPOP.

    Your authentication application must use Netwin's Simple Authentication Protocol, follow the link in the next section for details, page.
     

  5. The Defintion of the External Authentication Protocol

    Follow this link for a full definition and desctiption:
    External Authentication Protocol



Repeating Usernames on Virtual Domains (username re-use)

If you have set up dmail for multiple domains then the servers need some way to differentiate between user bob on one domain and user bob on another domain.

There are two stages where they need to do this,
1. when looking up the user in the user database
2. when the user logs on to the POP server

NB: it is important to remember that what the user logs in with and what the POP server looks up in the user database can be different - and mostly they are!

There are three ways in DMail to assure unique usernames in the database, i.e. requirement 1 above. Note: these systems may seem complicated, but they have been worked out so that life is simple for the end user.

  1. Don't allow usernames to be repeated on other domains:
    If you are happy with this then you probably don't need any virtual domains. You can specify all your domains as synonyms of the main domain with host_domain settings.
  2. Add the users to your database in the form user@domain: (recommended)
    To do this you set in the configuration file, dmail.conf,

    authent_domain true

    (remember to restart DSMTP and DPOP after changing an authentication setting)

    When a server needs to authenticate a user 'bob' it checks the external authentication for the user, bob@domain.

  3. Add a prefix to the the usernames of virtual domain users:
    Leave your existing 'main domain' users and add all virtual domain users with a prefix on their username, e.g. dom1_bob .

    This system is particularly useful if you already have a database full of usernames on your main domain, but wish to add a virtual domain and hence a new group of users.

    For Example:
    You already have a user, bob. And you want to add another domain, domain2.com. So you add a vdomain line to dmail.conf,

    vdomain dom2 1.2.3.4 domain2.com /mail/domain2

    the second entry sets the vdomain_prefix to 'dom2'. So in the user database you can add a user bob to this second domain by adding the username, dom2_bob. (the setting vdomain_separator can be used to set '_' to something else).
     

To fulfil requirement 2, i.e. a unique pop login username DMail offers the following 2 solutions.

  1. IP Address based virtual domains:
    This is described in detail in the Domains section of the manual. Basically for each domain after your main (first) one, you assign the domain a unique IP address, e.g. 1.2.3.4 .

    Then when the user logs in with the username 'bob' DPOP matches up the ip address they connect to with the domain, and alters the username given before logging it in to the user database. So,
    user logs in with: bob
    and dpop set to use option 2 above (authent_domain true), would lookup in database: bob@domain2.com

  2. Suffix based virtual domains:
    This is described in detail in the Domains section of the manual. Basically for each domain after your main (first) one, you assign the domain a unique POP login suffix. Users on this domain can connect to any ip address (on which DPOP is listening), but they must add the suffix to the end of their username.

    So if user bob logs in with,
    username of: bob@domain2.com (where '@domain2.com' is the suffix in this case)
    then if dpop is set to use option 3 above (authent_domain false), dpop would lookup in database: domain2_bob



Controlling client access to DPOP 

DPOP provides a variety of methods for limiting access from clients trying to read mail. 

First the client must use a valid username. This is limited by a wildcard list of valid names in the configuration file. 

There must be a drop file for that user. 

The username/password combination must be valid. This can mean a valid Unix or NT user/passwd. A variety of other methods for checking this combination are provided for and controlled by settings in the configuration file. An external authentication routine can also be used: See Adding Users ....

The from address ip_name or number can be limited using wildcard lists in the configuration file

 

By using an external authentication process other controls may be imposed such as limiting access from certain classes of users or users of certain machines to specific times of day. For example student users on laboratory machines may not be allowed to read mail during work hours. An example external authentication program is provided with DPOP. See the next section for details.



Controlling DSMTP access

Users do not log in to an SMTP server, but in general all mail delivered by an SMTP server has both a source address and a destination address (username and domain). This allows you to restrict mailing based on username and domain. You can restrict who can send mail out of your smtp server (non-local delivery and relay):

  1. Forward User System:
    The settings,
    forward_user and forward_window set up a system that allows local users to relay but stops your site being an open relay.
  2. ...
You can restrict who can send mail in to your smtp server (local delivery):
  1. ban_ip
  2. ...



Notes on UNIX Authentication:



Notes on Password Files (UNIX based systems only)

Password files can be specified for individual domains with the dmail.conf setting,

vdomain_passwd <domain> <filename>

The file specified (with full path) has exactly the same format as the /etc/passwd file.

The DMail servers do their own walk through these password files and will use any home directory setting etc. found within.



Notes on Case Sensitivity

On setting up a system you should be careful to get your case requirements and the settings to carry them out correct from the start, because it can be time consuming to fix problems once your system is up and running.

The settings that affect case sensitivity in DMail are,

lowercase_username
lowercase_password
unix_user

The following only applies to versions 2.4e and above.

The default settings are:
lowercase_username false
(the installation wizard sets this to,
lowercase_username true
in fresh installations in version 2.7 and above)
lowercase_password false
unix_user false (Unix based platforms only)
which means that the following situtations exist:

On Windows Platforms:

The username on an incoming message will be looked up by DSMTP in the case sensitive form. DPOP will also do this by default.

On Windows NT the username lookup is not normally case sensitive, so mail will be accepted by DSMTP for users bob, BOB, BoB etc. so long as there is a user called bob of some sort in the user database. Similarly DPOP will allow users to use any case for their username entered in their email client when they connect to read mail.

Both servers will write or read from the drop file with the case as it is presented to them. On NT this does not cause any problems as the file
\dmail\in\BOB
is the same file as
\dmail\in\bob

NB: The above means that on windows platforms you cannot have separate users, BOB and bob, i.e. differentiate usernames based on case differences in the username.

If you are using your own external authentication module do be aware of the case sensitivity of the lookup. DSMTP cannot currently be made to do a non case sensitive lookup. e.g. if mail arrives at DSMTP for BOB@domainx.com, then DSMTP will send
lookup BOB
to the external authentication module.

Our authentication module, NWAuth.exe always does a case insensitive lookup, so on windows platforms all problems are avoided.

If you want users to be able to enter their password in any case then set the lowercase_password setting to true and make sure that you have created the user with a lowercased version of their password.

On Unix based platforms:

DPOP by default will do a case sensitive lookup of the username. It will also look for a case sensitive drop file. E.g. if the user kathy has in her email client KATHY as her username, then DPOP will lookup the user KATHY and if it gets a match then it will look at the drop file,
/var/mail/KATHY

DSMTP is a little trickier :-)

By default on Unix DSMTP will first do a case sensitive lookup on the username given in the incoming message. If that fails, then it will do its own case insensitive lookup of the password file - this involves DSMTP doing its own password walk through the /etc/passwd file, rather than using the standard Unix calls. If there is a specific password file set, with the setting, vdomain_password, for the domain of the incoming message, then DSMTP will 'walk' that password file instead of /etc/passwd in the same manner.

In versions prior to 2.4j there was a bug in the default behaviour. DSMTP, when it did the case insensitive passwd file walk and found a unique match, would still use the version of the username that it started with for the drop file name, instead of using the drop file name as it found it in the password file. This resulted in drop files of the incorrect case, which DPOP then did not find. Setting lowercase_username to true also fixed this problem, see below.

If lowercase_username is set to true then DPOP will always do a lowercase lookup and will look for a lowercase drop file.

To make DSMTP only do case sensitive lookups you must set the unix_case to true. NB: this means that all incoming mail addresses to incorrect case versions of the username in the password file will be bounced!

Setting lowercase_username to true, will make DSMTP create ALL drop files in lowercase (as it will for DPOP also). NB: It will not change how DSMTP does its username lookups.

So on Unix we recommend:

  • If you are using NWAuth or another External Authentication Module that does lowercase lookups:
    Set lowercase username to true, so that the drop files are always in lowercase form. NB: you cannot differentiate two usernames on case, e.g. BOB and bob are the same user.
  • If you do want BOB and bob to be separate users:
    Set unix_case to true, and lowercase_username to false.
  • If you are not sure what you want:
    Set lowercase_username true (unix_case false).


Notes on Case Sensitivity for all Platforms:



Notes on NT Authentication:

If you have authent_method set to nt_user or you are running the new beta authentication module, ntauth then you are using windows NT's system user database. This is the one that you would normally modify with the User Mananger tool, under 'Programs/Administrative Tools (common)' on your start menu.

Notes:

  1. DPOP and DSMTP need to be running with the privilege 'may act as part of the system' in order to be able to check or lookup users. Note dwatch normally runs as a service on NT as the 'system account' user and spawns DSMTP and DPOP, so they to run as that account.
  2. When a user logs on to DPOP it has to logon the user to check their username+password combination. To do this the user has to have one of the privileges, 'log on locally' or 'Access this computer from the network'. This means that all mail users can log on to the mail server machine. If this is a problem you should use another authentication method, e.g. NWAuth




 

 
Products Downloads Prices Support Company