## The DMail General Configuration Settings:

This page details only those settings in dmail.conf which are recognized by both DSMTP and DPOP, some marked thus (DL) concern DList as well. The other settings in dmail.conf are specific to a particular server. See: Settings Specific to DSMTP, Settings Specific to DPOP and Settings Specific to DList

NOTE : If you have modified a dmail.conf setting which is relevant to both DPOP and DSMTP, it is necessary to reload both servers individually with their reload configuration file commands, e.g. tellsmtp reload and tellpop reload. DMAdmin will do this automatically.

### Compulsory Settings:

(If omitted, DMail may function unpredictably, or not at all.)

 authent_method sets the method used for user/password lookups drop_path specifies the directory to use for email drop files host_domain adds a domain name to the list of domains to be recognized as being local lock_id USE ONLY IF USING NFS OR A MAIL SERVER CLUSTER, set to a unique string on each mail server in a cluster. Turns on file locking. work_path   (DL) specifies the directory for work files (also default for log and statistics files)

### Optional Settings:

(These settings may be omitted, and all have reasonable defaults.)

 authent_cache Number of authentication requests to cache, External authentication only. authent_domain true for 'user@domain' instead of 'user' to be passed to the authentication process  (external authentication only) authent_timeout Timeout (in seconds) for external authentication requests.   (external authentication only) authent_number number of concurrent authentication processes to run (external authentication only) authent_process Specifies the executable to use for external authentication process(when authent_method external) dwatch_path specifies path for .pid and .wat files and other DWatch information drop_prefix If true then the virtual domain prefix is used as part of path for drop files. hash_spool Sets hashing method (0,1 or 2). A third level (3) has been added, available in 2.8z10 and on, and 2.9h and on. Hashing is where drop_files are distributed across multiple directories. log_level (NOT DL) Specifies how much information to output to the logfile (one of error, info, debug). log_path (DL) Specifies where the server log files are to go. lookup_names Sets DSMTP and DPOP to do reverse DNS lookups lowercase_username Sets DSMTP and DPOP to be case insensitive for usernames and hence 'dropfile' names. use_maildir tells DSMTP and DPOP to use the MAILDIR format for drop files, instead of standard Sendmail style drop files. (NB: use lock_id too) vdomain Sets up a virtual domain for use with/by DPOP and DSMTP. vdomain_passwd Tells DSMTP and DPOP to use a separate passwd file for a vdomain (Unix) vdomain_separator Specifies the separator character to use with Virtual Domain prefixes.

## Detailed Descriptions of DMail/DPOP configuration settings:

#### authent_cache <integer>

Sets the number of authentication requests to cache, for both DSMTP and DPOP. The default setting for DPOP is the minimum of the setting max_users and 1000. The default setting for DSMTP is 1000

Note the DPOP process size will grow with cache usage at about 100 bytes per cache entry so a 10,000 user cache will add about 1 megabyte to the process size. See the Authentication section for an overview of this topic.

Examples:
 authent_cache 0 (no caching) authent_cache 5000 (cache the last 5000 lookups)

DSMTP has a command,
tellsmtp clear_cache_all and a setting,
cache_clear_file <filename>
for clearing its cache when you change the fwd="" field returned by an external authentication lookup - see Ext Auth FWD Field.

authent_domain <switch>

<switch> must either be true or false.

If true, this setting tells DSMTP and DPOP to include the domain name when sending a username to the external authentication process, i.e. they will send lookup user@domain. This is to permit the same username to exist on more than one domain. The default is false, i.e. only lookup user is passed. See the Authentication section for an overview of this topic.

This setting applies to all domains on both the DPOP and DSMTP servers. It cannot be changed by domain administrators.

Example:

authent_domain true

authent_method <method>

This setting specifies which type of user authentication DSMTP and DPOP are to use. <method> must be one of the following strings:

The authentication process is used either for verification that a user exists (e.g. this is what DSMTP uses it for) or it is for a full authentication of a username and password pair ( this is what DPOP uses it for).

In addition the 'external' authentication module can return more information on the user, e.g. their drop file name (including path), mail re-direction settings etc.

Note on the drop path:
the methods nt_user and unix_user mean that the servers will work out the drop path based on the settings, drop_path, hash_spool (directory hashing) and vdomain. The external authentication process can also request that the servers work out the drop path by returning the key word, "config" as the user's dropfile path. If the external authentication process returns a drop file name (including path) then it must do any directory hashing required.

If the "External" method is used, the authent_process setting must also be used, the authent_number setting may be used as well. See the
External Authentication of users
section for more details on how the external authentication process must behave.

The default is unix_user on Unix and nt_user on NT so that after installation all system users automatically have email accounts on DMail.

This setting cannot be changed by domain administrators, covers all domains and requires a RESTART of both DPOP and DSMTP if it is changed.

Example:

authent_method unix_user

or
authent_method external
authent_process process_file

authent_number <number>

This setting tells DSMTP and DPOP how many external authentication processes to run upon startup. It has no effect unless authent_method is "external". If the process being used for authentication has long delays then running several copies will allow authentication of a number of users to be overlapped. However, the caching of external authentication requests normally provides sufficient gains to avoid the need for multiple processes. So the default of 2 for both DSMTP and DPOP would normally be left unaltered.

If you wish to enter a setting to set the authent number to a different value (both servers will use the same setting) then base your setting on how fast the external program operates, and how many clients are expected to be connected at any one time.

The default setting is 2 for both DSMTP and DPOP. See the Authentication section for an overview of this topic.

We do not recommend a setting higher than 10, and suggest a value of 5 if you find that you do need it higher than the default of 2.

NOTE: changing this setting requires a RE-START of both DSMTP and DPOP. It applies to all domains on both the DPOP and DSMTP servers.

NB: increasing this setting on some platforms results in less file handles being available for TCPIP connections. See max_sessions.

Example:

authent_number 12

#### authent_timeout <seconds>

Timeout for external authentication requests. If an external authentication routine is being used for checking username/password pairs you may want it to timeout if no response is given for some time. This setting sets the length of time before DPOP and DSMTP time out on the external authentication routine.

NB: Before version 2.5d this setting only applied to DPOP.

You may need to set this longer if for example your user database is down for a short period each day or is regularly congested.

If an authentication module takes longer than this period to respond DSMTP will treat it as if it respond with the 'come back later' response, -DEAD.

If your authentication module does respond after the timeout period, DSMTP may think that it has given the response in answer to the next lookup. This is when it reports an 'out of sync' message.

In versions above 2.7q DSMTP has code to 'get back in sync' when this situation occurs.

We recommend setting this to 30 seconds if you are unsure of a value to use.

The default timeout is after 10 seconds.

Example:

authent_timeout 10

authent_process <executable>

This setting is used in conjunction with the authent_method setting. When the "external" method is used, the <executable> parameter is used to determine the name and location of the program to be used for external user authentication. It must include the full pathname and filename of the program. If authent_method is set to external then you MUST also set this setting (DSMTP will stop if you don't). See the External Authentication section for details of how an external_authentication process should work. An example nwauth.c program is supplied with the DMail distribution set.

Changing this setting requires a RE-START of both the DSMTP and DPOP servers. It applies to all domains and cannot be changed by domain administrators.

Examples:

If you wish to use NWAuth then assuming the default installation directories set this setting to,
authent_process \dmail\nwauth.exe
on Windows platforms and on UNIX based platforms,
authent_process /usr/local/dmail/nwauth

authent_process c:\mail\authent.exe
authent_process /usr/local/dmail/authent
authent_process /mypath/myauthent

drop_path <pathname>

There is no default for the drop_path so a setting for it must be included in the dmail.conf file.

Drop_path specifies the default directory for the mail drop files. These are the files that contain newly arrived mail messages for each user. Normally the drop file for a user Fred will be drop_path/Fred. This file will be appended to each time a new message arrives. The only time this directory will not be used for mail deliveries is when an external user authentication program (other than the one specified by the NetWin setting) is used. Even then, if the program returns "config" as its drop directory, <pathname> will be used.

Note these added features . . .
When <pathname> is used, DSMTP and DPOP will perform any directory hashing specified by the hash_spool setting before writing to the dropfile. On UNIX based systems, a leading ~ can be used to signify the home directory. If used, it will automatically be replaced by the user's home directory, so ~/inmail might become /usr/local/ralph/inmail.

The DMSetup installation prompts you for the drop_path setting with, for example, c:\dmail for NT and /var/spool/mail for Linux.

Examples:

 drop_path ~/Mailbox # might use /home/fred/Mailbox as fred's drop file drop_path /var/spool/netmail # will use /var/spool/netmail/fred as fred's drop file drop_path c:\pop3\mail # will use c:\pop3\mail\fred as fred's drop file

#### drop_prefix <switch>

This setting determines how the drop file name is constructed when virtual domains are being used. Drop_prefix can be set to true or false. The default is true. When this setting is true the drop file name will include the virtual domain prefix.

NB: This setting and the resulting drop file name is not affected by, whether you are using IP based virtual domains or suffix based virtual domains or by the authent_domain setting.

For example consider the case when the following vdomain line is being used and a user fred is connecting to abc.com which maps to ip number 1.2.3.4

• vdomain abc 1.2.3.4 abc.com /mail/abc_com

This second item in this line sets the drop_prefix to 'abc'.

If drop_prefix is true the drop file used will be /mail/abc_com/abc_fred
(the underscore '_' is the default vdomain_separator setting)

While if drop_prefix is false the drop file used will be /mail/abc_com/fred

NB: the example above assumes that directory hashing is turned off (hash_spool 0). The hash_spool setting controls directory hashing which affects the path.

This setting applies to all domains and by default cannot be altered by domain administrators.

example:

drop_prefix false

dwatch_path <pathname>

This setting gives the directory for the .pid and .wat files. The .pid files are written by each of the servers, DSMTP, DPOP and DList on startup and removed on normal shutdown. They are used by DWatch to monitor their status. DWatch can restart each or all of them if necessary. The files with a .wat extension will also be stored in the same directory for each of the servers, e.g. dsmtp.wat, which contains information for DWatch on how to restart that server and how often before giving up etc.

When DWatch restarts a server it also renames the current log file to a 'ded' file and places it in the dwatch_path directory.

A useful trick to know is that you can stop most of the servers by putting a file in this directory named, server.exit, e.g. if DList sees a file called dlist.exit in the dwatch directory, then it will shut itself down (and remove the exit file when it does so).

The default dwatch_path is dpop_path, however on Windows NT the DMSetup installation wizard creates a specific 'dwatch' directory and points the dwatch_path setting at it. See the DWatch section for more details.

This setting applies to all domains and by default cannot be altered by domain administrators.

Example:

dwatch_path /usr/local/dwatch

hash_spool <number>

Specifies how the mail drop file names are 'hashed' (distributed) into drop directories.

Hashing is used to make up for Unix slow linear directory search. It also avoids overly large directories on large email systems.

NOTE: This setting must be the same for both the POP and SMTP servers of your mail system. In the case of DSMTP and DPOP they will both use this same setting and therefore match.

The <number> parameter identifies which hashing method to use. There are currently three options:

 0: No hashing 1: Add one extra directory level. The directories in the new level are named a-z, but note that the following is done to decide which drop files go in which of the 26 directories; sum the first four characters of the drop file name,modulo 26, i.e. any username beginning 'fred' will always end up in the same directory but it isn't named f for fred rather in this case it will be named b. E.g. fred's drop file might go in, \dmail\in\b\fred where the hashing has added the \b directory. 2: Add two extra directory levels. A simple naming method is used; the first two characters are used to name the two intermediate directories, e.g. /f/r/fred 3: This type of hashing is available in 2.8z10 and later, and 2.9h and later. It creates two directory levels, as does level 2, but it results in a much more even spread of files. This is an ideal hashing level to use for very large systems. An example hashing directory is /n_b0/w9/fred

The directories generated by the hashing method are appended to the pathname specified by the drop_path setting. If the directories do not exist, then DSMTP or DPOP will create them. The default is "0", which implies no hashing.

This setting is global to all domains and by default cannot be altered by domain administrators. This setting applies to DSMTP, DPOP and DList.

Note: if this setting is altered you MUST restart both DSMTP and DPOP.

Do not change this setting without planning first - otherwise you may be flooded with complaints about users' mail disappearing!

Example:

hash_spool 1

host_domain <domain>

This setting adds <domain> to a list of aliases for the machine running DSMTP. Any checks on a message's destination for (amongst other things) local delivery will also compare any names in this alias list with the destination.

NOTE: The first host_domain entry in the config file must be the host machine's actual name, i.e. the actual name that the machine has on the internet (or intranet) . Any messages sent from, or generated by the host machine will use this entry in the 'MAIL FROM' line to identify itself. So for a non-intranet server the first host_domain entry must be a domain name that can be resolved to an IP address by any machines wishing to talk to DSMTP.

Except for the first entry, the <domain> parameter may contain the wildcard character '*'. Note that *.domain.com does not include domain.com itself, but *domain.com does!

Any number of these settings may be used. There is no default.

Example:

host_domain my.resolvable.domain.com
host_domain *mydomain.com

lock_id <string_unique_to_machine>

If set then DSMTP, DPOP and IMAPD will do file locking on drop files and also take other safeguards needed for NFS and when running the servers in a cluster.

The setting causes the servers to use Netwin's own file locking mechanism to prevent more than one server writing to the user's drop file at the same time.

This setting must be used when running multiple DSMTP, DPOP or IMAPD servers talking to the same mail spool (drop_path) from different machines or when the mail spool is on an NFS.

On Windows platforms you must also use it where the servers are in a cluster and share the same drop_path.

IMPORTANT:You must ensure that all the machines in the cluster have their system time set to within 30 seconds of each other. Otherwise the file locking will not work. The DSMTP server will log very clearly if their is a time discrepancy between machines.

This setting may only be set once in dmail.conf and applies to all domains.

An alternative is the MAILDIR system which removes the need for drop file locking, see
use_maildir. NB: if using maildir and DPOP you must still set, lock_id so that DPOP knows to check that the same user is not connecting to multiple machines at once.

Example:

lock_id mail1
set in dmail.conf on machine, mail1.domain.com and,

lock_id mail2
set in dmail.conf on machine, mail2.domain.com, where the two machines share the same drop_path.

log_level <level>

This setting determines what types of event information should be written to the logfile. There are three levels: error, info, debug. Error is the default setting, and the usual setting for operating in.

 error: the only information written will be errors, warnings, socket read and write information and minimal progress information. info: as well as the error information, this setting gives much more progress information, as well as file open and close calls. debug: as well as the info information, this setting gives a whole lot of internal status information, function calls...all sorts of stuff. However, it may slow down operation slightly and can produce large log files, so it is not recommended for normal use.

If DSMTP is crashing or doing very peculiar things, you should immediately ensure that it is running with the debug option.
So edit the log_level setting in dmail.conf to read,
log_level debug
then reload both DSMTP and DPOP.

The most useful things to NetWin support are the config file and the log file. The log file is far more useful if the log_level was set to debug.

If setting log_level to debug because of DSMTP problems you should also consider setting, log_data true. The log_data setting only applies to DSMTP and makes it log all of its TCPIP transactions (DPOP does this on debug log level anyway).

You should also consider setting, pop_event_log to make DPOP log POP3 events.

NB: This setting does not apply to DList, see the setting dlist_loglvl for setting DList's logging level. It does apply to both DSMTP and DPOP. The log file writing is cached so it should not detriment the servers' performance. (If you want DSMTP to not cache log entries then set, log_flush true.)

This setting is global (it does not apply to individual domains).

NOTE: Don't get scared by log lines that you see on info or debug level. They are generally of a technical nature, which can make them worrying :-) See, Deciphering Log Files for more help.

Common Settings:
log_path
DSMTP settings:
max_loglen, rotated_logs
DPOP settings:
max_log_size, log_status

Example:

log_level debug

log_path <pathname>

This setting specifies the path for log files. The three servers record error and other informational messages into a file called servername.log, e.g. dpop.log for DPOP. Old versions of this file are called, in the case of DPOP, dpop1.log, dpop2.log etc. These files are stored in the work_path by default, but sometimes the system administrator may wish to keep all log files in one place. This can be absolutely anywhere, so long as it is a full pathname. By default, the logfile path is the same as the work path. Note that on Windows NT the DMSetup program creates a \dmail\log directory and sets the log_path setting to point at it.

In addition to dsmtp.log and dpop.log, both DSMTP and DPOP can be made to create statistics files, e.g. DSMTP creates a daily summary log file stored at <pathname>, with a name of dmddmm.log, e.g. dm2704.log. See Statistics Files in the Disk Use And Files section.

DWatch also stores a temporary log file, dwatch.log, at <pathname>.

This setting applies to all domains and by default cannot be altered by domain administrators. This setting applies to DPOP, DSMTP and DList, as well as DWatch (some DMail utilities do not make use of it).

Common Settings:
log_level
DSMTP settings:
max_loglen, rotated_logs
DPOP settings:
max_log_size, log_status

Examples:
log_path      work_path
log_path      mypath/for/log/files/
log_path      C:\dmail\log

lookup_names <switch>

Set true if DPOP and DSMTP should lookup domain names for checking valid connections - (CAN BE SLOW). If this setting is true then when DPOP gets a connection from say 161.39.2.44 it will do a reverse DNS lookup to turn this into whatsit.company.co.nz. This is only useful for the following reasons:

1. if you want to have incoming connections referred to by their domains, i.e. logged with their domain name as well as their IP address.
2. if you don't want DSMTP to accept connections where reverse DNS lookups fail. To do this you should set
reject_no_reverse true
in dmail.conf as well, so that when a connection opens, if the reverse DNS lookup fails then the connection will be rejected. It is generally faster to restrict access some other way as reverse name lookups can be quite slow.

The setting for lookup_names is disabled unless <switch> is "true", the default is false.

This setting applies to both DSMTP and DPOP, it is applied to all domains and by default cannot be altered by domain administrators.

Example: To turn reverse DNS lookups on, set

lookup_names true

If set true then DPOP will only work with lower_case usernames. So user BOB logging in will be assumed to be user bob, and his password will therefore be checked against user bob's password.

This means that drop files will also be forced to lowercase. This is how this setting effects DSMTP as well, as when true DSMTP will also only create lowercase drop files.

The default for this setting is false - i.e. usernames and hence dropfiles are case sensitive.

This setting affects both DSMTP and DPOP and is global across all domains. By default domain administrators cannot alter it.

Notes:

1. Previously this setting only applied to DPOP, i.e. versions before 2.4e
2. If your authentication module is not case sensitive (e.g. NWAuth, Windows NT, or your external auth module), then using this setting stops multiple case license user entries, e.g. you won't have three users bob, BOB and Bob.
3. DSMTP does not use this setting for deciding if incoming mail is for a valid local user. The lookup that it does on incoming mail for Bob@domain, is case sensitive, so it looks up Bob. If your password file only has a user bob, on NT it will succeed, on Unix it will fail.

For this reason, we have the unix_case setting for Unix systems where you want such a test to succeed.

See Case Sensitivity for more details.

Example:

use_maildir <switch>

Tells DSMTP, DPOP and IMAPD to use the MAILDIR format for drop files, instead of standard Sendmail style drop files.

The maildir format uses a number of directories and unique filenames to avoid servers accessing the same files at the same time and hence the need for file locking.

NB: use lock_id as well as use_maildir true if using an NFS spool or multiple mail servers in a cluster and using DPOP. This is because the lock_id setting tells DPOP to check that the user logging in is not already connected to another POP server in the cluster. The servers know not to also do file locking on the MAILDIR files when both use_maildir and lock_id are set.

The settings, maildir_home and maildir_althome are the maildir equivalents of, drop_path and alt_drop_path. You do not have to use them (and the servers will simply create the maildir directories in the same location as the old drop files), but often a drop file name and maildir directory need the same name. So we recommend that you use the maildir_home setting (and the maildir_althome setting if needed) to specify different directories for the maildir directories.

Also if you use the maildir_home directory then DPOP will burst both the old 'drop file' and the new maildir directory to the same bin files for all users. Thus you can easily turn maildir on and off.

Note that DPOP use the dslave process to burst all drop files when use_maildir is set, rather than only those bigger than the slave_burst_size setting. So you should check that you have set slave_number to something higher than 1.

NB: use_maildir was only brought in the 2.8 versions of DMail. We still consider it to be a 'beta' set of settings as at, 12 October 2000. Contact DMail Support if you have any questions on it.

Converting to MAILDIR:

Set, use_maildir true, and specify a maildir_home directory different from your drop path.

Also set maildir_althome for any virtual domains, e.g.,

vdomain a b vdomainx.com c:\dmail\vdomx\

becomes,
vdomain a b vdomainx.com c:\dmail\vdomx\
maildir_althome vdomainx.com c:\dmail\vdomx\maildir\

Leave your lock_id setting set if using DPOP and either an NFS drive or server cluster.

If you set,

use_drop true
then DPOP will continue to burst normal 'drop files' for any mail, and store all mail left on the POP server in it's own 'bin files'.

Converting from MAILDIR back to only 'drop files':

Set, use_maildir false, and set, dpop_maildir true so that just DPOP scans the MAILDIR directories and DSMTP no longer writes to them.

Leave you maildir_home directory, so that DPOP can retrieve mail from that location.

For IMAPD, use, #imapd_include to make a IMAPD only config file, with use_maildir true in it.

Example:
use_maildir true

vdomain

Virtual Domain support. A number of vdomain lines may be used to specify domain prefixes, ip numbers, virtual domains and drop paths. This allows different drop paths and username prefix strings to be specified for users connecting to different virtual domains based on IP number or username suffixes. See the virtual domains section of the manual for details of setting up virtual domains for use with DSMTP and DPOP.

The default is no virtual domains.

Multiple lines (one for each virtual domain) are required.

These settings cannot be altered by domain administrators by default and they apply to both DSMTP and DPOP.

NOTE: after altering any vdomain setting you MUST restart both DSMTP and DPOP.

DPOP needs to be able to work out which virtual domain a user belongs to when they log in to check their mail. DMail provides two methods for doing this, virtual domains can be either Suffix based or IP address based.

For virtual domains based on IP address rather than username suffix use the following format:(where DPOP tells the difference between users by the IP address they log into to check their mail)

where
 prefix This is the internal prefix that DSMTP and DPOP will attach to the start of the username, e.g. prefix_bob, for referring to the users of this domain. Externally this is only visible for setting up authentication, i.e. adding users, and naming drop files. See drop_prefix NOTE: The prefix MUST be different for different virtual domains. And must NOT include an underscore character IP address This is the IP address that users from this domain MUST connect to in order to read their mail. This is only needed by DPOP, so DSMTP ignores it (DSMTP knows that incoming mail is for this domain because the mail is addressed to this domain). This is the KEY to how DPOP tells the difference between users on IP addressed based virtual domains, i.e. it detects the ip address they connect to and assigns them to a domain based on this information. domain This is the domain name for which these virtual domain settings apply drop_path This is the FULL path to the directory where users of this domain should have their mail stored (any hashing directories will be added onto this). '~' can be used as the first character of the drop file path in the same way as it is used in a drop_path setting.

Examples: (assuming the default vdomain_separator of '_')
vdomain sal 1.2.3.4 sales.netg.com /var/spool/salesmail
will set up a virtual domain for the domain sales.netg.com. Users will connect to DPOP only on the IP address, 1.2.3.4 , with a normal username, e.g. bob's username is bob. The system administrator will have added a user bob to the authentication database with username, sal_bob and bob's mail will be found in the drop file, /var/spool/salesmail/sal_bob

vdomain dom1 161.33.2.44 ast.netg.com /var/mail/domain1

vdomain dom2 161.33.2.30 lnt.netg.co.nz /var/mail/domain2

For virtual domains based on username suffix rather than ip number use the following format: (where DPOP tells the difference between users by a suffix on the username that they use to login with)

vdomain    prefix    suffix    domain    drop_path

where
 prefix This is the internal prefix that DSMTP and DPOP will attach to the start of the username, e.g. prefix_bob, for referring to the users of this domain. Externally this is only visible for authentication, i.e. adding users, and naming drop files. See drop_prefix NOTE: The prefix MUST be different for different virtual domains. And must NOT include an underscore character suffix This is the suffix that users will add onto the end of their usernames in their email client, e.g. bob will enter bobsuffix as his username in his email client, for the purposes of connecting to DPOP, to read mail. NB: this setting includes the separator character! This is the KEY to how DPOP tells the difference between users on suffix based virtual domains, i.e. users connecting (on any ip address) have their username checked for this suffix, and if found DPOP assigns them to this domain. domain This is the domain name for which these virtual domain settings apply drop_path This is the FULL path to the directory where users of this domain should have their mail stored (any hashing directories will be added onto this). '~' can be used as the first character of the drop file path in the same way as it is used in a drop_path setting.

Example: (assuming the default vdomain_separator of '_')
vdomain sal /sales sales.netg.com /var/spool/salesmail
will set up a virtual domain for the domain sales.netg.com. Users will connect to DPOP on any IP address with the username, user/sales, e.g. bob/sales . The system administrator will have added a user bob to the authentication database with username, sal_bob and bob's mail will be found in the drop file, /var/spool/salesmail/sal_bob

vdomain_passwd <domain> <path>

When using many vdomains with unix_user authentication, it is sometimes more convenient to maintain separate unix-style passwd files for each vdomain. This command permits that to be done.

The <domain> parameter must be a domain name, with no wildcards.

We STRONGLY RECOMMEND NOT using this setting on Windows based platforms - if you want a file type user database then use NWAuth.

Note: DSMTP and DPOP will create the drop files for all users in the domain which the passwd file is for with the same uid and gid as the passwd file itself. E.g. if you have a vdomain_passwd line for the domain domain1.com of /etc/passwd2 then all users in domain1.com will have drop files with the same uid and gid as the file, /etc/passwd2.

This setting has no default value and by default cannot be altered by domain administrators.

Example:

vdomain_passwd vdomains.r.us /usr/local/vdomsrus/etc/passwd

vdomain_separator

Virtual Domain separator. This setting specifies the type of separator to be used for separating the domain prefix string from the username or filename, when operating virtual domains. The default is '_'.

The domain prefix and separator only appear in the users drop file name (unless drop_prefix is false) and in the authentication database (to distinguish between the same username on two different domains).

NOTE: this setting together with the domain prefix set in the vdomain line DO NOT affect the username that the user logs in with (or their email address).

So if the separator was the default '_' and the vitrual domain prefix is 'dom1' for domain one, then ralph from domain one becomes dom1_ralph. Similarly if the prefix for domain two is 'dom2' then user ralph from domain two becomes dom2_ralph in the password file. You can use this setting to change the separator to another character, e.g. '+', which would make the two examples just given become, dom1+ralph and dom2+ralph.

NB: This character is also used in naming the user's drop path, so think carefully of what character you use, for example * is not allowed as then you might get a drop file name of, /mail/dom1*amy, similarly '/' might cause ambiguity with a drop file name of /mail/dom1/amy.

Note also: you can NOT have any usernames with the vdomain separator character in them, in ANY of your domains if you are using virtual domains.

This setting is used by both DSMTP and DPOP and by default cannot be altered by domain administrators.

Examples:

 vdomain_separator _ # e.g. dom1_ralph vdomain_separator - # e.g. dom1-ralph

work_path <pathname>

This setting specifies the directory for the working files, temporary files, data files etc. for all three servers, i.e. this includes DList. By default log and usage statistics files are also stored here. The default work_path for each server is the same as the server's work path setting, e.g. dpop_path for DPOP etc., however for DMail, a common DMail directory would normally be used for all three servers' work paths.

DMSetup suggests a default work_path of
work_path \dmail\work (Windows platforms)
work_path /usr/local/dmail/work (Unix based platforms)

Examples:

 work_path drop_path # will set it to same as the drop_path setting work_path /usr/local/dmail # might be used on a Unix machine work_path c:\mail\DMail\work # might be used on an NT machine