Sun Internet Mail ServerTM 4.0 Product Update |
This product update reflects changes made to the SIMS 4.0 release introduced by the 05 revision of the SIMS product patch (108049-05 for SPARC and 108050-05 for Intel). The product update notes cover installation and software bugs for SIMS 4.0. The patch update process is outlined as follows:
|
Read through this Product Update. |
|
Obtain the software patches from SunSolve. |
|
Install the new software patch on the system running SIMS 4.0. |
Items covered in this product update are cumulative from the initial release of SIMS 4.0.
This section describes updates and workarounds for the known problems that occur during installation and initial configuration.
Description: 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 could not be properly created.
Workaround: Before installation, set the root umask to 227 (read, write, and execute permission for owner; read and execute permission for group and other).
Description: Bringing up the SIMS Admin Console with the Netscape browser 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.
Workaround: Restart slapd before starting the SIMS Admin Console:
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:
Jun 21 10:50:02 slim SUNWmail.ims.imta_dirsync[6399]: Fatal error
Note - After the error, installation proceeds and finishes successfully.
A dirsync cron job is set up by the postinstall script of SUNWimimo package. This job is set to execute at 10, 30 and 50 minutes 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.
After uninstalling SIMS 4.0, certain files associated with Web Access and Sun DS 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:
|
/var/opt/SUNWconn |
|
/opt/SUNWconn |
|
/opt/SUNWa |
You can remove these files and directories with the rm -rf command.
SunCluster Patch will not work on systems with SIMS 4.0 with HA and the Netscape Directory Service (NSDS) unless the modifications described in this note are made to the SIMS and SunCluster configuration. The patch location is:
http://sunsolve.Central.Sun.COM/cgi/retrieve.pl?type=0&doc=patches%2F108109&zone_32=108109
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.
| 1. | Install this patch on both cluster nodes. |
| 2. | Run /opt/SUNWcluster/bin/hadsconfig 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." |
| 3. | 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. |
| 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". |
| 4. | Re-register and re-start both nsldap and SIMS data services. |
| 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: |
3. Register the NSDS/HA service:
| # /opt/SUNWhadf/bin/hareg -s -r nsldap |
4. Start the NSDS/HA service:
| # /opt/SUNWhadf/bin/hareg -y nsldap |
5. Re-register the SIMS/HA service:
| # /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 |
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:
3. Stop the NSDS/HA service:
| # /opt/SUNWhadf/bin/hareg -n nsldap |
4. Unregister the NSDS/HA service:
| # /opt/SUNWhadf/bin/hareg -u nsldap |
This section describes known software limitations that are fixed and software updates that are introduced by the 05 revision of the SIMS 4.0 product patch.
Simple Family Accounts enhancements have been added to the Delegated Management Console.
Through the DM Console, an administrator has the ability to:
|
Create, modify, or delete a Family Account |
|
Define or modify a family head |
|
Define or modify the services for each Family Account |
|
Define or modify the maximum family size |
|
Define or modify the maximum family quota |
|
Generate a Family Account report |
Also through the DM Console, a family head has the ability to:
|
Create, modify, or delete a family member |
|
Define or modify the services for each family member |
|
Generate a Family Account report |
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.
The imrestore utility does not work on the x86 platform. The following errors result:
* LOG [ERR]: Incorrect block number read (11884434125920141313). Should have been 1
* LOG [ERR]: Restore failed..
The LIST and LSUB commands do not check for an asterisk (*) or a percentage sign (%) in non-quoted folder names. If a folder name contains one or more of these characters, it is not listed in a LIST or LSUB response.
The ims_apop_authenticate function returns only the user name and not the domain name.
The POP client hangs while downloading messages with attachments through the proxy.
Once a distribution list gets to be too large, you cannot add any more users through the Delegated Management Console.
When you access the Delegated Management Console as a delegated site admin, the domain information table gives values of unlimited even though there are values set for the domain.
You cannot edit or search for a user with a space in the last name using the Delegated Management Console.
The ^M characters in the message file cause immonitor-queue to generate improperly formatted output.
Create a new user, then subscribe to any number of distribution lists. Login to the Delegated Management Console using Internet Explorer 5.0, go to the "My Distribution List Subscriptions" page, then click Search.
The search result is displayed abnormally.
In the Delegated Admin, the toggle button on the Create Distribution List page to go from "Show Advanced" to `Show Basic" does not work.
The non-active status of a domain does not work; only active status works.
Login to the Delegated Management Console, click the Edit User bar and enter an asterisk (*) in the Login ID field to bring up all users. After you click Search, an error message appears:
The server encountered an internal error and was unable to fulfill the request.
Using imadmin change user to change the password for siteadmin breaks the Delegated Admin:
siteadmin@east.sun.com: password file modify failed.
At this point, it is possible to log into the SIMS Admin GUI, but you cannot log into the Delegated Admin.
The workaround is to change the permissions on /etc/opt/SUNWmail/simsr.cnf to 777 before running imadmin modify user, then changing the permissions back to 600 after you change the password.
If a backup group does not contain any users, imbackup -g backs up all of the users in the message store.
An IMAP client (for example, Eudora PRO for Windows) dumps core when a user uses a variety of search parameters and filters.
The imcheck utility reports errors when there are no errors. This happens when there are many extra buckets for a particular day.
Previously, report information (for example, the maximum number of users) was not shown in the Edit Properties page of a Family Account.
The following items have been added to that page:
|
Billable User |
|
Maximum Number of Users |
|
Maximum Group Quota (in bytes) |
If a Family Account is marked as inactive with the groupstatus:inactive parameter, it is still possible to change various properties for that group, like its description, or to create, delete, and edit its members.
When a Family Account is created using the imadmin CLI (add mg), the Family Account's owner is created but not the Family Account. The workaround is described below:
| 1. | Create a new user who will be the owner of the Family Account: |
.# imadmin add user -D siteadmin -w secret -l scott -F scott -L Tiger -W secret
| 2. | Invoke imadmin add mg with the -l option, using the owner's UID as specified in the previous step. Additionally, some attributes need to be added to LDAP entry manually: |
# imadmin add mg -D siteadmin -w secret -G smith -l scott -A "billableuser:cn=scott Tiger (scott),ou=People,dc=Japan,dc=Sun,dc=COM,o=internet"
| 3. | Modify the LDAP entry of the owner of the Family Account. |
# imadmin modify user -A "memberofmanagedgroup:cn=smith,dc=Japan,dc=Sun,dc=COM,o=internet"
The imadmin CLI (add mg) creates the Family Account directly underneath the directory rather than the groups entry. This positioning will cause some problems in the future when data is migrated.
If the server certificate used by SIMS has expired, imaccessd dumps core each time an ssl connection is attempted.
The imrestore utility does not work with a core file. It will fail on a command similar to the following:
# imrestore -t 2 - < /net/<NFSServerName>/ore
For example, if you have 1 million users, and you run the dirsync -F command, about 10,000 of those users do not appear in the alias database.
When running imquotacheck the total amount shown for the domain is a negative
Domain Usage for xyz.com : -2118593267 Bytes
The sum of the quota sizes for each family member can exceed the maximum quota size for the family account. When a family member's quota size is changed, the sum of all the quota sizes is not recalculated.
The imadmin add user command yields an unknown error message:
setUserAttribute() null attr: Sun Internet Mail Server 4.0 Administrative CLI
user1@Japan.Sun.COM: user added.
Additionally, the imadmin delete, modify, and purge commands all have a missing space in their messages. For example:
smith@Japan.Sun.COMmanaged group purged.
Notice the missing space before the word "managed."
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
The ims_master utility dumps core when it attempts to deliver a malformed MIME message.
A domain created by the admin CLI (imadmin create domain) does not have the mailhosts attribute and are therefore not picked up by the imta dirsync.
The imexportmbox utility dumps core during migration. However; the same mailboxes can be backed up using the imbackup utility.
On the Forward page of the Delegated Management Console, the text for the following checkbox is misleading:
|
Deliver a copy to INBOX when forwarding |
This portion of the GUI has been changed and now contains three separate checkboxes:
|
Forwarding On |
|
Forwarding Off |
|
Deliver a copy to inbox when forwarding
e-mail
(Automatically selected if "Forwarding Off" is chosen) |
If you try to delete a user or a distribution list as the delegated administrator in the Delegated Management Console, you will receive error messages and the operation will fail. The workaround is to use the imadmin tool.
Additionally, the Delegated Management Console always shows "unlimited" for the following domain entries:
|
Disk quota |
|
Maximum number of entries |
|
Number of email accounts purchased |
In the Message Access section of the Administration Console, select "Both Connection" at the "Get Current Connection" button. An IMAP4 connection is expressed, but the connection button reads "IMAP4 Connection" when it should be "Both Connection."
If the imedit command is run (by either the super-user or a normal user) when the EDITOR environment variable is empty, the imedit command dumps core. You are prompted to enter the name of an editor, but no entry is accepted and imedit dumps core.
When imdelegatedmd is run from the command line, a line similar to the following appears in the output, revealing the siteadmin's password:
: LDAP_DN_PASSWORD = secret
The default value of the ALLOW_RECIPIENTS_PER_TRANSACTION parameter should be 32767. However, it is showing 0 in the 'Reject Msgs if no. of recipients exceeds' field in the channel propertybook.
Thus, when you change anything in the channel propertybook, be sure that 'Reject Msgs if no. of recipients exceeds' is set to 32767 or some other appropriate number.
Suppose you create a group using the imadmin-create-group command. If you do a search on this group, parentheses () are incorrectly inserted at the "cn" entry.
Then, you can login to the Administration Console and create another group with the same name, thus having two groups with the same name. Furthermore, once this occurs, you are unable to edit either one.
When adding users to a distribution list, it is sometimes not possible to add a user to the list. This occurs when the ID of the user you are trying to add matches a portion of an existing user's ID; for example, if user "josephine" already exists in the distribution list, then it is not possible to add a user "joseph" because it matches a portion of "josephine."
In the Delegated Management Console, a UNIX user who has a password containing less than four characters cannot change his/her own password.
If you send an email to multiple users, a single copy of that message is stored. If you backup this message and then attempt to restore your mailbox, additional memory is allotted for the storage of this same email message. The problem is that when a message is deleted and purged, imrestore does not reuse the same idir entry and is therefore unable to preserve the single copy characteristic.
If you use SIMS to store MIME messages, then some messages are not displayed correctly when they are downloaded.
The imadmin-purge-user utility does not work when using ims-bind. This is the case for both the default domain's user and a virtual domain's user.
The workaround is to add the following line to the ims.cnf file:
This instructs imaccessd to listen on the address 127.0.0.1, which imdeluser uses to connect to IMAP and delete the mailbox
The Calendar function is unavailable to virtual domain users (no Calendar icon appears).
A user or the administrator is unable to forward mail to the alias of a person within their domain.
If a user is created with /var/mail instead of the mail server, the user can telnet to the server and view the entire system with the following command:
list / *
The imimportmbox utility delivers messages that are not RFC 822-compliant to the message store.
The imimportmbox utility automatically changes the Content-type of the mail message to charset=us-ascii:
Content-Type: text/plain; charset=us-ascii
The imquotacheck program returns error code 70 (EX_SOFTWARE) even though the operation was successful. It should return EX_OK.
When the admin runs imexpire with the -s option, it sets the indexdir record in_use to 0 if it has not been read by the user. However, the impurge is supposed to reset indexdir to in_use, causing it to overwrite the next record.
The SMTP Header String in patch 03 contained the incorrect patch version number. See the last line in the sample below:
Received: from tiger.hi-ho.ne.jp (tiger.hi-ho.ne.jp [129.158.60.210])
by simsosaka0.hi-ho.ne.jp
(Sun Internet Mail Server sims.4.0.1999.10.12.12.11.p2)
Note that "p2" should be "p3".
The ims_master file contains hard-coded file names sims-ms.dat and sims-ms.idx.
The imadmin command cannot be invoked without either the -w or -W option.
After logging in to the Delegated Management (DM) Console as a user and waiting for the system to time out, the DM Console crashes if you try to do a search on a distribution list by clicking on either the "Edit Distribution List" or "My Distribution List Subscriptions" tab.
In the Administration Console, if you select Admin Console->IMTA->Incremental Alias Synchronization Schedule and perform the following:
|
Change the status to Active then click Apply |
|
Change the status back to Inactive then click Apply |
you will receive the following error message: "The Incremental dirsync task was not created by admin server, it was manually added to the crontab. Can not save the changes." even though no manual changes were made.
Domain Quota Limits are not enforced in this version of the product due to the following technical issues and performance trade-offs:
|
The ldapserver 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 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 50,000. This attribute is located in the slapd.ldbm.conf file.
Additionally, there is an existing bug with case sensitivity of the attribute names in slapd.ldbm.conf. Directory Server slapd cannot distinguish the difference between modifytimestamp and modifyTimeStamp.
The immonitor access command can be invoked using -u uid@hostname.domain only when the "mail" or "rfc822mailalias" LDAP attributes contain the same uid@hostname.domain value.
For example, assume that "fujitani" is the hostname and "mydomain.com" is the DNS fully qualified domain name. First, check the values for "mail" and "rfc822mailalias":
# /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.com
Given 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.
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.
The Administrator cannot create a group containing only external members. If this user attempts to do so, he/she will receive the "Create group failed" message.
Additionally, the administrator cannot remove all internal members from a group. If this user attempts to do so, he/she 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 removing a required attribute so that it reads:
objectclass groupOfNames
requires
cn,
objectClass
allows
member,
businessCategory,
description,
o,
ou,
owner,
seeAlso
The imbackup utility does not backup Shared folder. For example, take the following command:
where /tmp/username is a group members list who used the Shared folder. After invoking imrestore, the group members' Inboxs are restored, but the Shared folders are not.
To workaround this problem, use distribution lists instead of Shared folders.
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:
|
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. |
The disadvantages of using a logging file systems in SIMS are:
|
Message store performance may be somewhat affected due to file logging overhead. |
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:
! tcp_etrn_dom1
tcp_etrn_dom1 smtp single_sys subdirs 20 copywarnpost copysendpost postheadonly immnonurgent noreverse logging notices 1 2 4 7 blocklimit 10240 charset7 US-ASCII charset8 ISO-8859-1 slave
tcp_etrn_dom1-daemon <fully qualified SIMS host>
(note: the tcp_ertrn_dom1 smpt single_sys... 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.
When using SMTP AUTH, the same mechanism that is used by the Message Access to retrieve a user's credentials in the directory is used when interpreting the identity in the AUTH command issued by the client. In particular, the domain from IP mechanism uses the same set of parameters in /etc/opt/SUNWmail/ims/ims.cnf.
SMTP AUTH now supports CRAM-MD5 SASL mechanism with the following restrictions:
|
When using Sun Directory 3.1, the passwords of the users have to be stored in the directory in clear or using the {sunds} encryption (default). |
|
When using the Netscape Directory, the passwords have to be stored in clear text in the directory. |
To turn on the CRAM-MD5 mechanism, set the following option in
/etc/opt/SUNWmail/imta/option.dat:
SMTPAUTH_USECRAMMD5=1
This section describes how to add SMTP over TLS to SIMS.
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:
|
Connecting to a TLS enabled port where TLS negotiation happens immediately once the TCP connection has been established. |
|
Connecting to a "regular" port and then issuing a STARTTLS (RFC 2487) command to begin TLS negotiation. |
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.
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 the 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.
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 an 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.
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:
|
Any subscriber connecting from outside the intranet must use TLS. |
|
Any subscriber connecting from inside the intranet may use TLS. |
The system can be configured as follows (only the main keywords are shown):
in imta.cnf:
tcp-daemon
tcp_intranet smtp mx single_sys maytlsserver tlsswitchchannel tcp_tlstcp_intranet-daemon
tcp_tls smtp mx single_sys musttlsservertcp_tls-daemon
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 (tlsswitchchanneltcp_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 purpose).
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 him, but he doesn't have to use it (maytlsserver keyword). If he issues the STARTTLS command, he will be switched to tcp_tls.
Of course a publicly referenced SMTP server (MX recorded) shouldn't use this kind of configuration.
Example 2
A site that generally blocks SMTP relaying through their 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 to do the same.
In imta.cnf:
tcp_auth smtp mx single_sys mustsaslservertcp-auth-daemon
with an ORIG_SEND_ACCESS mapping table (/etc/opt/SUNWmail/imta/mappings) like this:
tcp_local|*|tcp_local|* $NRelaying$ not$ permitted
For 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:
tcp_tls smtp mx musttlsserver maysaslserver saslswitchchannel tcp_authtcp_tls-daemon
tcp_auth smtp mx mustsaslserver musttlsservertcp-auth-daemon
with an ORIG_SEND_ACCESS mapping table
(/etc/opt/SUNWmail/imta/mappings) like this:
A 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 (tlsswitchchanneltcp_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:
l noswitchchannel...myhost.a.com
tcp_local switchchannel smtp mx maytlsserver tlsswitchchannel tcp_tlstcp-daemon
tcp_tls smtp mx musttlsserver musttlsclienttcp_tls-daemon
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.
When using a remote directory, if the time of the directory server and the SIMS server are not synchronized, it is possible that incremental dirsync might not pick up all changes in the directory. In such cases, these changes will be reflected in the MTA tables only after the next full dirsync.
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:
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):
$DATE
Current date in RFC 822 format
$STOREOWNER
Message store owner
$USERID
User's message store userid
$QUOTA
User's quota limit
$PERCENT
Percent used
$USAGE
Current disk usage for user
The following is an example <msg-file> (quota.msg):
Dear $USERID,
Your total mailbox size has exceeded $PERCENT% of the assigned quota:Mailbox size = $USAGEQuota = $QUOTA
Thanks for using our email server.
Your email administrator
Using the above quota.msg file, the following command can be executed:
The following is the example output:
Dear joe,
Your total mailbox size has exceeded 100% of the assigned quota:Mailbox size = 5039Quota = 5000
Thanks for using our email server.
Your email administrator
This section describes the updates for the Web Access client.
When a user's vacation mail is set and enabled, sending mail to this user creates a mail message issued by the autoresponder which does not contain the MIME-version header for the message, making it a non-compliant MIME message.
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 in to Web Access, but cannot read mail.
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):
You may now stop and start 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:
To start the Web Access server:
Garbled characters in uninstall process
(Bug4318920)
If you uninstall SIMS from zh locale, some characters
get garbled.
Work around: Uninstall SIMS4.0 on C locale
or ignore the garbled characters.
Cannot select Channel type when creating
a new channel (Bug4322191)
When creating a new channel from IMTA, the channel
type cannot be selected.
Work around: No work around exists.
Cannot open the LDAP statistics window(Bug4320949)
From Admin console, goto Sun Directory Service, then
click "Show Statistics" button. It will throw the
java.lang exception error.
Work around: No work around exists.
Problems in sending Chinese mail (Bug4331539)
There is a problem when handling mail with Chinese
characters on zh locale.
Work around: Stop the web access, change to
C locale, start web access again.
The day string in Chinese is incomplete in calendar day and year view (Bug4330099)
On calendar day and year view, since the day string
length is limited, the day in Chinese string get cut off
Work around: No work around exists.
Subject disappears if sending a mail with more than 22 chars on subject field (Bug4347889)
When sending a mail with more than 22 Chinese characters
in the subject field, the subject will disappear
on the receiving mail box. It will cause problems
in opening the mail.
Work around: Ensure that the subject field
has less 22 Chinese characters.
Default auto reply message is missing if a user is created from the admin console (Bug4349353)
Create a user from Admin console. Logon the new user
to delegated admin. The default auto reply
message is missing.
Work around: Create the message, then save
it.