Configuration Settings Specific to DSMTP:This page details only those dmail.conf settings which apply specifically to DSMTP.For more settings see: Settings Common to DPOP and DSMTP, Settings Specific to DPOP and Settings Specific to DList Note: After modifying a DSMTP setting you should do a tellsmtp reload command or send a reload command to the DSMTP server using DMAdmin. Compulsory settings:(If omitted, DSMTP may function unpredictably, or not at all.)
Often Used Optional settings:(These settings may be omitted, and all have reasonable defaults)
ban_ip Specifies an IP address that DSMTP should not talk to.
Obscure Optional settings:(These settings may be omitted, and all have reasonable defaults) add_footer Appends the
given footers file if the envelope from matches the given domains. Multiple entry settings: These settings may occur more than once(repeated from lists above).
add_footer Appends the given footers file if the envelope from matches the given domains.
Detailed Descriptions of DSMTP Configuration Settings:add_footer <filename> <domain>[,<domain>,...] This setting specifies a footer file to be added onto the end of all messages sent out by DSMTP, from users on any of the specified domains. The <filename> can be specified with a path, or without. If a path is not given then DSMTP looks in the directory specified by the dsmtp_path setting. (NB: DON'T specify a path in version 2.8b, i.e. put the footer file in your dsmtp_path directory.) One or many domains can be specified. Use a comma separated list (no spaces)
to specify a list of domains to which the setting should apply. In addition,
you can use one of the keywords to save typing,
This setting tells DSMTP which file contains the user alias information.
The <filename> parameter must include the full pathname and the
filename of the original alias file. DSMTP makes a copy of this file in
aliases.dml, in its working directory to use when doing user alias lookups. Alias files are
textfiles containing lines of the following format:
Lines starting with a hash are treated as comment. Destinations that
have multiple words should be within quotes. e.g.
NOTE: All aliases found for a user by DSMTP are applied. You can include another alias file using the :include: in the
destination, e.g. to include the alias file /etc/aliases2
you could use the following line,
As the examples above show, you can use an alias in the same way as you can use a forward setting to make DSMTP write incoming messages directly to file or to pass them to a robot with the pipe symbol, | . Note: The alias must be entered without a domain, but the destination for the alias should contain a domain - otherwise DSMTP will assume that the domain is the domain given in the first host_domain setting. If you do not wish to specify the destination domain and you don't like the host_domain default then you should put the alias in a domain specific alias file, identified in dmail.conf with the alias_file_domain setting. You do not need to enter virtual domain prefixes
in the alias file. E.g. with a
vdomain prefix of dom1_ the following line is incorrect,
Aliases only apply to valid local users, so DSMTP will check that an incoming message is for a valid local domain before it checks for an alias, whereas a forward rule can apply to local or non-local users, i.e. any domain. For more information, see the Forwarding and Aliasing section. Example: alias_file /usr/aliases alias_file_domain <domain> <filename> This setting works exactly the same way as alias_file, except that the alias file <filename> is only applied to domains matching <domain> which may include wildcards. This allows you to set up alias files for specific domains and also to create global aliases. To create global aliases you can add the setting,
NOTE: All aliases found for a user by DSMTP are applied. NOTE: You do not need to enter virtual domain prefixes
in the alias file. E.g. with a
vdomain prefix of dom1_ the following line is incorrect,
If a domain is not specified on the destination, e.g.,
In version 2.7m and above you can use the syntax,
For more information, see the Forwarding and Aliasing section. Example: alias_file_domain /usr/aliases alt_drop_path <domain> <pathname> This setting specifies an alternative path to use for the dropfiles of messages whose destination is <domain> The <domain> parameter may contain the wildcard character '*'. The path named by the pathname parameter must exist. This setting will be ignored if authent_method is set to external. This setting can be used any number of times. Note: This setting will be ignored unless the <domain> parameter is specified as being local by using the host_domain setting. The last applicable setting will be used. Example: alt_drop_path *.spammers.com /etc/trash/ This setting specifies various permissions or actions which are allowed for any user who has authenticated to DSMTP using the SMTP AUTH command. This setting is a comma separated multiple value setting which can take any of the following key words:
If 'relay' is set then DSMTP will automatically advertise,
If a non-local recipient is accepted then DSMTP will log, Command RCPT OK (authenticated channel) More about SMTP AUTH ...
NB: adding this setting will mean that some email clients like Netscape Mail force the users to turn on SMTP AUTH. Generally this is not a problem, as Netscape Mail instructs them on how to do it, but it may be confusing to some users. If using the forward_user system as well then you should probably set the setting,
We also have a new proxy widget called SmtpAuth (currently only in windows beta form) which takes a username and password to authenticate to an SMTP server with. So users with an email client that does not support the SMTP AUTH command can run this on their machine and point their client at it instead of directly at your smtp server. It then authenticates to your server before sending on any mail feed to it. If it is a whole domain coming through another trusted server then they could use the SmtpAuth proxy and feed all their outgoing mail through it. As we only have SmtpAuth on NT their server would have to be running on NT. If their server is DSMTP then we plan to add a setting so that DSMTP 'auths' all outgoing connections to a given ip address. So contact DMail Support if you need that setting. Example: auth_allow relay
This setting switches off the announcing of ESMTP AUTH under various conditions, so that AUTH lookups are not done when not necessary. You can use <ipnumber> to specify ip addresses. It can be,
This setting is a comma separated multiple value setting which can also take the following key words:
The 'recentpop' keyword, makes DSMTP check the ip address of a connection against its list of ip addresses which have recently successfully logged in to the DPOP server. This setting is only of use if you have set, forward_user to be true. Example: auth_hide 127.0.0.1,1.2.3.4,recentpop
This setting specifies an IP address that DSMTP should not talk to. If something attempts to connect to DSMTP from this IP address, DSMTP serves them with this line: 551 You have no permission to talk, Goodbye at the end of which the connection is dropped by DSMTP. Example: To stop anyone connecting from the IP address 1.2.3.4, use ban_ip 1.2.3.4 Allows specified ip's to be exempted from whatever is set in ban_ip
Example: Specifies patterns for banned MAIL FROM: lines. If set, DSMTP will scan all MAIL FROM: lines in the SMTP envelope to see if the sender's email address contains the given string. If it does, DSMTP will bounce the message. NB: DSMTP does not check the message headers for the specified string. This setting can be given multiple times in dmail.conf. Example: ban_mailfrom bob.com will make DSMTP bounce all messages which are sent by a user whos address contains the string 'bob.com'. Specifies patterns for banned rcpt to lines.If set, DSMTP will scan all RCPT TO: lines in the SMTP envelope to see whether any of the message recipients' email addresses contain the given string. If they do, DSMTP will bounce the message to only that specific recipient. NB: where a message is to multiple recipients, DSMTP will still deliver the message to any other recipients that do not match the given string. NB: DSMTP does not check the message headers for the specified string. This setting can be given multiple times in dmail.conf. Example: ban_rcptto bob.com will stop DSMTP from delivering mail to any destination address (given in the envelope RCPT TO: line) that contains the string 'bob.com'. This setting is an extension to the bomb_max setting. It is used for catching particularly devious mail-bombs which arrive over an extended period. The setting tells DSMTP how thoroughly it should clean up its sender-recipient cache. Once an hour, DSMTP goes through the cache and subtracts <number> from each counter (the entry will not be removed, even if the counter becomes 0). Under most circumstances, the <number> parameter should be set to be the same as the bomb_max setting. This assumes that any mail-bomb will take the form of a surge of messages in a short time. Some particularly devious sorts might send one message every five minutes for a day, which would still be a mail-bomb. If this is suspected to be happening, setting <number> to be much lower would trap the incident. Extreme care must be taken with this setting, however, as DSMTP will not deliver messages which it thinks are mail-bombs, and it will only keep the last 10 it has received. Basically, if DSMTP receives bomb_max messages in (bomb_max/bomb_dec) hours, it will trigger a mail-bomb alert. The default value is 50. Example: With bomb_max 50 if we want to define 50 messages in 5 hours as a bomb we set bomb_dec to 10 ( as 5 = 50/10 ): bomb_dec 10 This setting tells DSMTP where to put rejected mail-bomb messages. A maximum of bomb_max messages will be placed here, the last one being the most recent. The default value is work_path Example: bomb_dir /dev/null This setting tells DSMTP how many sender-recipient pairs to cache for mail-bomb detection. Every time DSMTP receives a message to be delivered locally, it stores the sender-recipient pair. If the pair is already present, it increments the associated counter. If there are <number> entries already in the cache, DSMTP finds one with a low count and deletes it to make room for the new one. The larger this setting is, the more likely DSMTP is to detect a mail bomb. Performance degradation may occur if it is made too large. The default value is 2000. Example: bomb_entries 500 This setting tells DSMTP how many sender-recipient pairs to cache for mail-bomb detection. Every time DSMTP receives a message to be delivered locally, it stores the sender-recipient pair. If the pair is already present, it increments the associated counter. If there are <number> entries already in the cache, DSMTP finds one with a low count and deletes it to make room for the new one. The larger this setting is, the more likely DSMTP is to detect a mail bomb. Performance degradation may occur if it is made too large. The default value is 2000. Example: bomb_entries 500 This setting defines what DSMTP is to call a mail-bomb. If more than <number> messages are received for the same user, from the same source in a one hour period DSMTP will alert the system administrator and intercept any further messages with the same sender-recipient pair. These will be placed in the directory specified by the bomb_dir setting. To disable this feature, set <number> to something big, like 10000. The default value is 50. Example: bomb_max 20
This setting tells DSMTP whether or not it should include the body of
a message in its Delivery Status Notification (DSNs can result from a failed
delivery (bounce) or a successful one, if requested by the sender as set out in the
Extended SMTP RFC). DSN requests are added by the sender's email client to the
MAIL FROM: line of the ESMTP envelope, e.g.
This setting can take true, false (= never) or always as an argument, with the following meanings: true - if requested by the sender, send the message body with
the notification message.
The default is false, which means that only the headers will be returned to the sender on a bounce or DSN. Example: bounce_body false
This setting specifies when to truncate the body of a bounced message. If the message body exceeds <number> kb, DSMTP will truncate it. The default is 20. Example: bounce_maxlen 5 cache_clear_file <filename> [max_frequency_limit_seconds] Activates authent cache clearing when specified file is modified. If you modify a user's details in the user database, including the quota="x" or fwd="y" fields, then the changes will not be noticed by DSMTP until it's authentication cache is cleared. Usually this is done with the tellsmtp command,
The NetAuth Web user authentication interface can also be set to do this. This setting allows you to make DSMTP notice when a user's information has changed and reload the cache itself. If the file is changing frequently, then you will probably want to use the optional max_frequency_limit_seconds option, to limit how often DSMTP can refresh the cache by clearing it. If you set this to 600 seconds, for example, then users will have to wait up to a maximum of 10 minutes for their database changes to take affect. This setting was added in version 2.9a For details on the authentication cache, see
Example: cache_clear_file c:\dmail\nwauth.add
cache_clear_file c:\dmail\nwauth.add 900
check_lwrusername <true / false / always>
This setting lets you control the casing of lookups in DSMTP for recipients. If you set it to always, it will always do lowercase lookups on the username. If you set it to true, it will try a lowercase lookup first, and if it cannot find a match it will then try an exact match.
NOTE: By default, DSMTP will use any DNS servers which you have set up your operating system to use (this includes any domains listed in your hosts file (commonly /etc/hosts or \winnt\system32\drivers\etc\hosts). So you probably don't need to use this setting. This setting is provided so that you can specify a list of DNS servers that DSMTP should use to lookup domains (resolve them to an IP address) INSTEAD of any DNS servers setup for use in the operating system. For outgoing mail, DSMTP will attempt to connect to the machines specified in email messages by using this setting for all DNS lookups, except for any that match those given by the gateway setting. This setting can be used any number of times or take a comma separated list of IP addresses. If multiple hosts are given, DSMTP will go through them all until it gets a valid answer. The default is to use the system DNS setup, i.e. no dns_host setting. Example: dns_host 127.0.0.1 This setting tells DSMTP how long to wait (in seconds) before giving up on a DNS lookup. If <time> is set too low, DSMTP may record a lookup failure where none occurred. Messages addressed to a domain whose lookup failed are placed in the retry queue. Repeated failures will cause DSMTP to bounce the message. If this appears to be happening too often, try adding another DNS host to dmail.conf, or increasing the <time> parameter. The default value is 10 seconds. Example: dns_timeout 20 domain_chroot <domain> <path> (Unix based platforms only) It is possible to configure DSMTP to make use of user-maintained alias files (using alias_file_domain for instance) and forward (.fwd) files. These can include references to files and/or autoresponders. Particularly in the case of virtual domains, it may be necessary to chroot to a particular directory before performing the desired operation. domain_chroot does this. The <domain> parameter may contain wildcards, DSMTP does not check that <path> exists. Example: vdomain prefix 1.2.3.4 vdomains.r.us.com /usr/local/vdomsrus/var/spool/
If a domain has a domain_chroot setting then references to robots and
different drop files in forwarding rules and the like, can take
relative paths. E.g. in the example above, the domain_chroot for vdomains.r.us.com
would mean that a forward rule for a user in that domain to a drespond
robot would have to call the robot from a relative path, with its root
based at the chrooted domain, i.e. /usr/local/vdomsrus, e.g.
NB: domain_chroot is intended for Unix based platforms only. In versions 2.5d and 2.4k DSMTP's default behaviour was changed on Unix platforms so that it no longer does dotstuffing on messages going to robots. On Windows platforms the dotstuffing of messages to robots still occurs. This setting is provided for backwards compatibility only. If set true then DSMTP will carry out dot stuffing on messages that it writes to robots. Example: dot_stuff true This command tells DSMTP how big to let dropfiles become. If a dropfile is bigger than <number> kb, DSMTP will not deliver the message (it will alert the sender to the problem, but not the recipient). This setting should be used in conjunction with user_quota because when a user checks their mail, DPOP clears the dropfile and sorts the messages within it into its own 'bin' files. So a user can have an empty dropfile but still use up a lot of space in message storage on your email server. Example: drop_max 5120 This is the DSMTP installation directory. It will contain the DSMTP executable, help files and utility executables. The work_path and log_path default to here. The DMSetup installation wizard will by default create a directory called 'dmail' and point all of the server's home directories at it, i.e. dpop_path, dsmtp_path and dlist_path are all made to point to the directory called DMail by default. This setting applies indirectly to DSMTP,DPOP and DList. It is global across all domains and by default cannot be changed by domain administrators. Example: dsmtp_path c:\mail\dmail\ external_processor <true/false> This activates dsmtp's message processing daemon functionality. This allows you to run a process on all incoming mail before DSMTP delivers it to local or non-local users. message_process_action is newer and much easier to use plus more powerful, we recommend you use this instead. When this setting is set to true, DSMTP writes a file called m_x.dmn in the work_path directory when it receives the closing dot of an incoming message. It will write the incoming message to a temporary file, m_x.tmp. NB: the value x will be a unique number starting at 0, e.g. 0 or 1 or 2 or, 99999 etc. It is then up to the external processor (daemon) to detect this file, and process m_x.tmp, i.e. a file of the same name but with the ending '.tmp'. NB: it is important that the external processor does not touch the .tmp file until the .dmn file appears, as DSMTP may still be writing to it. The processor can make whatever modifications to the message file m_x.tmp that it sees fit, including removing the file altogether. Common things are removing objectionable content, infected attachments, adding/removing footers, altering/removing headers, etc. The only proviso is that if it leaves the file it must leave a valid message otherwise DSMTP may not be able to deliver the message. DSMTP waits for a file, m_x.rdy to be created by the external processor. When that file arrives, DSMTP processes the message according to what it finds in the .rdy file. 1. If the .rdy file is empty then DSMTP will deliver the message it finds in the m_x.tmp file. 2. If the .rdy file is empty and the .tmp file has disappeared then DSMTP will bounce the message and give a permanent error response code (i.e. 500 level). 3. If the .rdy file has a first line with an SMTP-style reply line, DSMTP will use that response code and message for it's SMTP response to the message data and not deliver the message, i.e. DSMTP will bounce the message with that response code. A negative SMTP-style reply line starts with a '4' or '5', i.e. >=400 It is possible to run multiple daemons. The first daemon can write a m_x.2 file to trigger a second daemon, so and on, until the final daemon writes the m_x.rdy file. NB: DSMTP freezes the incoming message channel until it sees the .rdy file and knows how to respond. So the external_processor has up to tcp_timeout seconds to process the message and create the .rdy file. It it does not DSMTP will drop the TCPIP connection and tidy up the external_processor files. In practice it probably has a much shorter time to deal with the message, because email clients generally have a much shorter timeout for sending the message than the tcp_timeout value. Email clients typically have a timeout value of 15-30 seconds. NB: be careful not to set this setting true if there is nothing there to process the files, - otherwise the mail will never be delivered. This setting was added in version 2.8i Example: external_processor true
external_viruschecker <command_line> Tells DSMTP to use an external virus checker on MIME attachments from extract_mime. For every attachment extracted with extract_mime, DSMTP spawns this command line and replaces the macro $FILE$ with the full filename of the extracted attachment file. NB: DSMTP only spawns the external virus checker on MIME attachments that it checks. It does not run the virus checker on EVERY message. DSMTP expects the virus checker to delete infected files, and does not examine the output of the virus checker itself. If any of the attached files have disappeared, DSMTP will reject the message and send a 'infected attachment' warning to the sender. This setting was added in version 2.8n. Example: extract_mime c:\dmail\extract
extract_mime <path> [file_extensions_list] Tells DSMTP where to extract particular MIME attachments. If set, DSMTP will extract all MIME attachments or those of the type specified with the optional file_extensions_list to the given <path>. It then just leaves them there. It is intended that the external_viruschecker command is used in order to make DSMTP take further action with the attachments. This setting could be used by itself to archive attachments, e.g. images, that are passed through your system. Notes:
If any of the attached files have disappeared, DSMTP will reject the message and send a 'infected attachment' warning to the sender. This setting was added in version 2.8n. Example: extract_mime c:\dmail\extract extract_mime c:\dmail\images gif jpg bmp fallback_address <domain> <address>
This setting sets up a fallback address for a given domain. If a message is sent to a user at the given
domain, but that user doesn't exist (or no longer exists), then the message will be sent to the given address. The FAQ, I want all domain1 email which does not go to a specific user . . . is a common use for this setting. Example: fallback_address my.company.com boss@my.company.com This setting activates a restriction on the number of messages an IP number can send through DSMTP per hour. The default value is 10000. Example: fromip_max 50 This setting allows exceptions to fromip_max for local/trusted IP numbers. Wildcard characters are permitted. Example: fromip_nolimit 127.0.0.1
Any incoming message whose next destination is of the form user@domain,
and matches <wildcard> will be sent to <address> instead,
so long as <address> is valid. The <address> parameter
must be of the form user@domain (i.e. it must be a valid final destination).
The comparisons are done upon receiving the RCPT TO: SMTP line, so internally
generated messages (such as those generated by the forward
or alias settings) will not be checked. Any
number of these settings may be used. All applicable forward
settings will be applied. The '*' wildcard character
may be used in the <wildcard> parameter.
The message will not be delivered to the original recipient, so if you
want the original recipient to receive the message use, forward_cc.
Note: There is a fallback_address setting that can pick up addresses not covered by a forward rule, see the faq I want all domain1 email which does not go to a specific user to . . . Forward rules can apply to any users of any domain, not just local users as they must be in an alias file. New in version 2.8m and above, you can use forward settings for domain rewriting, i.e.,
For more information see the Forwarding and Aliasing section. Example: forward bgates@windows.com jreno@doj.gov will send a copy of all Bill's mail to Janet forward_cc <wildcard> <address>
This setting is matched against all recipients of a message. It causes any message addressed to recipient matching 'wildcard' to be copied to 'address'. This implies it is also delivered to whoever it would have gone to in the first place, including not delivering the message to any address other than the copy address or hitting a fallback address. Note: DSMTP will not deliver the message to the original recipient
if a forward rule exists for the same email address, i.e. DSMTP will
treat two rules,
Note: Also the original recipient may not get the message if there is a forward file for that user. For more information see the Forwarding and Aliasing section. Example: forward_cc sales@bob.com bofh@bob.com forward_on_from <wildcard> <address>
This setting is used to allow forwarding based on the senders address. forwardcc_on_from <wildcard> <address>
This setting i used to allow cabon copied forwarding based on the senders address.
This setting is used to establish an exception to relaying restrictions. If found,
DSMTP will allow the relaying of any messages where the domain in
the MAIL FROM line of the envelope matches <wildcard>
Notes:
If a non-local recipient is accepted because of a forward_from setting then DSMTP will log on info
log_level,
Example: To allow relaying ONLY from domains "below" local.domain, say
bob.local.domain put this line in dmail.conf
to allow relaying from local.domain AS WELL AS domains below it,
use this line instead,
because 'wildcard' is a simple string search.
This setting is used to establish exceptions to relaying restrictions. If this command
is present, DSMTP will not accept mail for non-local addresses unless
the sender's
ip number matches the <wildcard> parameter. If the forward_from_ip rule
specifies the sender, then they are allowed to
relay messages, i.e. DSMTP is
happy to try and send mail
to users at other machines for them.
Notes:
Example:
also to allow messages to be sent to users at other machines from your server, add
forward_from_and_ip <domain> <wildcard>
This setting allows users that have a email address that matches the domain in the setting
and are connecting from the specified ip to be allowed to relay
This setting activates relay permissions for recent DPOP users. If switch is set to true,
DPOP will keep a record of all recent logins ('recent' is defined by forward_window .
If a message's IP number and FROM envelope entry matches an entry in that record, relaying will be permitted
for that message. This allows users to read and send their mail from anywhere, while maintaining a
a server that is not an Open Relay.
If you have this setting set you should see in the dsmtp.log file (when on debug log_level) a line following every connection of
either,
Example: forward_user true
This setting tells DPOP how long to let records for
forward_user records to linger for in seconds.
The default is 120 seconds, or 2 minutes.
Example: forward_window 240 (sets the window to 4 minutes)
gateway <domain> <ip> [return domain]
This setting functions essentially as an instant DNS lookup. If the
next destination of a message matches <domain> and is not local,
DSMTP will not do a DNS lookup on the destination. Instead, it will use
the <ip> parameter (which must be of the form w.x.y.z).
This
can be used to handle fake domains, or force the message to take a particular
route. If, for instance, the host machine doesn't have access to the outside world,
it can send all non-local messages on to a machine that does. (The <ip>
parameter must not refer to the host machine. The setting host_domain
must be used instead.)
The optional [return] parameter, if present,
will be added to the messages reverse-path instead of the host machine's
name. Any bounce messages will then be sent via [return] This may
be used when the machine pointed to by <ip> knows the host machine
by some other name (that being what goes in the [return] parameter)
instead of the host machine's actual name (see host_domain
for information on how to set this).
The last applicable gateway setting
will be used. The <domain> parameter may include the
wildcard character '*'. Any number of these settings may be used.
In version 2.5g and above the <ip> parameter can actually be a
domain instead of the ip address. If DSMTP finds a domain destination then it does
a DNS lookup on this domain instead of the original domain. The domain may NOT refer
a local domain and if it refers to another gateway setting then that setting will be ignored.
Examples:
gateway fake.name 1.2.3.4
gateway * 1.2.3.4
gateway domain2.com 1.2.3.4 outside.com
When running multiple DPOP or DSMTP servers that access the same mail spool, it is necessary
to give each server a unique id for file-locking purposes. lock_id does this. <id>
can be any string, but for clarity, it should be a number to identify which server is using it.
Example: lock_id 02
Normally, DSMTP doesn't log every line sent or received via its TCP channels, as it can add
significant bulk to the logfiles. However, full logging can be turned on by setting <switch> to 'true'.
Example: log_data true
This setting tells DSMTP how many days worth of activity summary logfiles
to keep. These files are called dmxxyy.sta and dmxxyy.log, where xx is
the day and yy the month that the logfile is for. The sta files contain
message statistics (number received, sent, local, failed etc), the log
file contains lists of recipients and senders for all messages that day.
They are retained for accounting and security reasons, but can occupy quite
a lot of space if left alone. Any files older than <number> days
are deleted by DSMTP. The default is 14 days.
Example: log_days 8
DSMTPs logfile can get very large. Once they exceed <number> kb, DSMTP rotates out the old one
and starts a new one. The default value is 1024.
Example: max_loglen 2048
This setting tells DSMTP the maximum size a message is allowed to be
for DSMTP to accept it. This applies to all messages, not just those being
delivered locally. If an incoming message exceeds <number> kb,
any further data will be discarded. Once the message has finished, DSMTP
will notify both the sender and the recipient that the message could not
be delivered, with the first 20 lines from the body of the message appended.
The default is 2048 (that's 2 megabytes).
Example: max_msgsize 10240
This setting tells DSMTP the maximum number of recipients per message to log in
the daily summary logfile dmxxyy.log(see log_days .
If a significant portion of the messages going through DSMTP are mailing
list messages with several dozen recipients, the summary logfile can become
very large, as each recipient will be recorded for each message. max_others
caps the number of recorded recipients to <number> The
default is 20.
Example: max_others 100
One way to identify spam is that they often have a very large number of recipients per message.
To trap this, DSMTP can limit the number of recipients an individual message can have. Any further
RCPT lines will be refused. Be careful when using max_rcpts as legitimate mailing lists can often have
large recipient lists. By default, there is no limit.
Example: max_rcpts 200
This setting is like max_rcpts but it is per session instead of per message. A lot of spammers
will send in a lot of rcpt's but will then use a rset command and create a new message which
resets the counter on max_rcpts. This setting is per session so won't be reset so will foil
spammers using this method.
Example: max_rcpts_session 200
Sets the number of recipient lines from queue files that DMSTP
queues up in memory.
Default is 1000 - perfect for 99% of systems. This setting is available
in version 2.7k onwards.
NB: Do not play idly with this setting :-)
All messages that arrive at DSMTP's door get put in the work_path
directory as queue file (in pairs - q_x.itm being the message and q_x.idx
being an index of the envelope etc.). The way that DSMTP deals with these
messages is complex. This setting allows you to change how many of the
messages from the queue are stored in memory (the actual message is not
stored in the queue, just information on it). DSMTP does things like scanning
the internal queue reordering it, moving messages on and off it etc, so
a bigger queue does not necessarily lead to improved efficiency.
See also the queue file section, under Disk Use
and Files.
In version 2.7l we have made a considerable change to the efficiency of
DSMTP's queue. So if you are moving to this version or higher and you are
not running the default for this setting you should re-check its value is
correct for your system.
Example: max_queue 1000
This settting allows you to exempt specified ip's from being affected by the max_rcpts setting.
Example:
This setting sets the maximum number of Received: lines that can be in an incoming
message's headers before DSMTP bounces the message. Received headers are added
by SMTP servers when they receive a message, for this reason it is used to
check that the message has not ended up in a loop. A loop example is where you
have two SMTP servers forwarding the same message back and forth to each other.
By default
DSMTP rejects (bounces) messages with 15 Received: header lines. These days
SMTP servers can generally talk directly to one another, so
one or two received lines is normal.
This setting and its default were added in version 2.4e.
Example: max_rcvd 25
This setting tells DSMTP how long, in hours, it should continue to attempt
to send a message. If the message cannot be delivered after this time,
DSMTP will give up. The default is 24 hours.
DSMTP re-tries to send all queued messages every two hours by default. Example: max_retrytime 24
This setting sets maximum number of outgoing TCPIP channels, which limits
maximum simultaneous outgoing messages.
The default of 10 is normally adequate. The maximum value is 50.
NOTE: More outgoing channels does not necessarily lead to better
sending performance. This setting is provided to allow you to improve
performance for your setup, e.g. relays and servers with heavy mailing
list loads might require adjustment of this setting. We suggest that
you only increment this by
10 channels at a time and carefully monitor any effects.
Use tellsmtp showsend to see a
snapshot of the number of outgoing
channels in use. Tellsmtp showchans shows you all channels in use,
those in state 2 are sends. (those with the socket of -1 are no
longer in use).
Example: max_send 25
This sets the maximum number of outgoing channels that DSMTP will use for any particular domain.
This can be useful in preventing DSMTP from using all channels up on one domain.
Example:
This sets the maximum number of simultaneous channels that will be accepted by DSMTP from a single ip.
This obviously will stop DOS attacks where someone could open hundreds of connections to your server.
Example:
max_simultaneous_except <address>
This allows addresses to be exempted from the max_simultaneous setting.
Example:
This setting specifies the minimum amount of disk space DSMTP must have
to work. If the available disk space falls below <number> megabytes,
it will send an Email to the system administrator
alerting them to the problem, and then it will refuse all connections.
As soon as more disk space is made available, DSMTP will accept connections.
Because of this, it is important that the problem be addressed as soon
as possible. The default is 10, i.e. 10 Megabytes.
Example: min_space 5 message_process <executable> $FILE
This setting fires off the specified executable for every message that passes through the server.
$FILE is the macro that contains the actual message, you may edit the message as much as possible
and then your program can return an error code instructing DSMTP to either reject, accept or vanish
the message. You can choose what action to take based on the error codes using the setting message_process_action <return code> <action> [message to sender]
This setting sets what actions to take based on the error code returned by the program processing the messages,
This setting tells DSMTP which file to use for its message filters.
The file is a simple text file, containing any number of the following
types of entry, one per line:
For example, a text file filter.txt might look like:
The first line will cause DSMTP to reject any message with eschatology anywhere in the body.
Note: DSMTP does a different type of search depending on whether it is checking a message header
or the message body. Please see the notes below for specific differences.
White space is counted so the below examples are different If a message is rejected then DSMTP will give a message rejection
code at the end of the DATA stage of the SMTP protocol, i.e.,
Notes:
Example: msg_filter /etc/dsmtp_filter This allows addresses to be exempt from the max_msgsize setting.
You can specify addresses that match the senders address. If set to true, deactivates the auto adding of hosts to DSMTP's internal
host_domain list. Default is false.
DSMTP keeps an internal list of all host_domain entries that
DSMTP has read from dmail.conf. If DSMTP does a DNS MX lookup on a
domain and finds that the end
result points to itself (either IP address or domain) then it adds
the domain that it looked up to its internal list of host_domain
settings.
NB: it only adds Canonical or Primary names to its internal list. If the lookup
resulted in a secondary domain that pointed to itself, DSMTP would not add the domain to
its host_domain list and instead fail delivery and retry delivery later (hopefully when the
primary server has come back online).
For more information on this setting and its implications, please see Example: no_autohost true
no_dotforward <boolean> (UNIX based platforms only)
If set to true, deactivates DSMTP's default behaviour of looking
for a .forward file in the user's home directory as specified in
the /etc/passwd file. Instead DSMTP will look for a .fwd file in
the same directory as the user's drop file (including any directory
hashing). The default is FALSE. DSMTP has a method of creating forwarding rules where you create
a file called, drop_file_name.fwd in the same directory as a user's
drop file. To make DSMTP compatible with Sendmail systems, DSMTP
will normally check to see if a user has any forward rules
set up in a file called .forward in the user's home directory. DSMTP
finds the location of the user's home directory by using the system
call to retrieve that information from the /etc/passwd file. If the
administrator sets up a domain specific passwd file with the
domain_passwd setting, then
DSMTP will check that file for the user's home directory.
For more information on .forward and .fwd files see,
Forward Files in the 'Forwarding
and Aliasing' section.
Example: no_dotforward true The specified address/wildcard will be exempted from any quota restrictions.
Example: The specified IP address will be hidden by DSMTP in any Received
header lines that it creates. This option has been added so that DSMTP hides internal (made up) IP
addresses on a LAN when it is acting as the
gateway, so that they
are not visible to the outside world.
NOTE: The IP addresses will be hidden in ALL received header
lines, i.e. those added to BOTH incoming and
outgoing messages.
Example: hide_rcvd_ip 999.999.999.1
If set true, DSMTP will use a single line per message in the new format below for
its delivery message log.
Detailed statistics can then be found using the tellpop
statistics command.
The new format is also more convenient for creating your own script or program for parsing the
DSMTP delivery log.
NB: this setting was only added (and the tellpop statistics command) in version 2.9a.
DSMTP creates delivery logs in the log_path
directory, with the filename of the form,
The new syntax of the deliver lines is,
NB: we may add extra information to the line at any stage, hence the 'name value' style syntax. We
will try to only add to the end of the line.
Example: oneline_stats true
orbs_action <ban | reject | vanish>
If set, any of the listed actions causes DSMTP to lookup the ip address
of the incoming connection on the ORBS database. If the sender is found to
be from a listed site the specified action below is taken with the message.
Actions:
ban: causes the incoming connection to be dropped. DSMTP writes a message to
the channel informing the sender that they have 'no permission to talk'.
vanish: the incoming mail is accepted if otherwise ok but is then deleted
and is not recoverable.
reject: DSMTP will give 500 errors to all recipient lines.
NB: you may only specify ONE action
We have now added support for the MAPS RBL database which our customers
inform us is more reliable as it is a list of known spamming IPs rather
than just open relay sites. The setting for MAPS RBL lookups is,
You can set DSMTP to lookup incoming IP addresses on both databases,
however the action specified for the ORBS setting will occur if the IP
address is on both lists.
For more information on the ORBS database see,
Examples: orbs_action ban
orbs_action reject
orbs_action vanish
maps_action ban
maps_action reject
maps_action vanish
This setting tells DSMTP to send a minimal amount of output to stdout
(such as errors, and brief info on what it's up to). The information being
logged to the log file remains unchanged. The <switch> parameter
must be set to "true" to activate this option. The default setting is true.
Example: quiet true
ras_domain <domain>
(WINDOWS PLATFORMS ONLY)
Specifies a string containing the domain on which authentication
is to occur.
If left blank the domain in which the remote access server is a
member.
An asterisk specifies the domain stored in the RAS phonebook for
the entry.
It must be a full domain name. See the FAQ
for details on running a dialup mail server (NT only).
Example: ras_domain my.pet.domain
(it is recommended not to use this setting)
ras_entry <string>
(WINDOWS PLATFORMS ONLY)
The <string> parameter contains the name of the
dial-up entry in the RAS phonebook that DSMTP should use when
running in RAS mode.
Example: ras_entry My Connection
ras_number <number>
(WINDOWS PLATFORMS ONLY)
The <number> tells DSMTP which phone number to use when
dialing up in RAS mode. This should match the RAS phonebook entry.
Example: ras_number 5551234
ras_password <string>
(WINDOWS PLATFORMS ONLY)
If the RAS entry requires a password, it must be entered here. This
should match the RAS phonebook entry.
Example: ras_password mypassword
ras_smtpip <ip number>
(WINDOWS PLATFORMS ONLY)
Once DSMTP has established an RAS connection, it must contact an
SMTP server to retrieve messages that
are waiting for it. The <ip number> parameter tells DSMTP
where it is.
Example: ras_smtpip 1.2.3.4
ras_timeout <number>
(WINDOWS PLATFORMS ONLY)
After contacting the SMTP server given in
ras_smtpip messages will start arriving.
This
is because after opening up the connection to the remote SMTP server,
DSMTP sends the Extended SMTP command, ETRN domain, for all of the
domains specified in the host_domain and vdomain settings in dmail.conf.
The ETRN command causes the remote SMTP server to send all mail
waiting in its queue for the specified domain.
If DSMTP does not receive any messages for <number> minutes, it will hang up the RAS connection.
The default is 2 minutes. the minimum is 1 minute.
Example: ras_timeout 5
If using an RAS connection to get its mail, DSMTP will reconnect every <number> minutes. The default
is 30 minutes, the minimum is 5 minutes. It would be unwise to set this number to less than ras_timeout
as DSMTP would never hangup the connection. Which somewhat defeats the purpose.
Example: ras_timer 60
When establishing an RAS connection, a username is needed. This command tells DSMTP what that is.
Example: ras_username Simon Travaglia
Normally, DSMTP doesn't bother doing a reverse lookup on incoming connections,
as it can take time. However,
it is sometimes desirable to reject incoming mail from machines that fail a
reverse lookup. To do this, turn on reverse lookups and then set <switch>
to true.
NB: This setting will be ignored unless you have the
lookup_names setting set to
true.
Example: reject_no_reverse true
The relay_to setting permits unconditional relaying to a particular domain.
If DSMTP accepts a message for non-local delivery because of a relay_to setting it
will log,
Example: relay_to somewhere.com
This setting specifies how long DSMTP should wait between events before
alerting the system administrator of a recurring problem (see sysadmin .
DSMTP will not send an Email if the event occurs within <number>
seconds of the last one. This means that a frequently occurring problem
will only generate one error message. The default is 3600 (or one hour).
Example: remind_timeout 7200
retry_interval <time in minutes>
This setting tells DSMTP how often to retry sending messages in the queue that have
failed for some reason on past delivery attempts. It will keep trying at this interval
until max_retrytime is hit.
This setting tells DSMTP how long it ought to keep trying to send input
to a robot if it cannot send the whole message immediately. It will continue
to try to send the robot more data until <time> seconds have
elapsed since the last successful write. DSMTP will then give up trying
to send more data, but will wait until the time specified by robot_wait
before killing it. If the <time> parameter is larger than that
specified by robot_wait the robot
will be killed regardless of whether or not DSMTP was able to send the whole message to it.
The <time> parameter is in seconds, with the default being 120 (or 2 minutes).
Example: robot_try 10 When the write to the robot fails you will see a log line like,
'*** Warning *** robot 11631 choked on 77 bytes' in dsmtp.log. If the robot_try time is
reached then you will see a log line like, 'gave up trying to feed robot'.
This setting tells DSMTP how long to wait after sending the message
data to a robot before killing it. If the robot is still active after this
time, DSMTP assumes that it has either hung, or is stuck in a loop, and
terminates it. It can be set to any integer (negative numbers will have
the same effect as 0, i.e. the robot will be killed immediately). Because
there is no standard for robot implementation, they cannot be reliably
assumed to terminate under all circumstances, so there is no option to
switch off robot killing. The <time> parameter is in seconds,
with the default being 600 (or 10 minutes).
Example: robot_wait 10
DSMTP rotates it's logfile out once it reaches 1 megabyte in size. dsmtp.log is rename dsmtp1.log, dsmtp1.log is renamed
dsmtp2.log, and so on. The total number of logfiles kept can be set by using rotated_logs. The default value is 4.
Example: rotated_logs 10
Normally, DSMTP will run robots/autoresponder by directly forking and exec'ing the process. Sometimes this
doesn't work, or doesn't have the desired effect. It is possible to set shell_prefix to fix this.
If <string> is set to, say, "shell -c", DSMTP will run all autoresponders by forking, then exec'ing
shell -c "/usr/bin/whatever"
instead of
/usr/bin/whatever
Example: shell_prefix shell -c
If set to true, then DSMTP will advertise its 8 bit MIME
compatibility as part of the Extended SMTP welcome banner.
The default is false, i.e. do not advertise 8 bit MIME support.
When an email client or SMTP server opens up a connection to DSMTP,
it sends the SMTP command HELO. For Extended SMTP servers, like
DSMTP, it can send EHLO. In response to EHLO DSMTP sends a number
of lines to tell the client what its capabilities are, e.g. here are the
opening lines of an SMTP connection from the clients end,
If you want DSMTP to advertise 8 bit MIME as one of its
capabilities set show_8bitmime to true, then DSMTP will show its
8 bit MIME capability, e.g.
In versions prior to 2.5c DSMTP always advertised its 8 bit MIME
compatibility, but we think that 8 bit MIME is a strange thing :-) and
so DSMTP no longer does by default.
Note: If DSMTP advertises as 8 bit MIME and accepts a message
in that format, then it cannot pass the message on to a server or
client that is not 8 bit MIME compatible (e.g. if that server
only accepted 7 bit MIME messages), it will simply bounce the message
back to the sender.
Example: show_8bitmime true
show_ehlo [8bit],[vrfy],[auth]
DSMTP supports the ESMTP (Extended SMTP protocol) and as part of this
if a client connects with the EHLO command DSMTP must respond by advertising which
of the SMTP Extensions it supports.
The problem with this is that, if advertised, most clients tend to try to
use the latest and greatest things, even if they are not sensible. So this
setting is provided to allow you to decide what DSMTP advertises as its
capabilities.
DSMTP will always respond to EHLO with, ETRN,DSN and HELP, e.g.
This setting is a comma separated multi value setting which takes
any of the key words in the following table:
NB: this setting only affects what DSMTP advertises not whether it
supports each of the commands, e.g. whether you make DSMTP advertise VRFY or not,
what DSMTP does in response to the VRFY command is set with the setting,
fake_verify.
NB: If you have set,auth_allow relay, then you should not
need to set, show_ehlo auth, as DSMTP will automatically advertise support for AUTH PLAIN LOGIN.
See also show_8bitmime which this setting
can be used to replace.
Example: show_ehlo auth,vrfy,8bit
If used, this setting sets the port number which DSMTP will listen on
to port <number> Any SMTP clients wishing to talk
to DSMTP (including Tellsmtp) must use this port. Tellsmtp will look in
DSMTP's default config file unless told otherwise with a -i setting on
the command line, see the tellsmtp commands section.
The default value is 25, of course.
Example: smtp_port 1025
smtp_welcome <string[$HOST,$DATE,$QFILES]>
A template for the SMTP welcome line, given by DSMTP when it first opens a connection.
Warning - do not play with this setting unless you have a reason, and always
monitor your server for any effects after altering it.
The <string> can be a template that accepts the following macros:
$DATE = the day's datestamp.
$HOST = the hostname of the machine DSMTP is running on.
$QFILES = the number of files in the queue at this point in time (not normally used, added
by request for a customer's system where the sending device would distribute load based on this
information).
Accepts \\r\\n delimited lines, so that it can be a multiple line response although this is
not particularly recommended.
The default at time of writing this is,
NB:
Example: smtp_welcome 220 Welcome to ESMTP server, $HOST .
smtp_welcome 220 Welcome to ESMTP server, smtp.mymachine.com .
Activates a mail spooling directory for incoming mail.
DSMTP will deliver any mail found in this directory which is in a file with the ending, .msg.
If a message is written to file in this directory with the a filename ending in .msg,
DSMTP will open the file, parse it and try to deliver it to the destination given in the
message headers, namely the To: header.
The format of the .msg file should be a valid email message including headers, a separator blank line
and a message body, e.g.
NB: the address(es) MUST be enclosed in angle brackets.
Webservers with CDONTS:
This setting allows you to send messages with CDONTS from web pages. In version 2.9a we have
added checking for the CDONTS default file ending of .eml as well as .msg files.
Time delayed delivery:
If a message file name starts with a digit then DSMTP will try to work out a time setting from the
file name. If it can then it will wait until that time (to the nearest 5 minutes) and then deliver the message.
If DSMTP can not work out the time setting it will deliver it immediately.
The format is,
E.g. 2000310813.msg DSMTP will try to deliver this message within 10 minutes of 1 PM, on the 31
August in the year 2000.
Notes:
Example: spool_dir c:\dmail\spool_dir
This will stop DSMTP sending any messages to the specified domain until an ETRN is received for that domain.
Example:
suspend_domain test.com
See also suspend_domain_timeout
suspend_domain_timeout <time in minutes>
This will bounce messages being suspended for domains once the time has been reached
Example:
suspend_domain_timeout 720
See also suspend_domain
This setting tells DSMTP who to contact if something terrible happens.
Currently, those things are:
When DSMTP detects a mail-bomb incident
When DSMTP runs out of disk space (as specified by the min_space setting)
Also DSMTP automatically creates an alias for postmaster to this address (the postmaster
alias is case insensitive and currently covers all domains).
It is highly recommended that this setting be included. Especially in the
case of a disk full error, when DSMTP will cease to accept any incoming
connections, it is most important that the problem be attended to. There
is no default value.
This setting covers all domains and is not by default alterable by domain administrators.
Example: sysadmin littlegreenman@area51.mil
This setting specifies the number of RCPT TO: lines at which DSMTP starts
responding ever slower to further RCPT TO: lines in the SMTP protocol.
So if it is set to 7, for example, then when an SMTP session
commences, DSMTP counts the RCPT TO: lines that the sender (i.e.
an email client or another SMTP server) sends. On the 7th Rcpt To:
line DSMTP will do the lookup on the email address, but then delay its
response to the sender (e.g. 250 Rcpt User OK) by 1 second. After 3 more
Rcpt To: lines it will delay each response by 2 seconds. Every further
4 lines received it will increase the delay by another second up to a
maximum of 15 seconds.
This setting is an anti spam measure that
is independent to the
max_rcpts setting, but is intended to be used
in conjunction with it. The slowing of the response is likened to
being stuck in a tar pit, hence 'tarpit'. This is designed to be
annoying to spamming robots as it clogs them up. If you simply reject
a connection then it does not bother a spamming robot, but if you can
slow it down then that should make your server less desirable as a
spamming target.
This setting is not included by default, i.e. there is no point
at which DSMTP responds deliberately slowly.
The setting tarpit_except is provided
so that you can specify servers that should be an exception to this
setting.
Example: tarpit_start 5
This setting specifies any IP addresses which should never receive
a deliberately slow response from DSMTP, even if the number of recipients
in the session exceeds the tarpit_start setting.
This setting can take a comma separated list of IP addresses, and
wildcard entries.
Example: tarpit_except 1.2.3.4, 161.29.2.*
Specifies the maximum number of TCPIP channels that DSMTP listens on. This
is the equivalent of DPOP's max_sessions setting. The default is 200 channels, or
200 concurrent incoming connections.
This setting specifies how long DSMTP should wait for a response on
a TCP/IP port before giving up. This only applies when DSMTP is actually
expecting data. Once <number> seconds have elapsed, DSMTP closes
the channel and discards the half-complete message (if receiving), or queues
it for another try (if sending). The default value is 300 (or five
minutes).
NB: Setting <number> to something
small could have unpredictable results. Be sure that you set this setting
longer than your authent_timeout setting!
DPOP has the equivalent setting, pop_timeout.
Example: tcp_timeout 120
On NT, the _timezone variable gives unreliable results. If the timezone command is present, DSMTP
will insert the <string> parameter where appropriate. i.e. In date fields:
Fri, 19 Jun 1998 02:03:30 <string>
Example: timezone +1200 NZD
This setting tells DSMTP if it should use strictly case sensitive user lookups
for unix_user authentication. Normally, if DSMTP fails to find a user,
it searches again for a case insensitive match. If only one is found,
it uses that, otherwise it fails. Setting <switch> to 'true' will disable
this feature.
Example: unix_case true
This setting activates mailbox quotas. For each user, there should exist a file called <username>_inf. In
this file should be a line 'quota <number>', where number is the
user's quota (in bytes). It is up to the system administrator to
maintain the quota line in these files.
DPOP will maintain the 'used' line,
and DSMTP will not allow mail to be delivered to a dropfile whose
'used' bytes is greater than 'quota'. This setting should
be used in conjunction with drop_max
Note: If there is no 'quota' setting in a user's _inf file then,
DSMTP will not impose a quota restriction on that user.
The user quota setting has been extended in Versions 2.4i and above to take a numerical value instead of
the 'true' setting. The value specified is a default quota (in kbytes) for users who have no 'quota' line
in their username_inf file. E.g.
Examples:
user_quota true
user_quota false
user_quota 90 (ONLY valid in versions 2.4i and above)
virtual_user_post <filename>
virtual_user_post: Adds a sendmail style virtual user table, actioned immediately before lookup.
virtual_user_pre: Adds a sendmail style virtual user table, actioned before any other local-user rules apply.
Both of these settings allow you to specify a file in which you provide aliases for user database names. In
sendmail this is the common way to add virtual domains.
We have added support for such a file to help with conversion to DMail. However we strongly recommend
that you move to our 'vdomain' style virtual domains so that you can take advantage of the features that
they offer now, and will offer in the future. We of course always continue to support these settings
so you do not have to change.
The difference between 'post' and 'pre' is when DSMTP looks up a user in these files. The 'pre' file
is used as soon as DSMTP gets a RCPT TO: line, before any other checks for mail redirection, including
the forward settings and alias files. Whereas the 'post' file is only checked just before the
user database lookup, after all other mail
redirection.
This means that if a message is addressed to bob and a lookup of the 'pre' file
results in that being an alias for the user, 1234, then DSMTP will forget about 'bob' and only look for
dmail.conf settings (including in alias files) for user '1234'. '1234' is also the username it will
lookup in the authentication module. Whereas if that same alias was in the 'post' file you could add
forward and alias settings for user 'bob' and still have his database 'username' of '1234'.
NB: the virtual_user_post file will only be looked at if the incoming message is for a local user, so this
means that if you have,
The pre and post files have the same syntax of one 'rule' per line of the form,
<source><tab><destination>
The following are example syntaxes, along with effective changes to recipient addresses for each one:
NB: DSMTP offers all of the functionality of the virtual_user file with its other settings, see,
NB: Syntax 4 is also possible with forward settings in versions
2.8m and above, e.g.,
This setting activates DSMTP's virus scanning, it is far superior to the external_viruschecker setting.
It is designed specially for use with RAV DMail. You simply specify where the rav dmail daemon is located.
Example:
For more infomation on this please check DMail's Anti-virus capabilties
This setting tells DSMTP when to alert the sender of a message that
it is having trouble delivering the message. The <number> parameter
is in retries, which occur every 2 hours. If the <number> parameter is larger than max_retry,
DSMTP will only notify the user if it completely failed to deliver the
message. The default value is 4 (which means the user will be alerted after
roughly 8 hours). Delay warnings must be explicitly requested by the user by using the NOTIFY=DELAY
ESMTP extension.
Example: warn_user 5 This setting allows all checking of forwarding files to be turned off, so that
DSMTP will not check for .fwd or .forward files.
The default is true.
For more information see,
Example: use_forward_files false
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.
|