Note to self -- add something about LDAP_USE_ASYNC
If you are using Direct LDAP lookups instead of Dirsync then you can also set this variable to a value that maps to a memory mapped file system, like /tmp/. The location must exist prior to starting up the MTA, i.e. the MTA will not create this directory if it is not present. I often use simply /tmp/.Please note that this can not be set to the same location as Section 6.3
Set this parameter to a value that maps to a memory mapped file system, like /tmp/. Channels such as the conversion channel place files in this directory. The location must exist prior to starting up the MTA, i.e. the MTA will not create this directory if it is not present. I often use simply /tmp/. Please note that this can not be set to the same location as Section 6.3
If you wish, you can set the IMTA_TCP_FLAG_RETENTION option in your imta_tailor file to, say 1, so that the old *.data-failed files get purged after a day. You can find these files in msg-<instance>/imta/ queue/<channel-name>/spool/. Note -- this directory will only exist if the MTA needed to write files to this directory. Many sites will never see this directory on their systems.
If you are using the conversion channel to perform anti-virus checking, in addition to the other things in this document, you should know about the following software.
The original links I had are now gone. The best I can do right now is a search for
vanja & sophie and vanja & trophie. I have not used these myself, but I have heard good things from people who have.
If you're using Direct LDAP lookups the following parameters should be set in option.dat:
Note: If you're using iMS 5.2 or later then YOU SHOULD BE USING Direct LDAP, instead of Dirsync!
To get the maximum gain from DirectLDAP Mode, you should also look at adjusting MAX_LIFE_CONNS see Section 8.1 for more information.
ALIAS_ENTRY_CACHE_SIZE -- this is the maximum number of entries held in the cache. The default value is 1000. Each cache entry is about 2K.
ALIAS_ENTRY_CACHE_TIMEOUT -- this is the maximum length of time, in seconds, an entry is held in cache, the default value =1200
ALIAS_ENTRY_CACHE_NEGATIVE -- controls if alias match failures are cached. The default action is not to cache failures. This speeds up the activation of new users.
DOMAIN_MATCH_CACHE_SIZE=50
DOMAIN_MATCH_CACHE_TIMEOUT=60000
You want to allow enough connections to support your load, while not allowing enough concurrent connections that your system is not able to respond quickly, thus preventing a DOS attack. The max concurrency number is equal to MAX_PROCS * MAX_CONNS, defaults are 10 and 20 respectively.
Once you know the max concurrency rate for your given configuration this will help you determine the number of systems required to support the load at your site.
MAX_LIFE_CONNS should be adjusted if you are using Direct LDAP Mode, every site should be using Direct LDAP Mode, if at all possible. This should be at least twice, and probably four times ALIAS_ENTRY_CACHE_SIZE , to take advantage of the cache. See Section 8.11
To find an optimum value for MAX_HANDOFFS (Check here) (default value is 5), you need to figure out how long it takes for a connection to be ACCEPTED (you can look in Dispatcher debug logs for that), and then estimate how many connections you expect the Dispatcher to receive during that time period. If the time between the connection coming into the Dispatcher and being ACCEPTED by the worker process is 0.5 seconds, and the system should be able to handle 30 connections/second, then MAX_HANDOFFS would need to be set to at least 15 (30 conns/second * 0.5 seconds).
There are two files that you need to be concerned with, imta.cnf and job_controller.cnf. In job_controller.cnf you define the pools and the maximum number of jobs that can be run at a given time in those pools. In the imta.cnf file you define what pool a channel uses and the maximum number of processes the channel can run in that pool at a given time.
In large deployments machines are dedicated to a specific role. On a MTA-IN machine one would configure more jobs to the tcp_intranet channel and thus deliver mail faster to your mail stores.
In large sites they may wish to adjust MAX_MESSAGES. The Job Controller keeps information about messages in an in-memory structure. In the event that a large backlog builds, it may need to limit the size of this structure. If the number of messages in the backlog exceeds the parameter specified here, information about subsequent messages is not kept in memory. This parameter is set in the global section of the job_controller.cnf file, this variable is not present by default. The default value is 100000. For an in depth explanation about MAX_MESSAGSES see my personal website, http://ims.balius.com/ and look for the topic max messages.
The default value for notices in iMS is '1 2 4 7'. In large deployments you may want to reduce these defaults.
The default for Delivery Status Notifications (DSNs) for postmaster are copywarnpost and copysendpost. In large deployments or environments where the postmaster does not want to get DSNs about users mail, then these keywords should be changed. See the Sun ONE Messaging Server documentation for a complete explanation of the values. (The possible keywords are XYZwarnpost and XYZsendpost, where XYZ is either copy, no, warn, or err.)
If the mail store is handling lots of mailboxes and messages per second then you may want to increase the number of ims_master processes that job_controller will start to process the ims-ms queue. To increase the number of processes you need to make two changes, one in the imta.cnf file and the other in the job_controller.cnf file. In the imta.cnf file you need to change the maxjobs keyword, in the job_controller.cnf file you need to adjust the job_limit for the IMS_POOL.
This setting controls how much memory the SMTP server uses to store a message before it creates files in Section 8.5.3. If you have enough memory in your server then you might consider setting this variable to a value that allows the MTA to store your average message size or more in memory
If the MTA does not need to rewrite backward pointing addresses then you can set USE_REVERSE_DATABASE=0 in option.dat. I have in the past set this parameter while trying to get every last milisecond of performance out of an MTA. Most ISPs will not require the MTAs to rewrite backward pointing addresses.
To prevent DOS attacks and protect overall system health, the following parameters should be enabled in the msg-<instance>/imta/config/tcp_local_option and also msg-/imta/config/tcp_intranet_option files. (They do not exist by default.)
!
!
DISABLE_ADDRESS=1
DISABLE_CIRCUIT=1
DISABLE_EXPAND=1
DISABLE_GENERAL=1
DISABLE_STATUS=1
HIDE_VERIFY=1
!ALLOW_RECIPIENTS_PER_TRANSACTION=
!ALLOW_REJECTIONS_BEFORE_DEFERRAL=
The last two parameters should be set according to site policy. I am listing them here so you know they exist, check the reference guide for more options.