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.)
Optional Settings:(These settings may be omitted, and all have reasonable defaults.)
Detailed Descriptions of DMail/DPOP configuration settings:authent_cache <integer>
<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 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:
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 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
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 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
c:\mail\authent.exe 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 . . . 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_prefix <switch>
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 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:
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! See also,
Example: hash_spool 1 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
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
Example: lock_id mail1
lock_id mail2
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.
If DSMTP is crashing or doing very peculiar things, you
should immediately ensure that
it is running with the debug option.
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. For more information see, Log Files. See also,
Example: log_level debug 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). See also,
Examples: log_path work_path log_path mypath/for/log/files/ log_path C:\dmail\log 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:
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 lowercase_username <switch> 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:
See Case Sensitivity for more details.
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.,
Leave your lock_id setting set if using DPOP and either an NFS drive or server cluster.
If you set,
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:
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)
vdomain prefix
IPaddress domain drop_path
where
'~'
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 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
'~'
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_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 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 '_'. 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: 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
Examples: Setting not found?!
You probably got here by using a link on our Complete Settings List page.
That page lists all settings at the time of the latest compile, so we probably have not documented
the setting you are looking for yet.
Please contact DMail Support with a list
of any settings you want described and we will add them to these pages.
|