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. Therefore, 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 that you use the windows NT user database. This is the default on Windows NT machines.

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

2. authent_method unix_user
   which means that you use the /etc/passwd file and standard system calls (e.g. getpwnam()). This 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 that 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
   

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)
   In order 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).
    

In order 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.

   Therefore, if user bob logs in with,
   username of: bob@domain2.com (where '@domain2.com' is the suffix in this case)
   then, presuming that 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. 

Firstly, 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

 

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 from being an open relay.
2. ...

1. ban_ip
2. ...

Notes on UNIX Authentication:

• By Default, (unix_case false), DSMTP will first do a case sensitive lookup on the username of an incoming message. If that fails, DSMTP will do it's own case insensitive 'walk' of the password file, and consider the lookup successful if it finds one, unambiguous match. See Case Sensitivity
• Version 2.5c of DSMTP does the standard getpwnam() call if DSMTP's case insensitive passwd file walk fails. Then, if that fails, and unix_case is set to false, DSMTP lowercases the username and does the getpwnam() call on the lowercased form (note that this is not full case insensitivity!!).
• The getpwnam() system call will only work with the Yellow Pages system call and the shadow passwords if you use the linux libc6 build version.

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. This is 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 will do a case sensitive lookup of the username by default. 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 :-)

On Unix DSMTP will, by default, first do a case sensitive lookup on the username given in the incoming message. If that fails, it will do it's 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 password file walk and found a unique match, it 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 could then 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.

In order to make DSMTP do only 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 the way that DSMTP does it's username lookups.

So, on Unix we recommend that:

• If you are using NWAuth or another External Authentication Module that does lowercase lookups you should:
  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:

• Virtual domain prefixes (the second item in a vdomain line) will be in the case given in dmail.conf, unless lowercase_username is set to true, in which case the whole drop file name is made lowercase.
• Setting lowercase_username to true will make DSMTP both create/read ALL drop files in lowercase.
• Setting lowercase_username to true does NOT affect the way that DSMTP does it's user lookup of local users.
• Directory hashing (hash_spool 1 and 2) is always done on the lowercase form of the main part of the drop file name (e.g. the drop_prefix is skipped). E.g. hash_spool 2 for the drop file, dom1_BOB would be to, path\b\o\dom1_BOB
• NWAuth, the authentication module that comes with DMail, stores names in nwauth.txt file in a case sensitive form, but always does a case insensitive lookup. Therefore, we reccommend setting lowercase_username to true so that you do not end up with separate drop files BOB and bob on Unix based platforms (it does not matter on NT).
• If you are using your own external authentication module, you should realise that DSMTP will always do a case sensitive lookup, and it is up to you to decide whether your module does a case sensitive lookup. If it doesn't, you should probably set lowercase_username to true in order to avoid mismatched drop files.

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 which 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 that dwatch normally runs as a service on NT, as the 'system account' user, and spawns DSMTP and DPOP so that they to run as that account.
2. When a user logs on to DPOP it has to logon the user in order 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