CHAPTER 4 |
Documentation Changes |
This chapter describes any updates or changes to the SIMS 4.0 FCS documentation.
Note - Go to http://sun.com/sims/ for updated release notes and other product information concerning the Sun Internet Mail Server (SIMS) 4.0.
This section describes any changes or updates to the SIMS 4.0 Installation Guide.
The SIMS 4.0 Installation Guide (Step 2 of "Installing Netscape Directory Services 4.1" of Appendix A) currently refers to the NSDS package as if it was located on the SIMS 4.0 CD. The instructions state "Insert the SIMS CD-ROM into the disk drive."
NSDS is delivered on a separate CD in the SIMS packaging and information about the most current version can be found on the following at http://sun.com/sims/tech-info/nsds.jhtml.
Three errors exist in Appendix B "Installing Netscape Directory Services for SIMS High Availability":
| 1. | Step 2 of "Setting up the Netscape Directory Services Administration Server for SIMS/HA" of Appendix B contains an error. It reads: |
The logical address should be:
| 2. | Step 6 of "Guidelines for Installing and Configuring Sun Cluster and High Availability" of Appendix B contains an error. It reads: "You now need to edit the nsldap_svc_stop script on both nodes." |
| The instruction should read: "You now need to edit the /opt/SUNWcluster/ha/nsldap/nsldap_svc_stop script on both nodes." |
| 3. | Step 5 of "Registering the Netscape Directory Service with the High Availability Framework" of Appendix B contains an error. It reads:
|
"pv" should be -v. The command should be:
|
This section describes any changes or updates to the SIMS 4.0 Administrator's Guide.
The following section should be added to Page 232 under IMTA Maintenance:
SIMS IMTA log files must be periodically examined and purged or they will continue to grow and fill up your disk. The IMTA log files are located in /var/opt/SUNWmail/imta/log.
This section describes any changes or updates to the SIMS 4.0 Reference Manual.
The backup-groups.cnf configuration file is not documented in the SIMS 4.0 Reference Manual. The backup-groups.cnf file contains definitions for the SIMS Message Store backup groups. The group definitions are used by the message store utilities imbackup and mkbackupdir to back up users by group. See the UNIX man page (backup-groups.cnf(4)) for more information on this configuration file.
In Chapter 4, "SIMS Configuration Files," references to the spmProgramNumber parameter in the sims.cnf(4) file should be ignored. It is not used by the Delegated Management component.
A list of the IMTA options appears in Chapter 2, "IMTA Configuration," of the SIMS 4.0 Reference Manual. The following sections list each option with a more detailed description.
These options affect and modify various aspects of IMTA configuration file format and configuration settings.
COMMENT_CHARS (integer list {33, 59})
COMMENT_CHARS controls which characters are taken to signal a comment when they appear in the first column of IMTA input files. The value of this option takes the form of a list of ASCII character values in decimal. The default is the list {33, 59}, which specifies exclamation points and semicolons as comment introduction characters.
EXPROUTE_FORWARD (integer 0 or 1)
EXPROUTE_FORWARD controls the application of the exproute channel keyword to forward-pointing (To:, Cc:, and Bcc: lines) addresses in the message header. A value of 1 is the default and specifies that exproute should affect forward-pointing header addresses. A value of 0 disables the action of exproute on forward-pointing addresses.
ID_DOMAIN (string)
ID_DOMAIN specifies the domain name to use when constructing message IDs. By default, the official host name of the local channel is used.
IMPROUTE_FORWARD (integer 0 or 1)
IMPROUTE_FORWARD controls the application of the improute channel keyword to forward-pointing (To:, Cc:, and Bcc: lines) addresses in the message header. A value of 1 is the default and specifies that improute should affect forward-pointing header addresses. A value of 0 disables the action of improute on forward-pointing addresses.
MAX_ALIAS_LEVELS (integer)
MAX_ALIAS_LEVELS controls the degree of indirection allowed in aliases, that is, how deeply aliases may be nested, with one alias referring to another alias, and so on. The default value is 10.
MISSING_RECIPIENT_POLICY (integer)
RFC 822 (Internet) messages are required to contain a recipient header: a To:, Cc:, or Bcc: header. A message without a header is illegal. However, some broken user agents and mailers (For example, many older versions of sendmail) will emit such illegal messages. MISSING_RECIPIENT_POLICY takes an integer value specifying the approach to use for such messages. The default value, if the option is not explicitly present, is 0, meaning that envelope To: addresses are placed in a To: header.
Value
Action
0
Place envelope To: recipients in a To: header.
1
Pass the illegal message through unchanged.
2
Place envelope To: recipients in a To: header.
3
Place all envelope To: recipients in a single Bcc: header.
4
Generate a group construct To: header, To: Recipients not specified;.
5
Generate a blank Bcc: header.
6
Reject the message.
RECEIVED_DOMAIN (string)
RECEIVED_DOMAIN sets the domain name to use when constructing Received: headers. By default, the official host name of the local channel is used.
REVERSE_ENVELOPE (0 or 1)
REVERSE_ENVELOPE controls whether IMTA applies address reversal to envelope From: addresses as well as header addresses. This option will have no effect if USE_REVERSE_DATABASE is set to 0 or if neither the reverse database nor a REVERSE mapping exist. The default is 1, which means IMTA will attempt to apply any address reversal to envelope From: addresses. A value of 0 will disable this use of the address reversal database and REVERSE mapping.
USE_ALIAS_DATABASE (0 or 1)
USE_ALIAS_DATABASE controls whether IMTA uses the alias database as a source of system aliases for local addresses. The default is 1, which means that IMTA will check the database if it exists. A value of 0 will disable this use of the alias database.
USE_DOMAIN_DATABASE (0 or 1)
USE_DOMAIN_DATABASE controls whether IMTA uses the domain database as a source of rewrite rules. The default is 1, which means that IMTA will check the database if it exists. A value of 0 will disable this use of the domain database.
USE_FORWARD_DATABASE (integer)
USE_FORWARD_DATABASE whether IMTA uses the forward database. This value is a decimal integer representing a bit-encoded integer, the interpretation of which is given in the table below.
Bit
Value
Usage
0
1
When set, the forward database is used.
3
8
When set, channel-level granularity is used with the forward database entries. Forward database entries' left sides must have the form:
source-channel|from-address|to-address
Note the vertical bars, |.
4
16
When set, channel-level granularity is used with the FORWARD mapping. FORWARD mapping entries' patterns left sides must have the form:
source-channel|from-address|to-address
Note the vertical bars, |.
Bit 0 is the least significant bit.
The default value for USE_FORWARD_DATABASE is 0, which means that IMTA will not use the forward database. Note that a FORWARD mapping, if present, is always consulted.
USE_PERSONAL_ALIASES (0 or 1)
USE_PERSONAL_ALIASES controls whether IMTA uses personal alias databases as a source of aliases for local addresses. The default is 1, which means that IMTA will check such databases, if they exist. A value of 0 will disable personal aliases and make them unavailable to all users.
USE_REVERSE_DATABASE (0--255)
USE_REVERSE_DATABASE controls whether IMTA uses the address reversal database and REVERSE mapping as a source of substitution addresses. This value is a decimal integer representing a bit-encoded integer, the interpretation of which is given in the table below.
Bit
Value
Usage
0
1
When set, address reversal is applied to addresses after they have been rewritten by the IMTA address rewriting process.
1
2
When set, address reversal is applied before addresses have had IMTA address rewriting applied to them.
2
4
When set, address reversal will be applied to all addresses, not just to backwards-pointing addresses.
3
8
When set, channel-level granularity is used with the REVERSE mapping. REVERSE mapping table (pattern) entries must have the form:
source-channel|destination-channel|address
Note the vertical bars, |.
4
16
When set, channel-level granularity is used with address reversal database entries. Reversal database entries' left sides must have the form:
source-channel|destination-channel|address
Note the vertical bars, |.
5
32
Apply REVERSE mapping even if a reverse database entry has already matched.
6
64
Apply address reversal to message ids.
7
128
When set, this modifies the effect of bit 4 (channel-level granularity of address reversal database entries); when this bit is also set, the address reversal database entries take the form:
Note the vertical bars, |.
Bit 0 is the least significant bit.
The default value for USE_REVERSE_DATABASE is 5, which means that IMTA will reverse Envelope From: addresses and both backwards and forwards pointing addresses after they have passed through the normal address rewriting process. Simple address strings are presented to both the REVERSE mapping and the reverse database. Note that a value of 0 disables the use of the address reversal completely.
Note that the default of 5 represents a change from earlier versions of IMTA in which this option had a default value of 1 (reverse only backwards pointing addresses).
These options affect notification messages and the IMTA periodic return job.
ACCESS_ERRORS (integer 0 or 1)
IMTA provides facilities to restrict access to channels on the basis of the NETMBX privilege or on the basis of group ids on UNIX. If ACCESS_ERRORS is set to 0 (the default), when an address causes an access failure IMTA will report it as an "illegal host or domain" error. This is the same error that would occur if the address was illegal. This usage provides an important element of security in circumstances where information about restricted channels should not be revealed. Setting ACCESS_ERRORS to 1 will override this default and provide a more descriptive error.
HISTORY_TO_RETURN (1-200)
HISTORY_TO_RETURN controls the number of delivery attempt history records are included in returned messages. The delivery history provides some indication of how many delivery attempts were made and in some cases indicates the reason the delivery attempts failed. The default value for this option is 20.
LINES_TO_RETURN (integer)
LINES_TO_RETURN controls the number of lines of message content IMTA includes when generating a notification message for which it is appropriate to return only a sample of the contents. The default is 20. Note that this option is irrelevant when generating a NOTARY bounce message, where either the full content or only headers are included, according to the choice specified during the initial submission of the message. In practice, this option is mainly relevant to the warning messages the IMTA return job sends about messages awaiting further delivery retries in the IMTA queue area.
RETURN_ADDRESS (string)
RETURN_ADDRESS sets the return address for the local Postmaster. The local Postmaster's address is postmaster@localhost by default, but it can be overridden with the address of your choice. Care should be taken in the selection of this address --- an illegal selection may cause rapid message looping and pile-ups of huge numbers of spurious error messages.
RETURN_DELIVERY_HISTORY (0 or 1)
The RETURN_DELIVERY_HISTORY flag controls whether a history of delivery attempts is included in returned messages. The delivery history provides some indication of how many delivery attempts were made and in some cases indicates the reason the delivery attempts failed. A value of 1 enables the inclusion of this information and is the default. A value of 0 disables return of delivery history information. HISTORY_TO_RETURN controls how much history information is actually returned.
RETURN_ENVELOPE (integer)
RETURN_ENVELOPE takes a single integer value, which is interpreted as a set of bit flags. Bit 0 (value = 1) controls whether return notifications generated by IMTA are written with a blank envelope address or with the address of the local postmaster. Setting the bit forces the use of the local postmaster address, clearing the bit forces the use of a blank address. (The use of a blank address is mandated by RFC 1123.) However, some systems do not handle blank envelope From: addresses properly and may require this option. Bit 1 (value = 2) controls whether IMTA replaces all blank envelope addresses with the address of the local postmaster. This is used to accommodate incompliant systems that don't conform to RFC 821, RFC 822, or RFC 1123. Note also that you can use the returnenvelope channel keyword to impose this sort of control on a per-channel basis.
RETURN_PERSONAL (string)
RETURN_PERSONAL specifies the personal name to use when IMTA generates postmaster messages, for example, bounce messages. By default, IMTA uses the string IMTA e-Mail Interconnect.
RETURN_UNITS (0 or 1)
The time units used by the message return system is controlled using RETURN_UNITS; that is, this option controls the interpretation of the values specified for the notices keyword. A value of 0 selects units of days; a value of 1 selects units of hours. By default, units of days are used. On UNIX systems, the scheduling of the execution of the message return job is performed by changing the crontab entry controlling when it runs.
USE_ERRORS_TO (0 or 1)
USE_ERRORS_TO controls whether IMTA uses the information contained in Errors-to: header lines when returning messages. Setting this option to 1 directs IMTA to make use of this header line. A value of 0, the default, disables this header line. This default represents a change from the default in previous versions of IMTA.
USE_WARNINGS_TO (0 or 1)
USE_WARNINGS_TO controls whether IMTA uses the information contained in Warnings-to: header lines when returning messages. Setting this option to 1 directs IMTA to use these header lines. The default is 0, which disables this header line. This default represents a change from the default in previous versions of IMTA.
These options relate to message size, such as limits on the size of messages allowed in IMTA, message size affecting message processing priority, limits on the extent to which IMTA looks into messages of complex MIME structure, and fine tuning of message fragmentation.
BLOCK_LIMIT (integer > 0)
BLOCK_LIMIT places an absolute limit on the size, in blocks, of any message which may be sent or received with IMTA. Any message exceeding this size will be rejected. By default, IMTA imposes no size limits. Note that you can use the blocklimit channel keyword to impose limits on a per-channel basis. The size in bytes of a block is specified with BLOCK_SIZE.
BLOCK_SIZE (integer > 0)
IMTA uses the concept of a "block" in several ways. For example, the IMTA log files (resulting from placing the logging keyword on channels) record message sizes in terms of blocks. Message size limits specified using the maxblocks keyword are also in terms of blocks. Normally a IMTA block is equivalent to 1024 characters. Use this option to modify this sense of what a block is.
Note - IMTA stores message sizes internally as an integer number of blocks. If the size of a block in bytes is set to a very small value, it is possible for a very large message to cause an integer overflow. A message size of greater than 2**31 blocks would be needed, but this value is not inconceivable if the block size is small enough.
BOUNCE_BLOCK_LIMIT (integer)
BOUNCE_BLOCK_LIMIT can be used to force bounces of messages over the specified size to return only the message headers, rather than the full message content.
LINE_LIMIT (integer)
LINE_LIMIT places an absolute limit on the overall number of lines in any message that might be sent or received with IMTA. Any message exceeding this limit will be rejected. By default, IMTA imposes no line count limits. You can use the linelimit channel keyword to impose limits on a per-channel basis.
MAX_HEADER_BLOCK_USE (real number between 0 and 1)
MAX_HEADER_BLOCK_USE controls which fraction of the available message blocks can be used by message headers.
MAX_HEADER_LINE_USE (real number between 0 and 1)
MAX_HEADER_LINE_USE controls what fraction of the available message lines can be used by message headers.
MAX_INTERNAL_BLOCKS (integer)
MAX_INTERNAL_BLOCKS specifies how large (in IMTA blocks) a message IMTA will keep entirely in memory; messages larger than this size will be written to temporary files. The default is 10. For systems with lots of memory, increasing this value may provide a performance improvement.
MAX_MIME_LEVELS (integer)
MAX_MIME_LEVELS specifies the maximum depth to which IMTA should process MIME messages. The default is 100, meaning that IMTA will process up to one hundred levels of message nesting. Higher values may require additional amounts of memory and, for the Dispatcher, additional per-thread storage space.
MAX_MIME_PARTS (integer)
MAX_MIME_PARTS specifies the maximum number of MIME parts that IMTA should process in a MIME message. The default value is 0, meaning no limit is imposed.
NORMAL_BLOCK_LIMIT (integer)
NORMAL_BLOCK_LIMIT can be used to instruct IMTA to downgrade the priority of messages based on size: messages above the specified size will be downgraded to non-urgent priority. This priority, in turn, may affect whether the message is processed immediately, or whether it is left to wait for processing until the next periodic job runs. The value is interpreted in terms of IMTA blocks, as specified by BLOCK_SIZE. You can use the normalblocklimit channel keyword to impose such downgrade thresholds on a per-channel basis.
NON_URGENT_BLOCK_LIMIT (integer)
NON_URGENT_BLOCK_LIMIT may be used to instruct IMTA to downgrade the priority of messages based on size: messages above the specified size will be downgraded to lower than non-urgent priority, meaning that they will not be processed immediately and will wait for processing until the next periodic job runs. The value is interpreted in terms of IMTA blocks, as specified by BLOCK_SIZE. You can use the nonurgentblocklimit channel keyword to impose such downgrade thresholds on a per-channel basis.
URGENT_BLOCK_LIMIT (integer)
URGENT_BLOCK_LIMIT may be used to instruct IMTA to downgrade the priority of messages based on size: messages above the specified size will be downgraded to normal priority. This priority, in turn, may affect whether the message is processed immediately, or whether it is left to wait for processing until the next periodic job runs. The value is interpreted in terms of IMTA blocks, as specified by BLOCK_SIZE. You can use the urgentblocklimit channel keyword to impose such downgrade thresholds on a per-channel basis.
The options listed in this section affect IMTA logging. LOG_DELAY_BINS and LOG_SIZE_BINS relate to IMTA counters binning. The rest of these logging options affect the formatting of the IMTA log file and logging of optional additional information.
LOG_CONNECTION (integer)
LOG_CONNECTION controls whether or not connection information, for example, the domain name of the SMTP client sending the message, is saved in the mail.log file. This value is a decimal integer representing a bit-encoded integer, the interpretation of which is given in the table below.
Bit
Value
Usage
0
1
When set, connection information is included in E, D and R log records.
1
2
When set, connection open/close/fail records are logged by message enqueue and dequeue agents such as the SMTP and X.400 clients and servers.
2
4
When set, I records are logged recording ETRN events.
For example, enabling LOG_CONNECTION=3 will result both in additional sorts of log file entries--entries showing when an SMTP connection is opened or closed--and additional information in regular log file entries showing the name of the system connecting (or being connected to), or the channel host name of the enqueuing channel when the enqueuing channel is not an SMTP channel. TCP/IP channels have a channel level option that can override this setting for particular channels.
LOG_DELAY_BINS (comma-separated list of up to five integers)
This option specifies the bin divisions for the IMTA counters tracking numbers of messages delivered in the specified number of seconds. The defaults values are 60, 600, 6000, 60000, 600000.
LOG_FILENAME (0 or 1)
LOG_FILENAME controls whether the names of the files in which messages are stored are saved in the mail.log file. A value of 1 enables file name logging. When file name logging is enabled, the file name will appear as the first field after the final form envelope To: address. A value of 0 (the default) disables file name logging.
LOG_FORMAT (1, 2, or 3)
LOG_FORMAT controls formatting options for the mail.log file. A value of 1 (the default) is the standard format. A value of 2 requests non-null formatting: empty address fields are converted to the string "< >". A value of 3 requests counted formatting: all variable length fields are preceded by "N:", where "N" is a count of the number of characters in the field.
LOG_HEADER (0 or 1)
LOG_HEADER controls whether IMTA writes message headers to the mail.log file. A value of 1 enables message header logging. The specific headers written to the log file are controlled by a site-supplied log_header.opt file. The format of this file is that of other IMTA header option files. For instance, a log_header.opt file containing
would result in writing the first To: and the first From: header per message to the log file. A value of 0 (the default) disables message header logging.
LOG_LOCAL (0 or 1)
LOG_LOCAL controls whether the domain name for the local host is appended to logged addresses that don't already contain a domain name. A value of 1 enables this feature, which is useful when logs from multiple systems running IMTA are concatenated and processed. A value of 0, the default, disables this feature.
LOG_MESSAGE_ID (0 or 1)
LOG_MESSAGE_ID controls whether message IDs are saved in the mail.log file. A value of 1 enables message ID logging. When message ID logging is enabled, the message ID will be logged after the final form envelope To: address entry---and after the message file name, if LOG_FILENAME=1 is also enabled. A value of 0 (the default) disables message ID logging.
LOG_NOTARY (0 or 1)
LOG_NOTARY controls whether IMTA includes an indicator of NOTARY (delivery receipt) flags in the mail.log file entries. A value of 1 enables NOTARY flag logging. A value of 0 (the default) disables it. The NOTARY flags will be logged as a bit encoded integer after the current form of the envelope To: address.
LOG_PROCESS (0 or 1)
LOG_PROCESS controls whether the id of the process that enqueues mail is saved in the mail.log file. A value of 1 enables process id logging. A value of 0 (the default) disables it. The process id will be logged in a hexadecimal representation, after the date and time stamps in log entries--and after the node name, if LOG_NODE=1 is also enabled.
LOG_SIZE_BINS (comma-separated list of up to five integers)
LOG_SIZE_BINS specifies the bin divisions for the IMTA counters tracking numbers of messages of the specified number of (IMTA) blocks. The default values are 2, 10, 50, 100, 500.
LOG_SNDOPR (0 or 1)
LOG_SNDOPR controls the production of syslog messages (UNIX) by the IMTA message logging facility. If this feature is enabled by specifying a value of 1, the logging facility will produce a message if it encounters any difficulty writing to the log file. A value of 0 (the default) turns off these messages.
LOG_USERNAME (0 or 1)
LOG_USERNAME controls whether the user name associated with a process that enqueues mail is saved in the mail.log file. A value of 1 enables username logging. When user name logging is enabled, the user name will be logged after the final form envelope To: address field in log entries--and after the message ID, if LOG_MESSAGE_ID=1 is also enabled. A value of 0 (the default) disables user name logging.
SEPARATE_CONNECTION_LOG (0 or 1)
SEPARATE_CONNECTION_LOG controls whether the connection log information generated by setting LOG_CONNECTION=1 is stored in the usual IMTA message logging files, mail.log*, or stored separately in connection.log* files. SEPARATE_CONNECTION_LOG=0, the default, causes connection logging to be stored in the regular message log files; a value of 1 causes the connection logging to be stored separately.
These options relate to IMTA's facility to sideline as .HELD messages that appear to be looping.
HELD_SNDOPR (0 or 1)
HELD_SNDOPR controls the production of syslog messages (UNIX) when a message is forced into a held state because it has too many Received: header lines. A value of 1 instructs IMTA to issue a message when this happens. A value of 0 (the default) turns off these messages.
MAX_LOCAL_RECEIVED_LINES (integer)
As IMTA processes a message, it scans any Received: header lines attached to the message looking for references to the official local host name. (Any Received: line that IMTA inserts will contain this name). If the number of Received: lines containing this name exceeds the MAX_LOCAL_RECEIVED_LINES value, the message is entered into the IMTA queue in a held state. The default for this value is 10 if no value is specified in the option file. This check blocks certain kinds of message forwarding loops. The message must be manually moved from the held state for processing to continue.
MAX_RECEIVED_LINES (integer)
As IMTA processes a message, it counts the number of Received: header lines in the message's header. If the number of Received: lines exceeds the MAX_RECEIVED_LINES value, the message is entered into the IMTA queue in a held state. The default for this value is 50 if no value is specified in the option file. This check blocks certain kinds of message forwarding loops. The message must be manually moved from the held state for processing to continue.
These options relate to internal IMTA sizing issues. In general, these options should not be set manually, but should instead be automatically resized when necessary by using IMTA cnbuild (UNIX) utility.
ALIAS_HASH_SIZE (integer <= 32,767)
ALIAS_HASH_SIZE sets the size of the alias hash table. This in turn is an upper limit on the number of aliases that can be defined in the alias file. The default is 256; the maximum value allowed is 32,767.
ALIAS_MEMBER_SIZE (integer <= 20,000)
ALIAS_MEMBER_SIZE controls the size of the index table that contains the list of alias translation value pointers. The total number of addresses on the right sides of all the alias definitions in the alias file cannot exceed this value. The default is 320; the maximum allowed is 20,000.
CHANNEL_TABLE_SIZE (integer <= 32,767)
CHANNEL_TABLE_SIZE controls the size of the channel table. The total number of channels in the configuration file cannot exceed this value. The default is 256; the maximum is 32,767.
CONVERSION_SIZE (integer <= 2000)
CONVERSION_SIZE controls the size of the conversion entry table. The total number of conversion file entries cannot exceed this number. The default is 32.
DOMAIN_HASH_SIZE (integer <= 32,767)
DOMAIN_HASH_SIZE controls the size of the domain rewrite rules hash table. Each rewrite rule in the configuration file consumes one slot in this hash table. The number of rewrite rules cannot exceed this option's value. The default is 512; the maximum number of rewrite rules allowed is 32,767.
HOST_HASH_SIZE (integer <= 32,767)
HOST_HASH_SIZE controls the size of the channel hosts hash table. Each channel host specified on a channel definition in the IMTA configuration file (both official hosts and aliases) consumes one slot in this hash table. The total number of channel hosts cannot exceed the value specified. The default is 512; the maximum value allowed is 32,767.
MAP_NAMES_SIZE (integer > 0)
MAP_NAMES_SIZE specifies the size of the mapping table name table. The total number of mapping table names cannot exceed this number. The default is 32.
STRING_POOL_SIZE (integer <= 10,000,000)
STRING_POOL_SIZE controls the number of character slots allocated to the string pool used to hold rewrite rule templates, alias list members, mapping entries, and so on. A fatal error will occur if the total number of characters consumed by these parts of the configuration files exceeds this limit. The default is 65,000; the maximum allowed value is 10,000,000.
WILD_POOL_SIZE (integer)
WILD_POOL_SIZE controls the total number of patterns that may appear throughout mapping tables. A fatal error will occur if the total number of mapping patterns exceeds this limit. The default is 8,000; the maximum allowed value is 200,000.
These options enable debugging of various IMTA facilities.
DEQUEUE_DEBUG specifies whether debugging output from IMTA's dequeue facility QU is produced. If enabled with a value of 1, this output will be produced on all channels that use the QU routines. The default value of 0 disables this output.
POST_DEBUG (0 or 1)
POST_DEBUG specifies whether debugging output is produced by IMTA's periodic delivery job. If enabled with a value of 1, this output will be produced in the post.log file. The default value of 0 disables this output.
This section describes any changes or updates to the SIMS 4.0 UNIX man pages.
An error exists in the "Synopsis" section of the imrestore(1M) man page. The correct synopsis is:
[-f device | file | -] [-c continuation_file] [-l config_file] \
[ [-u usernames_file] | userid... | userid@domain...]
Only a usernames_file is used with the -u option. The userid and userid@domain parameters are not used with the -u option.
An addition should also be made to the description for each of the user parameters (userid, userid@domain, and usernames_file) In each of the user parameters, the user or users that are being restored can be listed (either in a file or on the command line). The user can be specified as userid or old_userid=new_userid. When restoring a user back to the same userid, you only need to specify the userid. If restoring or migrating a user to a new userid, the equal sign (=) is used to separate the new and the old userids. If a userid contains an `=', you need to escape the character with a backslash (\). For example:
Do not use any blanks around the `=' or within the userids.
Similar syntax should be used if the list is specified in a file (usernames_file). However, additional double-quotes should not be placed around any strings specified in a file. The following is an example of a usernames_file:
This feature is useful when migrating users from SIMS 3.x to SIMS 4.0.
References to the spmProgramNumber parameter in the sims.cnf(4) man page should be removed. It is not used by the Delegated Management component.
The "Synopsis" section for the immd_recipient_disposition(3) man pages is incorrect. It reads:
The actual function does not accept the flags argument.
The following information should be added to the imadmin-delete-user(1M) and imadmin-purge-user(1M) man pages:
Clearing the delete flag in the directory does not prevent a user purge. This condition exists during the following times:
|
|
the period between marking the user as deleted and the actual purge |
|
|
the period between the time the purge utility detects the delete flag and the time when the purge is performed |
The relationship between the imdeluser, imadmin-delete-user, and imadmin-purge-user utilities needs to be described in each of the respective man pages. Add the following description to the imdeluser(1M), imadmin-delete-user(1M), and imadmin-purge-user(1M) man pages:
Similarities and differences exist among the delete user and user purge utilities in SIMS. The imdeluser utility removes a specified user or users from the message store. The imadmin-delete-user utility only marks a user entry as deleted. In order to remove that user from the message store, you must execute imadmin-purge-user. In addition, imadmin-purge-user also removes the user's LDAP entry and updates the IMTA cache.