| Configuration
Parameters
Configuration
parameters for the MTA are described below:
-
service.smtp.smtp-accept.minruncount
This
limits the number of SMTP sessions being serviced at any one time. Like
the other services, when the server is busy it will accept the TCP connection
but nothing happens until resources are free. Unlike POP/IMAP, the 4.0x
SMTP daemon cannot share X worker threads among more than the same number
of X active sessions; it uses one thread per session. This behavior is
changed in 4.1x, which shares these threads among multiple SMTP sessions.
Even in
4.1x, the SMTP daemon still does not have a maxsessions parameter;
it will plex these threads among as many SMTP sessions as it can.
The default
for this parameter is 32. For 4.0x, this parameter directly controls
the number of active SMTP sessions that can be serviced at one time and
that can be safely tuned up to several hundred threads. With the new SMTP
thread model in 4.1x, this parameter should be left alone in most cases.
-
service.smtp.account-handler.minruncount
service.smtp.smtp-router.minruncount
service.smtp.autoreply-handler.minruncount
service.smtp.error-handler.minruncount
service.smtp.smtp-deliver.minruncount
service.smtp.prog-deliver.minruncount
service.smtp.unix-deliver.minruncount
service.smtp.mailbox-deliver.minruncount
The semantics
of these parameters are similar to service.smtp.smtp-accept.minruncount
but apply to their respective SMTP daemon modules. In most cases, the default
values are fine. When increasing the value of any of these parameters,
you should exercise the same care as in selecting reasonable values for
IMAP/POP/HTTP servers (see the Protocol Tuning Information
section). For example, multiplying all the defaults by 10 would not be
resonable, but doubling the number of program-deliver threads on a machine
that runs a program delivery mail list manager should be fine.
-
service.smtp.smtp-accept.log
service.smtp.account-handler.log
service.smtp.autoreply-handler.log
service.smtp.error-handler.log
service.smtp.mailbox-deliver.log
service.smtp.smtp-deliver.log
service.smtp.prog-deliver.log
service.smtp.unix-deliver.log
service.smtp.smtp-router.log
These parameters
turn on or off the logging for each MTA module. The following parameters
default to on (yes) if not set:
service.smtp.smtp-accept.log
service.smtp.error-handler.log
service.smtp.smtp-deliver.log
The following
parameters default to off (no) if not set:
service.smtp.account-handler.log
service.smtp.autoreply-handler.log
service.smtp.mailbox-deliver.log
service.smtp.prog-deliver.log
service.smtp.unix-deliver.log
service.smtp.smtp-router.log
-
service.smtp.domainlangtable
This
parameter should be changed from its 4.01 default value. A bug was uncovered
in certain versions of our internationalization libraries that leaves the
SMTP daemon vulnerable to core dumps when certain foreign language messages
are sent to the server. Changing this value does not wholly eliminate the
problem, but it reduces the number of cases in which this problem could
occur.
Our recommended
value specifies a language table that only includes languages for which
Netscape has resource bundles:
This problem
is fixed in version 4.15.
The meaning
of this parameter is that each line in service.smtp.domainlangtable
consists of:
-
country/domain
language-list
country/domain
is either a country 'ending' (e.g. us=USA, be=Belgium,... or netscape.com.jp
for a Netscape group based in Japan). In this way you can set language
defaults for a whole country or even a particular domain in a country (e.g.
if everyone in netscape.com.jp spoke English, replies to it would
override the Japanese language default for the country).
language-list
is an ordered list of languages separated by commas or pipes (|).
Currently the ,'s and |'s have the exact same meaning.
(We were intending to have the |'s be used when you want to display
more than one language (e.g. for a reply to Canada send both English and
French), but that never go into the product.) To make your life simpler,
it's probably best to just use commas everywhere until functionality changes.
The meaning
of a line like:
would be (if
|'s were handled):
For mail
from the domain of Belgium, send a reply in both Belgian-French and Belgian-Dutch
(=Flemish?). If neither of those are available, then send reply in both
French and Dutch.
Since |'s
are not handled, this is actually equivalant to:
which means:
Send reply
to Belgians in (first available language of): Belgian-French, Belgian-Dutch,
French, Dutch. (If none of the above are available then the universal default
is English).
-
service.smtp.smtp-router.smtprewritestyle
This
parameter controls how the MTA rewrites some of the RFC822 message header
fields. Doing header rewrites slows SMTP down a bit.
The From:,
To: and CC: lines are rewritten. The overhead is an additional
LDAP lookup on the From: address. The To: and CC:
addresses should already be cached and no additional lookup is required.
The default
value for this parameter is quoted. A value of never
turns the header rewriting off.
-
service.smtp.ldappoolsize
LDAP
connections are pooled in the Messaging Server 4.x. The pool of LDAP resources
is shared among all the threads of a given messaging server process. These
connections are not shared across separate processes.
This parameter
controls not only the size of the SMTP LDAP pool, but also specifies the
default size of the LDAP pool used by other messaging server processes.
Since there is no way to change the LDAP pool size for other processes,
this effectively sets the pool size for all messaging server processes.
The default for this parameter is 32, which should be adequate
in most cases.
Decreasing
the value of this parameter may actually help performance in some situations,
particularly if you have many IMAP/POP/HTTP daemons since you will be swapping
LDAP with too many total connections. However, care should be taken when
dropping this number to avoid introducing contention for the LDAP connection
among the other working threads. Dropping this value below 8 in most cases
is not recommended. Increasing this value by a large amount is usually
just a waste of resources.
-
service.smtp.smtp-accept.maxmessagesize
This
parameter is coded to work only if the SIZE extension in service.smtp.smtp-accept.allowsize
has been turned on by the administrator.
-
service.smtp.smtp-deliver.timeoutgreet
This
parameter is the timeout in seconds when waiting for a response when the
local MTA contacts a remote MTA.
-
service.smtp.*.maxruncount
None
of the maxruncount options are used.
-
local.service.smtp.smtp-router.addresentfrom
In
Messaging Server 4.15 Patch 1, this parameter is now available to suppress
the addition of the Resent-From: header on list expansion. Setting
the parameter to no prevents the header from being added. Setting
it to yes adds Resent-From: on list expansion.
By default,
this value is not set; and works as if set to yes.
-
service.smtp.smtp-router.dorewritefromusingauth
service.smtp.smtp-router.dorewritesenderusingauth
These parameters
will rewrite the From: and Sender: headers with the information
from the authentication session.
-
service.smtp.smtp-accept.timeoutcommand
service.smtp.smtp-accept.timeoutdata
These parameters
help make sure that connections that are not used and not closed get closed
after a certain amount of time.
By default,
these parameters are set to 600 seconds (10 minutes). If users are sending
large attachments over slow dialup lines, you may need to modify these
to avoid connections waiting for threads.
-
service.smtp.prog-deliver.defaultuid
service.smtp.prog-deliver.defaultgid
This is
the user and group IDs used for program delivery. By default these values
are 1, which often corresponds to the daemon use and
other group in your local /etc/passwd file.
-
service.smtp.error-handler.hopcountexceedactions
service.smtp.error-handler.quotaexceedactions
service.smtp.error-handler.unknownactions
These parameters
describe the error handling when the MTA hop count is exceeded, quota is
exceeded, or something unknown happens. These values are numeric sums of
the following actions:
-
1
Reply to Sender
-
2
Hold (not used in 4.x)
-
4
Notify Postmaster
-
8
Log
So that if
you define the value 14 as service.smtp.error-handler.hopcountexceedactions,
it will treat a hop count exceeded as Hold (not used in 4.x),
Notify Postmaster, and Log.
-
service.smtp.smtp-deliver.checkdeferredqueue
When
set to yes, this parameter instructs the MTA to determine if there
are messages in the queue waiting to be sent to a particular domain. If
so, new messages to the domain are also queued, awaiting the next attempt
to connect and send.
Throttling
SMTP Accepts
Messaging
Server 4.x provides two additional ways to stop denial of service attacks
along with plugins and filters:
-
Any one connection
cannot send more than 1000 mail messages
-
Once the control
queue is over 2000 messages, the server starts to throttle back the speed
with which it accepts incoming connections.
These mechanisms
make it more difficult to grow the queue to massive proportions.
To throttle
SMTP accepts, configure the following parameters:
-
local.service.smtp.smtp-accept.maxrecipients
Netscape
Messaging Server 4.04 and later allows the administrator to tune the maximum
number of recipients of a message. Care should be taken to modify this
values because ISPs and other systems receiving mailing lists may need
to accept a large number of recipients in each mail.
The default
value is 100000.
-
local.service.smtp.smtp-accept.maxmessages
This
is the maximum number of messages per SMTP session; the default value is
1000.
You may also
modify the queue throttle value:
-
local.service.smtp.throttlethreshold
Messaging
4.05 Patch 1, 4.1 Patch 2 and 4.15 Patch 1 allow the administrator to tune
the level at which the throttling occurs. Care must be taken because if
the throttle level is set too high, the accept rate will overwhelm the
ability over the server to deliver all the messages it accepts.
There is
no parameter default value; the internal value is 2000.
Configuring
the Postmaster
The MTA will fail to start if it doesn't find a postmaster
account, nor will it start if it finds more than one postmaster account.
More information is available from http://help.netscape.com/kb/corporate/19990216-3.html.
Routing
Multiple Recipients
The SMTP
routing is done after the envelope of the message has been split on recipient
domains. This means that if you route all mail with one routing rule in
a routing table:
*:smtp.otherdomain
and send a
message to user1@mydomain and userX@yourdomain, then
the server sends two messages to smtp.otherdomain: one for user1
and one for userX.
This is
probably not efficient if you have a hub or router machine that handles
all outgoing mail.
Caching
LDAP Queries
Each time
an LDAP query is made (on message senders and recipients), the entry info
is kept; it is 'tagged' by the search that retrieved the entry (could be
either recipient address or UID). This information is kept in memory, roughly
tracking the Control information for the message (stored separately, but
linked) and removed when the message is delivered or dropped.
Theoretically,
this keeps us to one LDAP entry per recipient per message; and most of
the time this is the way it works out.
Note:
The LDAP information between messages is not cached; it is assumed that
there is little chance of random messages containing the same recipients.
DNS
Caching
For performance
reasons, the MTA caches DNS entries. The following describes the impact
and process of the caching.
-
The MTA randomizes
MX hosts at the same preference. If an MX host at a higher preference goes
down it gets removed from the cached list and it re-enters the cache only
when the domain gets looked up again; that happens when TTL for that domain
is up.
-
The code which
does MX lookup always tries the nameservers in the order in resolv.conf.
It does not remember if the first nameserver timed out from last time.
-
If there is
no MX record for the host and we lookup the A record for that domain, then
the behavior is to try the servers listed in resolv.conf in order.
If no response is received from a server, it's demoted (placed last in
an internal list constructed from the list in resolv.conf). A
server cannot be promoted except by having its superiors demoted, which
means a demotion is permanent unless the MTA is refreshed (the MTA doesn't
yet support this in 4.x), or the secondary (or tertiary) server stops responding.
More DNS information
can be found at: http://docs.iplanet.com/docs/manuals/messaging/nms41/ag/routing.htm
Turning
DNS Caching off
Starting
with Messaging Server 4.1 Patch 2 and 4.15 Patch 1, DNS caching by the
MTA can be turned off if you wish to have more control over the DNS behavior.
The following
configuration setting will turn off DNS caching in the MTA:
configutil
-o service.smtp.dnscachesize -v -1
A message
will appear in the smtp log stating that DNS caching has been disabled:
[28/Feb/2000:10:00:00
-0800] system smtpd[10000]: General Notice: DNS cache is disabled
MTA
Relays
Customer
experience shows that the following should improve performance on outbound
SMTP servers. They usually build up to large SMTP Deliver queues causing
the server to stop accepting incoming connections. Specifically, the lower
setting for smtp-deliver.timeoutgreet and higher setting for smtp-deliver.minruncount
are important.
configutil
-o service.http.enable -v no
configutil
-o service.imap.enable -v no
configutil
-o service.pop.enable -v no
configutil
-o service.ldapmemcache -v no
configutil
-o service.smtp.smtp-deliver.minruncount -v 130
configutil
-o service.smtp.smtp-accept.minruncount -v 140
configutil
-o service.smtp.smtp-router.minruncount -v 50
configutil
-o service.smtp.smtp-deliver.timeoutgreet -v 30
configutil
-o service.smtp.account-handler.minruncount -v 40
configutil
-o service.smtp.error-handler.minruncount -v 3
configutil
-o service.smtp.mailbox-deliver.minruncount -v 1
configutil
-o service.smtp.unix-deliver.minruncount -v 1
configutil
-o service.smtp.prog-deliver.minruncount -v 1
configutil
-o service.smtp.autoreply-handler.minruncount -v 1
setconf
local.dbtxnsync 1
You may also
want to tune the following based on the expected output usage:
setconf
local.service.smtp.smtp-accept.maxrecipients 250
MTA
Fallback Host
Starting
with Messaging Server 4.15 Patch 1, you can create a fallback host ("host
of last resort") so that if you timeout connections on all of the remote
MTAs, you can route messages to a fallback MTA; for example a local MTA
that acts as an offline deferred queue.
The following
configuration setting will enable a fallback host for the MTA:
service.smtp.smtp-deliver.fallbackhosts
is a $ separated list of x:y where x is a pseudo
regular expression specifying domain and y is a host (name or
IP address). If y has multiple IP addresses, they'll all be tried.
The y IP addresses are treated as if they are the lowest priority
MXs by the nameserver.
If the
real MXs for the domain are all dead, these pseudo-MX IP addresses
will float to the top and stay there for the duration of TTL (typically).
Trivial
case of *:<host> forwards all deferred mail to <host>.
Turning
off LDAP lookups
Beginning
with Messaging Server 4.15 Patch 1, the ability to turn off LDAP lookups
for outbound-only relays is available through the following configuration
parameter:
Queueing
Behavior
In Messaging
Server 4.1, the queue handling is designed using a structure based on a
directory containing control files and auxiliary directories containing
the body of the messages.
The idea
is to use status attributes in the control files holding information about:
-
last time
a message attempt was made for delivery
-
sender
-
recipient
-
sender mailhost
-
remote mail
server
-
... and so
on ...
Thus, an envelope
is a holder of control information, which allow us to track the messages
on their way out to the remote system.
The queue
reporting tool, mailq, performs a count of the number of envelope
files in the control directory for a deferred domain and displays that
information to the user.
Differences
between 4.0x and 4.1x Queueing Behavior
The organization
of the deferred directory for SMTP delivery has been changed between 4.0x
and 4.1x. Multi-level hash directories have been employed to fan-out domains
and message files under queue/deferred/SMTP-Deliver. The hash
directories are two levels deep, and is computed for domainname
and also for the message files. The hashdir utility can be used
to find the hash values.
The deferred
queue for the domain netscape.com in 4.0 was queue/deferred/SMTP-Deliver/netscape.com/env-XXX.
The 4.1 deferred queue is queue/deferred/SMTP-Deliver/xx/yy/netscape.com/env-XXX,
where xx and yy is the hash value computed over netscape.com.
Additionally,
in 4.0x when a message was deferred the message file was left in the /messages
directory, and only the envelope file was moved to the deferred directory.
In 4.1, the message file is now also moved to deferred directory. Ie. queue/deferred/SMTP-Deliver/xx/yy/netscape.com/aa/bb/XXXXXXXX.XXX,
where XXXXXXXX.XXX is the message file.
This was
changed to minimize the number of files in the messages directory.
Queue
Processing when the MTA is Started
On start
up, the MTA will attempt a sanity check between contents of the files in
the queue/control/env-XXX and the files under queue/messages.
In 4.0x,
since we're leaving the message files for deferred messages in the queue/messages
directory, a situation could arise where one ended up with many tens of
thousands of files in the queue/messages directory (say if a site
like hotmail.com is down). This considerably slows down the checking
performed by the server at start up. To prevent this situation from occurring
the deferred messages are no longer kept in the queue/messages
directory.
In 4.1x,
since we move deferred message files to their own directory under queue/deferred/SMTP-Deliver,
and also since the default throttle limit for the server is 2000, we should
rarely, if ever, end up with a situation where there are 20,000 message
files in the messages directory.
It is conceivable
that this processing could be done in the background, but this is not the
way 4.x has been architected. Also it is questionable to start the MTA
without doing a sanity check first.
Note: The
deferred queue is not processed on start up.
Mail
Headers
If a message
is received with only one (envelope) recipient, then the MTA will put the
recipient address into the Received: header. For multiple recipients,
it adds no extra information.
For example,
the following is what you may see for a single recipient:
Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA])
by anotherserver.yourdomain (Netscape Messaging Server X.Y)
with ESMTP id AAA5555 for <user1@testenv.yourdomain>;
Fri, 14 Jan 2000 15:00:00 -0700
while for
multiple recipients, you would see:
Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA])
by anotherserver.yourdomain (Netscape Messaging Server X.Y)
with ESMTP id AAA5555; Fri, 14 Jan 2000 15:00:00 -0700
Language
criteria for Replies
The Messaging
Server uses the following criteria for determining the language of replies:
-
Does message
have a Prefer-Language: or X-Accept-Language: header
(the later is used by Communicator 4.x I believe). If so, try to use the
language specified in that header.
-
Is recipient
in our Directory, and if so do they have a preferredLanguage attribute.
-
What is the
domain of the sender? (e.g. blah@domain.kr is by domain definition
Korean, so we'd use Korean in the reply). This is editable (see service.smtp.domainlangtable)
so you can specify desired languages for countries and even individual
domains.
-
If none of
the above 'click' then we fall back to English.
sendmail
utility
The sendmail
utility is a fixed command located at /usr/lib/sendmail which
is part of the Messaging Server. Since multiple instances of the Messaging
Server can be installed, but only one of /usr/lib/sendmail, this
causes issues with which sendmail utility to use.
Starting
with Messaging Server 4.05 Patch 1, 4.1 Patch 2 and 4.15 Patch 1, the following
configuration parameters are now available for use by the sendmail
utility:
local.service.sendmail.port
local.service.sendmail.listenaddr
The sendmail
utility now does the following when looking up its listen address and port
number:
-
looks for
the local.service.sendmail.port config value
-
if not set,
looks for service.smtp.port config value
-
if not set,
looks for the smtp/tcp service port number
-
if not set,
uses 25
-
looks for
the local.service.sendmail.listenaddr config value
-
if not set,
looks for the service.listenaddr config value
-
if not set,
uses localhost
Thus with
multiple instances of the Messaging Server, different listen addresses
and ports can be specified each time sendmail is run. |
Platform
Tuning Information