| SIMS 4.0 Patch 9 Release Notes |
Sun Internet Mail Server™ 4.0 Product Update
This product update reflects changes made to the SIMS 4.0 release introduced by the 09 revision of the SIMS product patch (108049-09 for SPARC and 108050-09 for Intel). The product update notes cover installation and software bugs for SIMS 4.0. The patch update process is outlined as follows:
Product Update Notes
Items covered in this product update are cumulative from the initial release of SIMS 4.0. A list of bugs fixed in this release is available in the patch readme.
Installation Updates
This section describes updates and workarounds for the known problems that occur during installation and initial configuration.
Installation fails with root umask set to 227. (bug 4270752)
An address error occurs during SIMS 4.0 installation. Because the root umask is set to 227 (read and execute permission only for owner and group), the IMTA configuration file cannot be properly created.To work around this problem, before installation, set the root umask to 022 (read, write, and execute permission for owner; read and execute permission for group and other).
Disappearing lines in slapd.conf file. (bug 4250205)
Bringing up the SIMS Administration Console with the Netscape Directory Server causes the schema files to disappear from the slapd.conf file. The console rewrites the slapd.conf file, removing the following lines:The old file is renamed slapd.conf.old.
To work around this problem, restart the slapd process before starting the SIMS Administration Console:
# /usr/netscape/server4/slapd-<hostname>/stop-slapd
# /usr/netscape/server4/slapd-<hostname>/start-slapd
Fatal error during install. (bug 4248148)
An error results when installing SIMS 4.0 using setup-tty with the sims_setup.dat file and the following options: Web Access, SDK, SDK documentation, SIMS 4.0 documentation, varmail, Sun Directory Services, remote LDAP host, and alternate LDAP Port.You will receive an error similar to:
Note A dirsync cron job is set up by the postinstall script of the SUNWimimo package. This job is set to execute at 10, 30 and 50 minutes past every hour. The message store configuration file ims.cnf is created towards the end of install during the configuration phase. If the cronjob executes between the time the cronjobs are set up and the message store configuration file is created (usually between 8-10 minutes), this error will result.
Apart from the display on the console, this is not fatal and the next time the cron job is executed, it will succeed.
Some directories remain after uninstall. (bug 4267591)
After uninstalling SIMS 4.0, certain files associated with Web Access and Sun Directory Server are not removed; hence, their directories are not removed. These files are co-packaged with SIMS 4.0 but are not really a part of the SIMS product. They reside in the following directories:You can remove these files and directories with the rm -rf command.
Installing SIMS with SunCluster 2.2
SunCluster 2.2 Patch will not work on systems with SIMS 4.0 (in an HA configuration) and the Netscape Directory Service (NSDS) unless the modifications described in this note are made to the SIMS and SunCluster configuration. The patch number is 108109-01 and is available through your solution provider.
Advantage of applying SunCluster patch
This patch contains a fix that enables the Netscape Directory Service probing feature. This feature allows the HA server to probe for the slapd process. In an event of slapd failure, the HA server will try to restart the service. If restart attempts fail, the service will be restarted on the backup node. This provides more directory service reliability.
To configure the SunCluster
These instructions describe the procedures for new SunCluster installations as well as how to modify existing installations. These instructions make extensive references to "Guidelines for Installing and Configuring SunCluster and High Availability," Page 147 of the SIMS 4.0 Installation Guide.
Install this patch on both cluster nodes.
3. Register the NSDS/HA service:Run /opt/SUNWcluster/bin/hadsconfig on both cluster nodes.
If you have completed step 6 of "Guidelines for Installing and Configuring SunCluster and High Availability" in an earlier installation, undo the changes on both cluster nodes.
- Use "Create instance" if this is the first time running hadsconfig. Use "Edit instance" if you've already run hadsconfig.
- Next to Name of the instance: enter nsldap
- Next to Base directory of product installation: enter
/shared-file-system/NSDS/slapd-ha-logical-hostname
- Use default values for other parameters of hadsconfig, and save the changes. These parameters are shown in step 5 of "Guidelines for Installing and Configuring SunCluster and High Availability."
Re-register and re-start both nsldap and SIMS data services.
- That is, make sure the line method_timeout='hareg -q nsldap -T stop' exists in /opt/SUNWcluster/ha/nsldap/nsldap_svc_stop
- Skip step 7 of "Guidelines for Installing and Configuring SunCluster and High Availability".
- Refer to page 152 of the SIMS 4.0 Installation Guide on how to register the Netscape directory service with the High Availability Framework. (If the data services have been registered, they need to be unregistered prior to being re-registered.) Replace steps 3-5 as follows:
4. Start the NSDS/HA service:
- # /opt/SUNWhadf/bin/hareg -s -r nsldap
5. Re-register the SIMS/HA service:
- # /opt/SUNWhadf/bin/hareg -y nsldap
- # /opt/SUNWhadf/bin/hareg -r Sun_Internet_Mail -b /opt/SUNWimha/clust_progs -m START_NET=imha_start_net, STOP_NET=imha_stop_net -t START_NET=120,STOP_NET=30 -v 4.0 -d nsldap
Procedure for removing the NSDS Data Service
Refer to page 155 of the SIMS 4.0 Installation Guide on how to remove the NSDS Data Service. Replace steps 3-4 with the following:
4. Unregister the NSDS/HA service:
- # /opt/SUNWhadf/bin/hareg -n nsldap
- # /opt/SUNWhadf/bin/hareg -u nsldap
Software Updates
This section describes software updates that are introduced by the SIMS 4.0 product patch.
Simple family account implementation
Simple family accounts enhancements have been added to the Delegated Management (DM) Console.Through the DM Console, an administrator has the ability to:
Also through the DM Console, a family head has the ability to:
The following items have been added to the Edit Properties page:
A set of command line interfaces has also been included. Through the CLI, a family head can add, modify, or delete a family member, and generate a family account report.
Logging file systems and SIMS
A logging file system is a computer file system that contains its own backup and recovery capability. Before file indexes on disk are updated, the information about the changes are recorded in a log. If a power or other system failure corrupts the indexes as they are being rewritten, the operating system can use the log to repair the indexes when the system is restarted.SIMS supports two logging file systems, Veritas VxFS and the UFS logging file system. The advantages of using a logging file systems in SIMS are:
The disadvantages of using a logging file systems in SIMS are:
If a message is being written to a folder, and if the system crashes during the write, the folder can be corrupted due to a partial write to disk. Using a logging file system prevents such a partial write.
When the system crashes or if imaccessd is terminated abnormally (for example, by using kill -9) you are required to run imcheck -c to check and repair message store corruption. This must be done before restarting SIMS. All the SIMS processes must be shut down while imcheck -c is running. This can result in hours of downtime. With a logging file system, you are not required to run imcheck -c after a system crash or abnormal termination. There is no downtime.
Message store performance may be somewhat affected due to file logging overhead.
How to create an ETRN Queue Channel
An ETRN Queue Channel can reduce SIMS computational overhead for domains without permanent connections to the mail server. SIMS enqueues messages for disconnected domains and delivers them when the domain client connects to SIMS and sends an SMTP ETRN <client_domain> command (see RFC 1985—www.rfc-editor.org). The problem is that by default, SIMS continues attempting delivery of the domain's messages at regular intervals, even though the only time the messages can be delivered is when the domain client is connected. These unsuccessful delivery attempts generate non-delivery messages and waste computational resources.By creating an ETRN Queue Channel for each domain, messages to that domain are stored in the channel and no delivery attempt is made until the domain client sends an ETRN command.
To create an ETRN Queue Channel, you must create a rewrite rule and a channel for each domain which will be using ETRN. The rule will cause the mail to be routed to the appropriate channel. The mail will be held in the channel until the client connects and retrieves it.
The rewrite rule should be like the following:
domain1.com $E$U%$D@tcp_etrn_dom1-daemon
The new channel should have the same settings as the tcp_local channel but also include the slave keyword, and possibly change the notices keyword:
(note: the tcp_etrn_dom1 smtp single_sys...slave line above should be all one line, but may appear to be on separate lines because of its length.)
Separate channels are required for each domain because when a client issues the ETRN command, the IMTA will attempt to deliver all messages pending in the channel.
For SIMS 4.0, you can have a single ETRN Queue Channel holding the messages for multiple domains. However, the client must issue the ETRN command in the following form:
If the client issues this command without the @, then SIMS will attempt to deliver all the messages in the channel.
The slave keyword prevents the IMTA from attempting to deliver the mail. The messages will be delivered only when the client connects and issues the ETRN command. See the SIMS 4.0 Reference Guide page 102 for additional information on the slave keyword.
The notices 1 2 4 7 keyword specifies when warning messages should be returned to senders to let them know that the message is still in a queue waiting to be delivered. Depending on how frequently the remote system will connect to retrieve mail, you may want to increase these values. See the SIMS 4.0 Reference Guide page 108 for additional information on the notices keyword.
SMTP AUTH supports CRAM-MD5
SMTP AUTH now supports CRAM-MD5 SASL mechanism with the following restrictions:
To turn on the CRAM-MD5 mechanism, set the following option in
/etc/opt/SUNWmail/imta/option.dat:
Adding SMTP over TLS to SIMS
This section describes how to add SMTP over TLS to SIMS.
Overview
As defined in RFC 2246, the primary goal of the Transport Layer Security (TLS) protocol is to provide privacy and data integrity between two communicating applications. The TLS protocol itself is based on the SSL 3.0 Protocol Specification as published by Netscape. SIMS 4.0 is compliant with SSL 3.0. There are some differences between TLS 1.0 and SSL 3.0 but TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0. In the following, we will talk about TLS and not SSL.For an overview of SIMS implementation of SSL, see the Chapter 11 of SIMS 4.0 Administrator's Guide, "Secure Sockets Layer (SSL) Support in SIMS."
There are two modes of operation that the SIMS IMTA supports:
The only difference between these two modes is when the TLS negotiation begins. In both cases, once the TLS negotiation is complete, all subsequent data sent across the TCP connection will be secure.
Connecting to a special port number is one way to connect to a TLS enabled server. SMTP has an established port for use with TLS (port 465). When a client connects to this special port (as configured in the Dispatcher configuration file), the IMTA will immediately begin TLS negotiation. Once the negotiation is complete, the connection will be given to the service as usual.
If a STARTTLS command is used, the TCP connection is established on the usual port number (or an alternate port number if configured in the Dispatcher) and given to the service normally. If TLS is available to the client in this SMTP session, the server will advertise STARTTLS as one of its available SMTP extensions. The client will then issue the STARTTLS command, and the server will acknowledge receipt of the SMTP command and instruct the client to begin TLS negotiation. Again, once the negotiation is complete, the connection continues normally.
If connecting to a special port is largely widespread for IMAP or POP protocols, the STARTTLS command is a better and more flexible choice for SMTP.
Security Layer Configuration
The security layer can be configured on the server or client side.
Server Side Configuration
If you plan to use only the server side of STARTTLS (the server accepts the STARTTLS command but never issues it), or if you want to use the special port, the step by step configuration of TLS/SSL is described in chapter 11 of SIMS 4.0 Administrator's Guide, "Secure Sockets Layer (SSL) Support in SIMS." If SSL was configured for IMAP/POP, no additional step is needed.
Configuration SMTP Over TLS
This section describes how to configure SMTP over TLS.
Dispatcher Related Configuration For Alternate Port Numbers
By default, the dispatcher.cnf file has an SMTP service definition that looks something like:To enable TLS for such a dispatcher service, you simply add a TLS_PORT option to the configuration for that service. For example, to add TLS support on port 465 for SMTP (the established port for SMTP TLS use), you'd use:
[SERVICE=SMTP]
PORT=25
TLS_PORT=465
...Once the dispatcher configuration modifications are complete, you must restart the dispatcher (if it is currently running) or start it (if it is not currently running) so that the new dispatcher configuration with the new port numbers takes effect.
TCP/IP channel configuration for TLS use (STARTTLS)
SIMS supports a number of keywords on the TCP/IP channels to control whether TLS functionality is desired or required. These keywords are summarized in the following table:
Enabling (or requiring) the use of TLS may be of interest with dedicated channels intended for communicating sensitive information with companion systems that also support TLS.
Enabling the use of TLS for the SMTP server may also be of particular interest when SMTP SASL use has been enabled. Since with SMTP SASL use, a remote client will be sending a password over the network, then, especially if the PLAIN authentication mechanism is used (password sent "in the clear"), it may be particularly desirable to use TLS so that the entire transaction, including the password, is encrypted.
Use of the tlsswitchchannel keyword may be of interest for logging purposes, so that log entries show the message as coming in via a special channel. Use of the tlsswitchchannel keyword may also be of interest if it is desired to route messages submitted using TLS differently (using source channel specific rewrite rules) than messages submitted without TLS.
About the Switchchannel Keywords
In the following examples, we make extensive use of the switchchannel/tlsswitchchannel/saslswitchchannel keywords. Those keywords allow you to switch the source channel of a connection. Switching the source channel means that all the messages submitted by the user will be seen (in terms of logging or access control) as coming from the new source channel. Another effect of switching the source channel is that all the keywords associated with the old source channel are forgotten and the ones associated with the new channel apply. For example, if the tcp_local channel definition contains the musttlsserver keyword but the user is switched to tcp_intranet, which doesn't contain this keyword, the user won't have to use TLS.If the switchchannel is configured in the tcp_local definition (see SIMS 4.0 Reference Guide, "Selecting an Alternate Channel for Incoming Mail" page 118), it is applied first, at the beginning of the connection. For the other switchchannel keywords, they are taken into account in the order the corresponding commands are issued.
Sample TLS Configurations
The following three examples describe how to configure TLS.
Example 1
A site that has a submission SMTP server reserved for its own subscribers and has the following policy:
The system can be configured as follows (only the main keywords are shown):
in imta.cnf:
A subscriber trying to connect from tcp_local must issue the STARTTLS command in order to be able to send a message (musttlsserver keyword). If the command succeeds, the user is switched to the tcp_tls channel (tlsswitchchannel tcp_tls keyword), every message submitted by this user will be seen as coming from the tcp_tls channel (for logging as well as access mapping purposes).
A user trying to connect from the site's intranet will be first switched from tcp_local to tcp_intranet. Consequently, STARTTLS is offered to the user, however, the user does not have to use it (maytlsserver keyword). If the user issues the STARTTLS command, the user will be switched to tcp_tls.
Of course a publicly referenced SMTP server (MX recorded) should not use this kind of configuration.
Example 2
A site that generally blocks SMTP relaying through its SMTP server, but wishes to allow such SMTP relaying for specific users who will authenticate themselves using SASL (SMTP AUTH), might use channel definitions similar to these given below. This type of configuration is particularly appropriate for sites wanting to allow roaming users to keep relaying mail through their domain's mail server, while preventing other users from doing the same.In imta.cnf:
tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth
tcp-daemon
tcp_auth smtp mx single_sys mustsaslserver
tcp-auth-daemonwith an ORIG_SEND_ACCESS mapping table (/etc/opt/SUNWmail/imta/mappings) like this:
ORIG_SEND_ACCESS
tcp_local|*|tcp_local|* $NRelaying$ not$ permittedFor details about using SASL, see SMTP AUTH Configuration on page 140 of the SIMS 4.0 Administrator's Guide.
The problem with this configuration is that clients will use the PLAIN mechanism to authenticate. The PLAIN mechanism implies that user passwords are sent in clear text. Passwords should never be sent in clear text in an untrusted environment unless over TLS.
The same configuration with TLS would look like this:
In imta.cnf:
with an ORIG_SEND_ACCESS mapping table
(/etc/opt/SUNWmail/imta/mappings) like this:
ORIG_SEND_ACCESS
tcp_auth|*|*|* $Y
tcp_*|*|tcp_local|* $NRelaying$ not$ permittedA client connecting from the tcp_local channel issues the EHLO command. The server offers STARTTLS (maytlsserver keyword in tcp_local definition) but not AUTH as an extension. The client issues the STARTTLS command and is switched to the tcp_tls channel (tlsswitchchannel tcp_tls keyword in tcp_local definition).
Then, it issues a new EHLO command. At this point, since the maysaslserver keyword is configured for the tcp_tls channel, the server offers AUTH in the available extensions. If the client authenticates successfully, it is switched to tcp_auth (saslswitchchannel tcp_auth keyword in tcp_tls definition) and the ORIG_SEND_ACCESS rules apply from this channel.
Example 3
Three companies (a.com, b.com, and c.com) want to exchange secure information over the Internet. They want to use TLS when sending messages to each other but not when talking to any other domain. A sample configuration for a.com could be:In imta.cnf:
A message for user@toto.com matches a rule in internet.rules (.com $U%$H$D@tcp-daemon) and goes into the tcp_local channel from which it will be sent without using TLS.
A message for user@b.com matches the (b.com $E$U%$D@tcp_tls-daemon) rule and consequently is routed to the tcp_tls channel. The tcp_tls channel definition contains the musttlsclient keyword. When the message is finally sent to b.com mailserver, the tcp_smtp_client must use STARTTLS.
New option for imquotacheck
A new command line option has been added to the imquotacheck utility. The -m option allows the administrator to customize the quota warning message. The syntax for the -m option is:
-m msg-file where the msg-file variable represents the file name of the quota warning message. The msg-file must contain a valid message header and a message body. Every line must be terminated with a CRLF. Required header fields must be present. The following macros can be used inside the message body (imquotacheck replaces the macros with the user's information before it delivers the message):
The following is an example <msg-file> (quota.msg):
Using the above quota.msg file, the following command can be executed:
# imquotacheck -u joe -m quota.msg The following is the example output:
Authentication to the SMTP server now supports Microsoft Outlook and Outlook Express. (bug 4308271)
Authentication to the SMTP server, SMTP Auth, can be enabled for Microsoft Outlook and Outlook Express by following these steps:
Add the keywords mustsaslserver and msexchange to the tcp_intranet channel and maysaslserver to the tcp_local channel in the /etc/opt/SUNWmail/imta/imta.cnf file.
Run the imta restart commnand.
Issue an ehlo command to check whether the following lines are set in SMTP:
AUTH LOGIN PLAIN
AUTH=LOGIN PLAINIn Outlook, check the box "My server requires authentication" in the Outgoing Mail Server section and make sure the logon settings are set appropriately. Without this option checked, the user will not be able to send mail.
New hold_master and hold_slave images were included in SIMS 4.0 patch 9. (bug 4404170)
Potential Problems and Solutions
This section describes known software limitations that have workarounds in the 09 revision of the SIMS 4.0 product patch.
Workaround for broken POP3 client depending on qpopper functionality. (bug 4335073)
POP3 clients that depend on qpopper functionality do not work. qpopper is inconsistent with the POP3 RFC in a variety of ways. However, because it is the POP3 server in widest use, it must be considered a defacto standard and clients that depend upon this functionality must be supported.The workaround is to set the property ims-emulate-qpopper on in ims.cnf. Restart all the daemons. Make note of the differences before and after setting.
The dns_verify utility should be able to log messages to syslog when an address is: rejected/accepted/timedout. (bugs 4335213, 4460391)
The dns_verify and imthrottle modules are now able to log rejected addresses in the syslog. The prefix for those syslog messages is:The dns_verify program is documented in Chapter 6 of the SIMS 4.0 Administration Guide. Configuration is not needed for the new syslog facility. If you use dns_verify in the context of ORIG_SEND_ACCESS and ORIG_MAIL_ACCESS mapping rule and the domain fails to be verified, you will get a syslog entry, such as:
SUNWmail.imta.anti-spam[22159]: dns_verify:unknown (domainname) If you use dns_verify in the context of PORT_ACCESS mapping rule and the domain is verified to be in a blacklist, you will get a syslog entry, such as:
SUNWmail.imta.anti-spam[23091]: dns_verify:found (domainname) If the dns_verify program encounters a timeout or other error, you will get:
SUNWmail.imta.anti-spam[23101]: dns_verify:timeout (domainname)
SUNWmail.imta.anti-spam[23190]: dns_verify:unknown error (domainname)
The imexpire utility should expire the oldest messages in the folders that are over quota. (bugs 4337672, 4447308)
The -q option has been added to imexpire. This option expires the oldest messages in the folder, until the total_bytes of a folder are fewer than the specified quota limit. The following is an example:The quota should be listed in bytes, where 1,000,000 would be a possible number used, though this number will vary dramatically depending on the situation.
Optionally enhance full dirsync performance by not generating reverse database. (bug 4340194)
Optionally enhance full dirsync performance by not generating the reversedb database. Running the command imta dirsync -F (a full dirsync) generates the reversedb database in
/var/opt/SUNWmail/imta/db automatically. This can be a performance problem for sites with very large numbers of users (for example, in excess of 1 million) because the time to perform the database insertions becomes significant in the overall time a full dirsync takes to complete.In addition, some sites would like to eliminate the use of reversedb altogether, while still using a REVERSE mapping. However, the lookup to the reversedb is still performed and there was no option to avoid this.
This option can be turned on by adding the keyword NOREVERSEDB to the dirsync.opt file located in /etc/opt/SUNWmail/itma.
POP server needs to send status: U line for new mail. (bug 4352681)
The Sega DreamPassport POP3 client needs to receive a U flag in status header flag to indicate new (unread) mail. To accommodate this client without breaking other clients, the ims-pop-status-unread option was added to the ims.cnf file. To enable this option, add the following to the /etc/opt/SUNWmail/ims/ims.cnf file:
The commands imta dirsync and imdeluser should provide configuration path option. (bug 4353721)
The quota update command failed to update quota in a non-default message store. An environment variable IMS_CONFIG_DIR has been added for setting the location of the config file, ims.cnf.This environment variable will also affect the imadmin-purge-user command.
The libthread utility may cause a panic. (4381942)
If you encounter a libthread panic on your system, you can use the following patch(es) to fix the problem:105568-15 or 105568-21 on Solaris 2.6 SPARC
There is no patch available for Solaris 2.7 on X86.
SIMS is sensitive to conflicting access rules. (bug 4276513)
Administration services works as expected when either anti-relaying rules or mail blocking rules are enabled, but when both rules are enabled in the /etc/opt/SUNWmail/imta/mappings file, the Administration Server returns the following error message at startup:
To workaround this problem try one of the following:
SMTP port not responding. (bug 4339061)
SIMS server is unable to send or receive mail consistently with multiple SMTP processes running.The workaround is to stop some of the SMTP processes. To avoid this problem:
set the dispatcher.cnf file max_shutdown to equal 1/2 the number of max_procs.
view the output of the netstat(im) if connection timeouts are occurring. The backlog with active SYN_RECEIVED connections may be full.
set BACKLOG=n in the dispatcher.cnf file, the default is 5, which is not enough for an ISP, so it should be set to a higher number, such as a few hundred (later versions of PMDF/SIMS have a higher default). Use a default number that is less than the kernel setting.
ensure the tcp parameters correspond to the version of solaris. The tcp parameters should be tcp_conn_req_max (prior to solaris 2.6), or tcp_conn_req_max_q and tcp_conn_req_max_q0 for solaris 2.6 or later or solaris 2.5.1 with patches 103630-09 and 103582-12. tcp_conn_req_max_q0 defaults to 1024. The backlog should be set to a number lower than 1024.
Delegated Administrator CGI fails when the distribution list is too large. (bug 4284501)
Once a distribution list gets to be too large, you cannot add any more users through the Delegated Management Console.The buffer size has been increased to 6144 instead of 1024 which allows 256 users with 24 character lengths apiece.
Administrator cannot modify group entry with the Administration Console. (bug 4338045)
An administrator using the Administration Console cannot always modify the group entry name. For example, using the following steps, the group entry name is not modified as it should be.
Create a no password group at DM console (or Administration CLI).
The GUI indicates a process is underway, but the attribute is not always modified.Logon to the Administration Console.
The workaround for the problem is to add a password to the group properties.
Delegated Administrator cannot add a group as member to another group. (bug 4340645)
In the Delegated Administrator Console, when attempting to add a group, which was created by the Administration Console, to an existing group, the operation fails.The workaround is to create a group with Delegated Administrator or imadmin-add-group and add it to an existing group.
In the Delegated Management (DM) Console, the last rfc822mailmember cannot be removed. (bug 4318979)
DM Console fails to remove the last external member of a distribution list (rfc822mailmember).The workaround for this problem is shown in the example that follows.
Using an example distribution list as follows:.
In the DM console (using edit distribution list option), drag and delete all members.
- At this time, there is a "uniquemember: o=internet" data existing in LDAP.
Click edit distribution list in the DM console
In this list, add internal members only.
- There is no member (both internal and external) in the list that appears.
The imbackup utility does not back up shared folders. (bug 4267595)
The imbackup utility does not backup Shared folders. The following command is an example:
# imbackup -f /tmp/backup -u /tmp/username where /tmp/username is a group members list who used the Shared folder. After invoking imrestore, the group members' Inboxes are restored, but the Shared folders are not.
To workaround this problem, use distribution lists instead of Shared folders.
The imta counters become corrupt and do not display channel information. (bug 4306284)
When using SIMS 4.0 with latest patch installed, occasionally, the imta counters show command does not display everything is supposed to.
External list member is not clearly deleted by the DM Console. (bug 4283824)
The last external member of a distribution list is not completely deleted by the DM Console. If you create a distribution list with all external members, then use the DM Console to remove them one by one, everything seems to work properly; no warning messages are displayed. However, upon reverting back to the Administration Console, the last member in the list still remains.Delegated Manager will not process the delete operation if there are illegal characters at the end of entry. This problem can be resolved by removing the extra CR, space, or tab trailing the last member of the distribution list.
Creating groups with only external members/removing all internal members from a group. (bug 4261934)
The Administrator cannot create a group containing only external members. If a user attempts to do so, they will receive the "Create group failed" message.Additionally, the administrator cannot remove all internal members from a group. If a user attempts to do so, they will receive the "Failed to add/modify entry" message.
The workaround to these problems is to modify the groupOfNames section in the slapd.cc.conf file and to remove a required attribute so that it reads:
objectclass groupOfNames
requires
cn,
objectClass
allows
member,
businessCategory,
description,
o,
ou,
owner,
seeAlso
Korean to UTF-8 iconv module is not found. (bug 4262729)
The Korean to UTF-8 iconv module is not found when called by name.This bug has been partially fixed in the patch 05 revision. The following links should be made in /usr/iconv/lib/ during install or as a workaround:
# ln -s ko_KR-iso2022-7%ko_KR-UTF-8.so ko_KR-iso2022-7%UTF-8.so
# ln -s ko_KR-euc%ko_KR-UTF-8.so ko_KR-euc%UTF-8.so
Alias database is missing entries. (bug 4343321)
A full dirsync does not finish successfully and no error message is generated. The result is an incomplete alias database which causes messages to bounce.The workaround is to set ioblocktimeout to 0 in slapd.conf.
An incomplete Dirsync error message (error 89) is generated after patch 108049-06 is installed. (bug 4347530)
The dirsync process issues an incomplete error message. This usually happens when dirsync has not been run often or for some time.The workaround is to set ioblocktimeout to 0 in slapd.conf
SIMS 4.0 + HA: tcp_smtp_server and ims_master dump core. (bug 4331992)
When using SIMS 4.0 + patch 05 + HA, error messages occur and tcp_smtp_server and ims_master processes dump core. The SIMS-HA server takes over for the other servers.The suggested workaround is to increase the stack size for the tcp_smtp_server program. This is done in dispatcher.cnf as follows:
[SERVICE=SMTP]
STACKSIZE=3072000
Multiple white space characters in subject header are compressed. (bug 4457457)
As per RFC 2822 this is not a bug. Some mail user agents (for example, the Japanese version of WinBiff) insert CRLF in the header fields into field bodies. As per RFC 2822 MTA's are allowed to unfold the header fields by simply removing the CRLF that is immediately followed by white space. Programs should not depend on the unfolded form of the header body when performing a syntactic or semantic evaluation of the header field.
A domain alias cannot be created when using Netscape Directory Server. (4484761)
For this problem, the workaround is as follows:
Add the following lines to the sims.oc.conf file:
objectclass aliasObject
superior alias
requires
dcRun the following command in order to restart Netscape Directory Server:
serverRoot/slapd-instance/restart-slapd
Known Limitations and Considerations
This section describes known software limitations and considerations in the 09 revision of the SIMS 4.0 product patch.
The imadmin modify user command refuses to add mail alias (duplicate mail address). (bug 4327947)
The modify user command will not add mail aliases to the LDAP database in SIMS 4.0.In the following scenario, which replicates the problem, sun.com is the domain in the LDAP database:
dc=sun, dc=com, o=internet The following definitions are set up with the Administration GUI:
If an alias is added to an established user with the following imadmin input file an error message is issued.
l user2
d sun.com
q user1@somewhere.deThe following error message is a result:
/opt/SUNWmail/sbin/imadmin modify user -D siteadmin -w secret -i infile
Invalid attribute: rfc822MailAlias. Duplicate mail address found.
DM console interprets group owner's LDAP syntax as CES by mistake. (bug 4341403)
The DM console erroneously interprets group owner's LDAP syntax as CES. SIMS displays an error message and it is no longer possible to modify a group.The DL name field is also null at times.
Seen mail is imported as unseen mail by imimportmbox. (bug 4324690)
When importing mbox from /var/mail by imimportmbox, seen mail is imported as unseen mail when accessed from the pop client. This does not occur with the IMAP client.
The imaccessd utility dumps core when server certificates have expired. (bug 4303035)
If the server certificate used by SIMS has expired, imaccessd dumps core each time an ssl connection is attempted.
The maximum quota size for a family account is exceeded. (bug 4300888)
The quota size for a family account can be exceeded. When a family member's quota size is changed, the quota size for the family account is not recalculated.The quota for the Family Account is not enforced by SIMS. However, this over quota condition can be detected by imquotacheck.
Domain quota limits are not enforced. (bug 4295401)
Domain Quota Limits are not enforced in this version of the product due to the following technical issues and performance trade-offs:
The LDAP server does not support transaction locking; therefore, the quota counts are subject to race conditions and may not be accurate.
The operation of the DM is hampered. When a user logs in, the DM counts the number of users and distribution lists in the directory by searching for all of them. If there are a lot of users, this can take a considerable amount of time. Additionally, as the number of users approaches the quota limit, the DM recounts the number of users.
The imta dirsync utility takes a long time when migrating from SIMS 3.5 to 4.0. (bug 4279420)
The lookthroughlimit attribute cannot handle a value of -1; if this attribute is set to -1, the indices will be skipped. By default, this value should be set to at least one million (1,000,000,000). This attribute is located in the slapd.ldbm.conf file.
# /opt/opt/SUNWconn/bin/ldapsearch -b o=internet uid=siteadmin rfc822mailalias mail
cn=Site Administrator,ou=People,dc=mydomain,dc=com,o=internet
mail=siteadmin@mydomain.com
rfc822mailalias=siteadministrator@fujitani.mydomain.comGiven this information, the following would work:
##/opt/SUNWmail/sbin/immonitor access -u siteadmin@mydomain.com -L fujitani.mydomain.com ## /opt/SUNWmail/sbin/immonitor access -u siteadministrator@fujitani.mydomain.com -L fujitani.mydomain.com
However, the following would not:
#/opt/SUNWmail/sbin/immonitor access -u siteadmin@fujitani.mydomain.com -L fujitani.mydomain.com Neither the mail nor the rfc822mailalias contain an entry for siteadmin@fujitani.mydomain.com in the LDAP directory on fujitani.mydomain.com on port 389.
Domain-specific default quotas cannot be set. (4450915)
If you have hosted domains and want to set a mail-account quota for a specific domain, you will not be able to. Hosted domains use the system-default quota, which is the value of the ims-default-quota attribute located in the ims.cnf file. The mailquota attribute in the domain entry does not work as expected and cannot be used to set quotas for hosted domains.
Internal delivery notification messages are not sent to delegated domain postmasters. (4407623)
Delegated domains enable multiple domains to coexist on one physical messaging host. Each delegated domain has a corresponding postmaster. The expected behavior is for a delegated domain's postmaster account to receive delivery notifications for its users when the incoming messages for those users originated from another MTA.Delivery notifications for messages being delivered into a delegated-domain-member mailbox should be delivered to the delegated domain's postmaster, but they are not. Instead, these inbound delivery notifications are sent to the SIMS default postmaster account.
SIMS does not support non-ASCII characters in the client and administration tools. (bugs 4284794, 4479044)
Do not use non-ASCII characters, such as Japanese characters, in Web Access, Administration Console, or Delegated Management Console. Notice, though non-ASCII characters are not supported, you will not receive an error message if you attempt to use them.
Documentation Updates
This section describes the updates for SIMS 4.0 documentation.
Description of headerset8 is missing in SIMS 4.0 documentation. (bug 4299541)
The following information was not included in the SIMS 4.0 Reference Manual. The headerset8 channel keyword is designed to allow non-ASCII message headers to be delivered without RFC2047 encoding. This is popularly referred to as "Just Send 8" message headers. Setting headerset8 on the destination channel will cause SIMS to remove the MIME encoding on the Subject: lines and on other unstructured text header lines, including headers containing addresses.When "Just Send 8" messages are submitted to the IMTA, the source channel normalizes the headers into RFC2047 format. The definition of the charset tag depends on the configuration of the source channel. If the source channel is unmarked, the charset label is set to UNKNOWN. In theory, by setting headerset8 UNKNOWN on the destination channel, the headers would be restored to their original un-encoded form.
Normally headerset-originating decoding or any other kind of header decoding is not performed from the UNKNOWN character set. A code change in SIMS 4.0 consists in allowing UNKNOWN charset decoding when configured by the user through a headerset keyword. A plausible but untested workaround would be to use the charset8 channel keyword on the source channel to set a fictitious character set:
then set the headerset8 on the destination to the same value. To prevent the fictitious name from appearing in the Content-Type field, it would be necessary to set up a charset conversion relabelling operation.
Correction to documentation on dns_verify arguments. (bug 4328992)
In the SIMS 4.0 Administrator's Guide, DNS-based Email Access Control is described on pages 128-132. The following corrections to the text should be noted:Page 128, the 4th paragraph should read:
Given a domain, the dns_verify program queries the DNS to check if either an A record or an MX record exists for the domain. Then depending on the way you configure it, the host can be accepted or rejected.
Page 129, dns_verify Arguments, should read:
The arguments to dns_verify have four parts delimited by '|' as shown below (or delimited by another character if | is part of the template, see more examples later using + as the delimiter):
hostname|return-if-good|return-if-bad|return-if-indetermined
The return-if-good and return-if-bad and return-if-indetermined strings are templates for the return string. If hostname has a valid DNS entry, the return-if-good template is used to generate a return string; if the DNS server returns an authoritative "host not found" error, then the return-if-bad template is used to generate a return string; return-of-undetermined template is used if the dns lookup gives a SERVFAIL or other "indeterminant" error, meaning we can NOT determine if the host name exists in the DNS or not.
If the return-if-undetermined template is not given, you only use the three parts of the argument:
hostname|return-if-good|return-of-bad
then in the case of undetermined returns from the DNS lookup, return-if-good is used.
Example
$2|$$Y|$$NInvalid$ host:$ $$2$ -$ %e|$$NCannot$ look$ up$ host:$ $$2$ -$ %eOn page 128, in the example boxes, a blank line is required after the ORIG_SEND_ACCESS line, and the rest of the lines need to be indented.
On page 130, in the example box, a blank line is required after the PORT_ACCESS line, and the rest of the lines need to be indented.
Additional information about imta.cnf channel blocks. (bug 4335729)
It is possible to configure the MTA to advertise a name other than the default hostname in the SMTP banner and the HELO and EHLO messages. In the channel block, the line which the SIMS documentation calls the "routing system identifier" can do this:
! tcp_local
tcp_local smtp single_sys ...
tcp-daemon zortch proxycache.labnet.east.sun.comHostname "zortch" will now be used in the SMTP banner and the HELO and EHLO messages.
The imquotacheck man page is missing -f option. (bug 4334742)
The imquotacheck command sends an email warning to users who are approaching their mail store quota. This command can be put in a cron file to provide a daily check on mail store users. You can configure the desired warning message using the -f flag for imquotacheck.
An imsauth(5)Man Page change is needed. (bug 4320666)
A new member, internal_id, was added to auth_user_info structure. It is to be ignored by the library author. The complete list of members is:In addition, make note of the following correction:
The last five fields of the structure should be ignored by the library author. They are all related to /var/mail mailboxes, and this is not supported for the imsauth plug-in interface. The last one, internal_id, is for Sun's internal use only.
The SEND_ACCESS mapping is missing from SIMS 4.0 documentation. (bug 4265689)
The following information was not included in the SIMS 4.0 Reference Manual. The mappings file, /etc/opt SUNWmail/imta/mappings includes a SEND_ACCESS table by default. The SEND_ACCESS or ORIG_SEND_ACCESS mapping table may be used to control who may or may not send mail, receive mail, or both. If a SEND_ACCESS or ORIG_SEND_ACCESS mapping table exists, then for each recipient of every message passing through the IMTA, the IMTA will probe the table with a probe string of the form (note the use of the vertical bar character):src-channel|from-address|dst-channel|to-address
src-channel is the channel originating the message (i.e. queueing the message): from-address is the address of the message's originator; dst-channel is the channel to which the message will be queued; and to-address is the address to which the message is addressed. Use of an asterisk in any of these four fields causes the fields to match any channel or address as appropriate.
Now, if the probe string matches a pattern (i.e., the left hand side of an entry in the table), then the resulting output of the mapping is checked. If the output contains the metacharacters $N, then the enqueue to that particular address is rejected. In the case of a rejection, optional rejection text may be supplied in the mapping output. This string will be included in the rejection message. If no string is output (other than the $N metacharacter), then a default message will be used.
Suppose that local users in the domain acme.com, with the exception of the postmaster, are not allowed to send mail to the Internet, but can receive mail from there. Then the SEND_ACCESS mapping table shown below is one possible way to enforce this restriction. In that example, the local host name is assumed to be acme.com. In the channel name tcp_*, wild cards are used so as to match any possible TCP/IP channel name. In the rejection message, dollar signs are used to quote spaces in the message. Without the dollar signs, the rejection would be ended prematurely and would only display the message "Internet" instead of "Internet postings are not permitted."
*|postmaster@acme.com|*|* $YN00kIe
1|*@acme.com|*tcp_*|* $NInternet$ postings$ are$ not$ permitted
Two configuration options have been added to the dirsync.opt configuration file. (bug 4399599)
The following was a problem that has been fixed:A full dirsync does not update the profile database time stamp correctly and may set it to 0. This can result in incremental dirsync to perform very large LDAP searches that can result in unacceptable load on the LDAP server. In fixing this problem, two configuration options have been added to the configuration file dirsync.opt. They are:
LIMIT_SEARCH=[TRUE|FALSE], where TRUE is the default when missing
LIMIT_SEARCH_TIME=time, where time is measured in seconds and 86400 is the default when missing.The LIMIT_SEARCH option places a limit on the maximum duration used by incremental dirsync. If the limit is set to true, then LIMIT_SEARCH_TIME allows you to set how far back in time, relative to the current time, you want to limit the LDAP search performed by incremental dirsync.
A new option has been added to the autoreply_option file. (bug 4439022)
The autoreply program by default only relies on the local part of the incoming header To: or Cc: address to determine whether the user is the intended recipient and, therefore, if the autoreply message should be sent to the sender. For example, the program relies on user, instead of user@sesta.com.However, some sites want to use the full header To: or Cc: address. To enable this, a new option, check_fulladdr, has been added to the following file:
/etc/opt/SUNWmail/imta/autoreply_option
When this option is set to 1, the program ensures that the user is the intended recipient by doing a comparison check using the full address from the To or CC header fields of the incoming message. When this option is absent or the value is set to 0, which is the default, the program does a comparison check using only the local part of the address from the To or CC header fields of the incoming message.
Users do not have to log in as root in order to use the imadmin command. (bug 4451589)
Web Access Updates
This section describes the updates for the Web Access client.
Login separator inconsistency. (bug 4250347)
In the case where Web Access and SIMS are installed on the same system at the same time, the SIMS installation mechanism configures the separator for both Web Access and SIMS. The only way the separator can be different in this case is if the administrator intentionally changes it after installation.In the case where SIMS and Web Access are installed on separate systems or at different times, the SIMS installation GUI is used to install both components and configure the separator for both. The administrator can specify different separators in this case.
If the login separators are different for SIMS and Web Access, a user may be able to successfully log into Web Access, but cannot read mail.
Enabling instances via Sun Web Server 2.1. (bugs 4250317, 4250498)
In order to start and stop the Web Access server using the htserver command, the instances must be enabled via the SWS2.1 (Sun Web Server):
# htserver enable sws_server
# htserver enable admin
# htserver enable WebAccessYou may now stop and start Web Access:
# htserver stop WebAccess
# htserver start WebAccess
Starting and stopping web access
You can start and stop the Web Access server using the webaccess start and webaccess stop commands (using SIMS 4.0).To stop the Web Access server:
# /etc/init.d/webaccess stop To start the Web Access server:
# /etc/init.d/webaccess start
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated August 30, 2001