                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO7
                                    4/17/98

MailWorks for UNIX V2.0, ECO7 includes all of the changes incorporated
into ECO1-ECO6.  The release notes for those ECOs are included at the end
of this document.  The changes introduced in ECO7 are described below.

IMPORTANT: Because of internal changes in Digital UNIX version 4, the
requirements for operating system tuning are different from Digital
UNIX version 3.2.  Please use the following table of parameters instead
of the table printed in the MailWorks manual:

  Users      maxusers   vm-vpagemax  vm-mapentries
  0-63         200         64000         400
  64-199       512        131072        1024
  200-499     1024        214748        1024
  500-999     1800        322122        2048
  1000+       2048        322122        4096
  
  maxusers is set in /usr/sys/conf/YOURHOSTNAME
  
  vm-vpagemax and vm-mapentries are set in /etc/syscofigtab, with an
  entry of the following form:
  vm:
  	vm-vpagemax = 322122


With ECO7, MailWorks has been made Year 2000 compliant.

ECO7 will now be supported on Digital UNIX Version 3.2C-3.2G, or 4.0B and 
later, although we strongly recommend 4.0D (build 878) or later.  If you use 
4.0B or 4.0C, you should install the latest patches, since they resolve some 
problems with the threads system which could affect MailWorks.

MailWorks has been tested with the following versions of other
components, and we recommend that you upgrade to these versions:
  X.500, version 3.1-2
  MAILbus400, version 2.0-1
  InfoBroker Version 2.2 (To be available on the April Layered
      Products CD)
Note that a few minor problems were found with MailWorks on UNIX 4.0, so
if you are still running an earlier ECO of MailWorks, we recommend that
you upgrade to ECO7.

MailWorks now handles ISO Latin-2 character sets as follows:
* For outbound X.400 messages, MailWorks now properly declares ISO-Latin2
  in the character set repertoire, and properly maps ISO-Latin2 characters
  in Teletex fields.
* For inbound X.400 messages, General Text bodyparts encoded in ISO-Latin2
  will be recorded as MailWorks PlainText bodyparts, so that they will be
  readable by ordinary message viewers
* For inbound MIME messages, MailWorks now accepts messages that declare
  ISO-Latin2 in header fields.
** Note: if your system normally operates with ISO-Latin2, and if you
routinely generate MIME messages, you may want to change the mapping of
PlainText in the file /usr/opt/DMW/Enclosures/.dmw_mime_send_map

A few problems were fixed that could cause the mcs or x488 processes to
report illegal instructions and/or segmentation faults in the log file.

In rare circumstances, it is possible to receive a heavily forwarded
message (often from the internet) which will cause the mss server to fail.
To combat this problem, we recommend that you place the following line
into the file /usr/opt/DMW/MAILworksrc:
set RMESOCK_THREAD_STACK_SIZE=84480

Starting with ECO7, when submitting a message to X.400,  MailWorks will
no longer supply the MTS_ID (envelope ID), but will rely on MAILbus 400 
to generate this ID.    This will insure unique Local Identifiers on
all X.400 messages.   
	


                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO6
                                    12/9/97


MailWorks for UNIX V2.0, ECO6 includes all of the changes incorporated
into ECO1-ECO5.  The release notes for those ECOs are included at the
end of this document.  The changes introduced in ECO6 are described
below.

The msr process has been made multi-threaded.  This means that some
operations (such as the receipt of an X.400 message with a large
distribution list), will no longer cause the entire system to pause.

Under unusual circumstances, it was possible for the mcs process to stop
responding for 2 minutes while waiting for a lock to free up - after the
2 minutes the server would begin operating normally.  This 2 minute
"smoke break" has been eliminated.

The MIME encoding logic now properly handles equal signs when the
bodypart is encoded with quoted printable encoding.

Eliminate the corruption of text bodyparts in draft messages and
revisable text documents which are updated in place.

A number of changes designed to increase the reliability of the server,
including the elimination of a problem that would cause the mcs to "spin",
i.e. consume large amounts of CPU time.

The server processes have improved the handling of signals from the
operating system reporting that a child process had completed.  The
handling of the signal will no longer cause corruption of the parent
process (usually the mcs or the mss process).

MailWorks now properly handles forwarded messages received from SMTP
where the embedded message is encoded differently from the enclosing
message; this had been seen in messages forwarded from ALL-IN-1 through
the SMTP gateway.


                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO5
                                    6/16/97

MailWorks for UNIX V2.0, ECO5 includes all of the changes incorporated
into ECO1-ECO4.  The release notes for those ECOs are included at the
end of this document.  The changes introduced in ECO5 are described
below.

* When a user with read-only access opened an Excel spreadsheet in
  a shared drawer, the server would continuously make a copy of that
  spreadsheet in the MailWorks temporary directory, which in turn
  would exhaust space on that file system.  Note that this occurred
  *only* with Excel, and *only* if the user did not have write privileges
  to the drawer containing the spreadsheet.  Starting with ECO5,
  the server will leave only one or two copies of the spreadsheet
  in the temporary directory - these files will be cleaned up when
  MailWorks is stopped and restarted.
  (IPR 1694)
  
* Additional file types have been added to the MIME send and receive
  maps, and a number of file types (including Office 97 documents)
  have been added to the /usr/opt/DMW/Enclosure/DB file.
  
* The mss process correctly handles a timeout situation when attempting
  to open a message store.  Starting with ECO3, if a timeout occurred
  opening a message store, the message store would become corrupted.
  (IPR 1700)
  
* The mcs process will no longer allow a client to open a folder if there
  was a problem attempting to open a drawer.  Previously, the mcs process
  would log a segmentation fault.
  
* The mcs process now properly handles a NULL value for an ldap attribute.
  Previously, the mcs process would log a segmentation fault.
  (IPR 1695, 1702)
  
* If the server is configured to send messages using UUEncoding (i.e.,
  sendMime is FALSE or is not present), and if a MIME message is
  received then forwarded, the server now removes the MIME version header
  from the forwarded message.  This was making the forwarded messages
  unreadable.
  (IPR 1693)
  

New Features
------------

* A new MAILworksrc parameter, addUuencodeFileName, has been added. The
  default value, TRUE, indicates that when MIME is not being used, and
  when a filename is availble from the client, that filename will be
  used in UUEncoded attachments placed on outgoing messages. The value
  of FALSE indicates the form Enclosure1 will be used as a name in
  UUEncoded attachments.
  
* When using TeamLinks clients, find by a range of dates is implemented.

* ECO3 introduced a timeout on opening a message store.  By default,
  this timeout is 10 seconds, which is a reasonable value when all
  message stores are private message stores.  However, if your
  configuration uses one or more shared drawers, then users are much
  more likely to encounter a conflict opening a message store.  In
  this case, you should set the MAILworksrc parameter lockMSTimeout to
  30 or even 60.

* ECO5 introduces a change to the handling of lines of text that begin
  with hyphens. Prior to ECO5, MailWorks implemented the behavior
  specified in RFC934, specifically:
  1) If a message was received containing a text bodypart with a line that
     began with exactly two hyphens, those two hyphens were considered a
     bodypart separator, and MailWorks would generate two (or more)
     separate bodyparts.
  2) Because of that, in an outgoing message, if a line that began with
     more than one hyphen was encountered, a single hyphen and a space
     were inserted at the beginning of that line.
  3) Conversely, if an incoming message contained a line that began with a
     hyphen followed by a space, the hyphen and the space were stripped
     from the line.
   
  (Note that this behavior took place only when the message was not MIME
  encoded, and did not include an Encoding header.) Starting with
  ECO5, this behavior is optional, and by default, it does not take
  place.  If the behavior specified in RFC934 is important to you, it
  can be restored by entering the following line into the file
  /var/opt/DMW/MAILworksrc: splitBodyparts=TRUE
  
Performance Useage Notes:
------------------------
MailWorks for UNIX uses standard TCP connections for communication among
the different processes that make up MailWorks for UNIX.  It is possible
to configure TCP to handle that communication more efficiently when two
processes communicating are in the same system.  If your node address is
16.99.16.99, then you should add the following entry to the file
/etc/routes:
   16.99.16.99 localhost
This will take effect on the next system restart; to have this take effect
immediately (but only until the next restart), you can also enter the 
UNIX command:
    route add 16.99.16.99 localhost
Note that in some cases when the network is busy or noisy, this change
can reduce the number of communications-related errors reported in the
log files.

By default, most MailWorks processes locate the msr process using a TCP
broadcast mechanism; this consumes a small amount of network resources,
and can introduce a small delay in starting processes.  For the best
performance, edit the MAILworksrc file, and replace the following line:
   #msrHost=<broadcast>
with an entry of the form
   msrHost=my.host.name.com
As with the localhost optimization above, this can reduce the incidence
of errors in the event that your network is busy or noisy

Finally, whether you use SMTP or X.400 primarily, we strongly recommend
that you configure MailWorks to perform optimized local delivery; look
in the MailWorks Admin guide for the description of the MailWorksrc
parameters localSMTPAddresses and localX400Addresses.  This will reduce
both the elapsed time to deliver a message, and the CPU time required to
deliver the message.  For messages sent over SMTP, it will eliminate an
invocation of sendmail and inetgrecv for every message sent - this also
reduces the load on your server system.


                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO4
                                    4/10/97

MailWorks for UNIX V2.0, ECO4 includes all of the changes incorporated
into ECO1-ECO3.  The release notes for those ECOs are included at the
end of this document.  The changes introduced in ECO4 are described
below.

* A problem in which the mss server could become unresponsive when the
  user of a MAPI-based client successively deleted nested folders has been
  fixed.
  
* Several problems that could lead to the mcs or the mss server
  becoming unresponsive or to crash have been fixed.
  (Problem 3900, 4884, 5197, 5008, IPR 1664, 1673, 1681)

* When a corrupted message store is encountered by the mss server, it now
  properly closes the message store file.  Prior to this, it was possible
  for the system to report "too many open files".  Often this report would
  appear in the lsfd log file, when lsfd continued to attempt to deliver
  a message into the corrupt message store.
  
* Occasionally, the command line command resend would send the message
  to the original recipients of the message rather than the newly specified
  recipient - this has been corrected.  (Note that this affected only the 
  command line command resend - the forward command has always worked 
  properly from all clients.
  (Problem 3121)

* x488grecv now properly handles messages with bodyparts with a length
  of zero.
  (IPR 1660)
  
* When the MAILbus400 MTA is disabled, or otherwise unavailable, x488grecv
  will now check whether the MTA has become available every 30 seconds
  rather than every microsecond; this will significantly reduce the number
  of log entries while the MTA is unavailable.  If you would prefer to 
  adjust the 30 second retry interval, set the parameter mtaRetryInterval 
  in MAILworksrc.  For example, to set it to 10 minutes, include the line:
  mtaRetryInterval=600
  (IPR 1655)
  
* When sendMIME is not set, or is set to FALSE, binary attachments are
  UUEncoded.  Prior to ECO4 the filename incorporated into the UUEncoding
  was of the form Enclosure1.  Starting with ECO4, the original file's
  filename will be included - this means that the recipient will see the
  full filename, including extension, and most PC clients will properly 
  recognize the type of the attachment.
  
* The utility mschk has been made more robust, to handle some additional
  forms of message store corruption.
  (IPR 1683)
  
* Previously, if a user of the motif client performed a folder query, then
  selected a query field, but did not provide a value for that field, the
  motif client would crash.  It now processes the query as though the field
  were not selected.
  

ECO4 introduces another change that is the first of two steps to fixing
another problem.  We discovered that the SMTP header fields in the file
/usr/opt/DMW/Enclosures/DB had been constructed incorrectly. (This is
the field used by MailWorks to construct the encoding header used in
SMTP messages when MIME is not used.)  To ensure interoperability among
different systems using MailWorks, the version of the DB file in this
release has defined synonyms for those fields, so that when the correct
values (introduced in a future release) are received by a system using
ECO4, they will be recognized and handled properly. We strongly
recommend that you install this DB file on all of your systems, even if
you do not update every system to ECO4 (simply copy the file
/usr/opt/DMW/Enclosures/DB from the newly installed system to replace the
same file on all of your older systems). In the next release or ECO, we
will provide a version of the DB file that uses the correct version of
the SMTP headers, but recognizes and properly handles the version of the
headers used in ECO4 and prior releases.

So, what problem are we fixing?  When a user of a MailWorks system that
is *not* using MIME sends a message with binary attachments to a user of
the Microsoft Exchange server or selected other mail systems, the other
mail system may not recognize that the binary attachment has been
UUEncoded.  The recipient will see the attachment as a text file
containing the UUEncoding rather than as the decoded binary file. If you
are seeing this problem, rename the file /usr/opt/DMW/Enclosures/DB that
is currently installed on your system, and replace it with the file
usr.opt.DMW.Enclosure.DB.new that is included in this kit. If you have
multiple MailWorks systems, and if you are not using MIME, you will want
to install this file on all of your systems simultaneously. (Note that
while you will need to restart MailWorks, it is *not* necessary to
install this full ECO on all systems simultaneously.)


============================================================================

                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO3
                                    2/21/97

MailWorks for UNIX V2.0, ECO3 includes all of the changes incorporated
into ECO2.  The release notes for ECO2 are included at the end of
this document.  The changes introduced in ECO3 are described below:

* Under rare circumstances, when the mss server had problems opening
  one message store, it could get "stuck" and prevent all users from
  opening any other message store.  The symptoms were that users who
  were already connected could continue to work, but other users could
  not make new connections to the server.
  
  ECO3 introduces a timeout on the opening of a message store, so that
  if it fails, an error will be reported to that user, but no other
  users will be locked out of their message stores.  A message of
  the following form will be placed in the msslog:
  
  -----
  Sat Feb 15 15:58:12 1997, Program: ./mss, Pid:31422, User: root, Type: Err, Sev:
   Error
          Version: 2.0-FT1, Version Date: Sat Feb 15 15:36:30 EST 1997
          Module: 15, Error: 47
  The message store:
  mail4u.zko.dec.com:/mailworks/test_users/test103/dmw/test103.po
  is currently locked and cannot be accessed (Error MSMutexLocked).
  If this condition persists, your system administrator may need to
  restart MailWorks.
  -----
  
  Under some circumstances, this condition may clear itself (for example,
  if a background thread is emptying someone's wastebasket, they cannot
  make a new connection until the process is complete).  If it does not
  clear itself, it may be necessary to restart MailWorks to clear that
  user's problem.
  
* The startMAILworks and stopMAILworks scripts fix some minor problems.
  If the lsfd process is running, it no longer prevents the stopMAILworks
  script from completing.  If the lsfd process is running when startMAILworks
  is run, startMAILworks will simply allow the lsfd to continue.
  
  (Note that it is perfectly normal for the lsfd process to be running while
  MailWorks has been shut down - once MailWorks is restarted, lsfd will 
  re-establish its connection to the other processes.  While MailWorks is
  shut down, lsfd may be started up if new internet mail arrives - the
  inetgrecv process will use lsfd to ensure that the incoming mail will
  be delivered when MailWorks is restarted.
  
* Inetgrecv now properly handles some MIME messages that previously
  caused a segmentation fault in inetgrecv.
  
* The table used to identify attachment types in MIME have been updated to
  correct an omission (Powerpoint version 7), and to correct an error
  (Excel version 5).  This is the file .dmw_mime_send_map.

* ECO2 introduced a harmless error message that appeared in the inetgrecv
  logs (erroneously reporting an invalid Internet Header) - this has been 
  corrected in ECO3.
  
* The script suppscr.sh, located in the unsupported directory has been 
  updated to collect more complete information.  This script should be
  used if you need to report a problem to engineering - simply run
  the script from the root account, and include a copy of the script's
  output (a file named session.out) in the problem report.
  

Useage notes
============

Using filenames on attachments
-----------------------------
   Now that the MailWorks server will carry file names for message
   attachments, it is possible to enounter problems with names
   that are too long.
   
   In particular, the default behavior of TeamLinks for Windows
   when attaching a file is to include the full path spec of the
   file.  Depending on where you have the file, this can result in
   a fairly long file specification.  In many cases, when the recipient 
   extracts this bodypart from the message to the native file system
   the long name will be truncated, in the process losing what may
   be the most important part of the name: the extension.
   
   If this becomes a problem, or more precisely, if this problem
   becomes more significant than the benefit of having a full
   path spec in the message, TeamLinks for Windows can be modified to
   use only the filename without the full path.  
   
   In OFFICE.INI under [TeamLinks Mail] add the entry 
   FullSpecAttachmentTitle=0
   
   Note that as of this writing, this feature is not documented in
   the TeamLinks documentation.

UUEncoded bodyparts in MIME
---------------------------
   Eudora Pro 3.0 has an option to UUEncode attachments. Unfortunately, it
   does not do what you might expect it to do - the message as a whole is
   still sent MIME encoded, but the individual attachments are sent using a
   transfer encoding of x-uuencode.  (This is a non-standard encoding for
   MIME, and MailWorks does not yet support it.)
   
   The effect is that when a sender uses this option, the recipient sees an
   attachment that is apparently of the right type (e.g. it appears to be a
   word document, and when the TeamLinks user tries to read it, Word is
   invoked), but the content is actually the raw UUEncode.
   
   Alternatives for the receiving user:
   
   1) Talk to the sender, and ask him/her to resend the message
      with either MIME or binhex selected as the encoding method
      under attachments in the Eudora client.
   
   2) Save the file to disk and use a stand-alone UUDecoding utility
      to decode it.
   
   3) If you are using TeamLinks for Windows, then with the message 
      open, use the menu entry "Decode Message" on the file menu.

Attachment tagging
------------------
   A couple of problems have appeared recently that generally
   relate to bodypart tagging and decoding:
   
   1) Starting with V2.0.2, MailWorks now supports full fileanames on
      attachments for local delivery, X.400 delivery, and SMTP/MIME.
      It does *not* yet carry filenames in the UUEncoded encoding
      used when sendMime is turned off (which is the default).  The
      filenames used with UUEncoding are of the form Enclosure1, 
      Enclosure2,...
      
      This limitation has been corrected in ECO4.
      
   2) The MSMail driver includes a version of TLFormat.ini to assist in the
      mapping of file types from the server tagging to the tagging that 
      MSMail requires.  The version included in the driver kit has already
      gotten out of date (and will only get more so).  The symptoms of this
      are that an MSMail recipient sees an attachment that is not recognized
      by MSMail, but if s/he saves the file to disk with an appropriate
      filename, it can be opened by the appropriate application.  (Note that
      the symptoms are almost identical to the first problem, but the cause
      is very different.)
      
      The solution is to add the appropriate file types to the TLFormat.ini file
      used by the MSMail driver.  Note that you cannot simply take the 
      file from the latest version of TeamLinks, since newer versions of TeamLinks
      often add fields not recognized by the older MSMail driver code.
      Just the individual file type entries should be copied, and some of the
      newer fields should be dropped (e.g. in the following entry for Word 6, 
      the line for Template, MIMEContentType, and PegasusType should be omitted
      when creating the entry for the MSMail driver:
      
   [WINWORD6]
   Desc=Microsoft Word for Windows V6.0/7.0 Document
   FileExt=DOC
   IosFormat=WINWORD6
   IosDsab=FOREIGN
   IosFileExt=DOC
   Asn1=2B0C02877305014F
   Template=WINWORD6.DOC
   MIMEContentType=application/msword; name="TL.doc"; Type=%%peg%%
   PegasusType=MS-Word-6
   


============================================================================
  
                                 Release Notes
                          MailWorks for UNIX, V2.0, ECO2
                                    1/13/97

This document contains the following information:

  Problems fixed in ECO1 and ECO2.
  Additional Features implemented in ECO1 and ECO2:
    -  Support for MTA password
    -  Limit on the number of mcs connections accepted
    -  POP3 administration
    -  Support for filenames on message bodyparts
    -  ISO Latin 2
    -  Controls on the elimination of duplicate messages
    -  Improvements to the start and stop scripts
  Other notes on using MailWorks effectively
    -  How to use a single msr with several servers
    -  Valid SMTP addresses
    -  Automatically applying quotes to SMTP addresses in TeamLinks
    -  How to safely move or rename message stores
    -  POP3 clients that are supported
    -  Defining new data types
    -  Memory usage
    -  Interoperability with Microsoft Exchange

Problems fixed in ECO2
======================
* A number of significant memory leaks in the mcs process have been 
  fixed in both ECO1 and ECO2.  Sites that had been restarting
  MailWorks every night or every second night may find they need to
  restart only once per week.  See the discussion later in the release
  notes for more information on memory usage.

* Disable "From" field in command line interface:
  The command line interface allows users (or scripts) to specify a "from"
  value.  While this can be useful for some scripts, it opens the door
  for impersonation when used interactively by end users. MailWorks now
  accepts a MAILworksrc parameter to control whether the from option
  is accepted.  When allowFrom is TRUE, users and scripts will be able to
  specify a From field when they do a comp -headerlist.  In this case,
  MailWorks will now add a Sender field to minimize the effects of any
  impersonation attempt. When allowFrom is FALSE, users and scripts will not
  be allowed to specify the From field.
   
  NOTE: the default value of this parameter is FALSE, which represents
  a change in behavior from prior versions.  If you depend on being
  able to set the From field, e.g. for scripts, you should define
  this parameter to be TRUE in the MAILworksrc file.

* If the directory service is unavailable at the time an incoming messge
  arrives, it will now be queued for later delivery (via lsfd) rather than
  being immediately rejected.

* Several problems that caused inetgrecv to fail have been fixed.  
  Inetgrecv can now properly decode MIME messages with attachments
  encoded in BinHex.
  
* When sendMime is false (or not specified), forwarded messages are
  no longer corrupted.  This had been particularly prevalent when
  the forwarded message had an attachment.

* Message delivery dates are now properly preserved when the packf
  command is executed (and are properly imported by the inc command).
  If the MAILworksrc parameter sendMime is TRUE, the messages exported
  by the packf command will be MIME encoded.
  
* A typographical error in the DMW-delete script (that prevented the
  complete deletion of an account) has been corrected.

* stopMAILworks now waits 5 seconds before attempting to stop the mss
  process - this gives the mss a chance to properly close its connections 
  to the other processes before beginning its own shutdown cycle.

* When entering header date fields (e.g. deferred delivery date, expiration 
  date) into the Motif client, the input box is now sized so that the time 
  portion of the date is visible as it is being typed.

* Clicking on the delete button of the Motif client's DDA dialog no
  longer brings up the Help window.

* ECO2 fixes a couple of small windows in which messages could be lost if
  MailWorks or the system went down at the wrong time.  We believe that
  other than power failures that would prevent memory writes to disk, 
  all opportunities to lose a message have been fixed.
  
* A number of problems have been fixed with the dates appearing on messages, 
  particularly with TeamLinks clients.  In particular:
  -  When a message is being copied or moved to the server from a local 
     TeamLinks drawer, the server will properly set the posted date.
  -  When non-modifiable messages (i.e. received messages or sent copies)
     are being written to the server, the server will not reset the modified 
     time, or in some cases will set the modified time to the delivered time.
     The field that the server identifies as the modification time appears in
     all TeamLinks clients in the Read Message window, and in older 
     TeamLinks for Macintosh clients as the date/time that displays in the
     file cabinet display window.
  -  When revisable (e.g. draft) messages or documents are copied to the
     server, the modification time is reset to the date/time of the copy.
  -  When a message has BCCs and an expiration date or reply by date, 
     the date is now properly stored with the message.
  
* When transferring messages to an X.400 MTA, the X.400 field "Originally 
  Specified Recipient No" is now properly set. This caused problems when the
  message was transferred to a non-Digital MTA.
    
* The mss server now properly recovers from certain types of corruption in
  message stores.  This error showed itself as ProtoBadLength in the mss logs.

* The x488grecv process now properly recovers from many communication problems
  with the MTA - previously it was possible for x488grecv to get hung up
  waiting for an operation to complete that was never going to complete.
  
  Note: we had recommended against using the LOCAL option in the file 
  /var/mta/mta_api_server_address - the situation that caused problems
  with this configuration option has since been corrected, so you may
  now use this configuration option.
  
* The mcs server now properly handles messages containing both X.400
  recipients and bcc recipients; this combination used to cause the
  server to crash.


Additional features/capabilities
===============================

MTA password
------------
   MailWorks/UNIX now supports optional password authentication when
   MailWorks connects to the MAILbus400 MTA.
   
   To enable this password authentication, do the following:
   
   From the MTA side:
   
   1) Using NCL, set a password for the MailWorks MTA agent as follows:
   
      ncl> SET MTA AGENT mailworks_mta_agent_name PASSWORD "secret"
   
      where "mailworks_mta_agent_name" is the name defined in the
      /usr/opt/DMW/MAILworksrc file as X400ClientName.
   
   2) Add this command to the var/mta/scripts/start_mta.ncl at the point
      where the MailWorks MTA agent is defined, so upon restarting the MTA, 
      the password is retained.
   
   From the MailWorks side:
   
   1) Create a file of the name /var/opt/DMW/mtaAgentPwd.  (This filename is
      case sensitive.)  On the first line of this file, enter only the
      password set for the MailWorks MTA agent using NCL (e.g. secret). The
      password is case sensitive.  This file should contain nothing else but
      this password on a single line.
   
   2) Set the UNIX ownership and permissions on the file
      /var/opt/DMW/mtaAgentPwd so no unauthorized users can
      obtain the password.
   
   Notes: A password is not required to connect to the MTA.  However, a
   matching password is required once either side (NCL or the mtaAgentPwd
   file) defines a password.  It is not necessary to restart the MB400 MTA
   or MailWorks for password authentication to take effect.  Once passwords
   are defined, they will be used automatically by MailWorks on the next
   MTA connection attempt.

Limit number of connections
---------------------------
   If your users use TeamLinks, cc:Mail, or Microsoft Mail be aware that
   there is a limit on the number of connections that the mcs process can
   accept.  (Microsoft Exchange clients communicating through the MAPI
   driver do not use the mcs process, so are not subject to this limit.) 
   Prior to ECO1 of version 2.0, the mcs process would not properly
   recover when this limit was exceeded (among other effects, it would
   refuse to accept new connections, even when the number of active users
   dropped below the limit).  Beginning with ECO1, it is now possible
   to put a limit on the number of connections that the mcs process will
   accept.  If this limit is specified, then any attempted connection that
   would exceed this limit will be rejected (the user will get a message
   that the connection attempt failed), and an entry will be logged in the
   mcs log.  This user can try again later, and if other users have
   disconnected from the MailWorks server (so that the number of active users
   is below the limit), the connection will be accepted.

   The limit is enforced if the parameter maxGENIConnections is defined in
   the file /usr/opt/DMW/MAILworksrc, and of course the maximum number of
   connections is the value of the parameter. If no parameter is defined,
   no limit is enforced.  Note that the default MAILworksrc file specifies
   no limit, so if you have a large number of users, you should supply
   a limit. The parameter defines a limit on the number of connections
   that the mcs server will accept from a PC client.

   In general, a reasonable value for this parameter is 2600.

   Some background and details:
   When a TeamLinks or cc:Mail user logs into the MailWorks server, his
   client software is actually making two connections to the mcs server
   process (one to port 6161, and one to port 8484), the mcs server in
   turn makes one connection to the mss process on behalf of that user. 
   Thus, in the simplest case, each user causes the mcs to consume 3 TCP
   connections.  The mcs process has a limit of 4096 files and TCP connections
   that it can have open at one time (in general, the mcs process keeps
   very few files open, so the number of files does not contribute
   significantly to the limit).  Thus if 1300 users connect, there will be
   1300 connections to the mss process, and 1300*2 connections from the PC
   clients - the total of 3900 leaves a reasonable margin of error below
   the absolute limit of 4096.

   Microsoft Mail clients make two sets of connections to the server for
   each user, and some new mail notification applications make yet another
   set of connections.  Thus, when Microsoft Mail is being used, the limit
   of 2600 PC connections will translate into fewer than 1300 users.

   When the limit is exceeded, a log entry similar to the following will
   be placed into the mcs log:

   -----
   Mon Nov 11 22:36:24 1996, Program: ./mcs, Pid:14708, User: root, Type: Err,
   Sev:
    Error
           Version: 2.0-1, Version Date: Mon Nov 11 18:04:23 EST 1996
           Module: 34, Error: 24
   The limit of 1 PC-client/compatibility-server connections has been
   reached (Error MUAS_TooManyConns).  As a result, a connection request by user
   testjmm has been rejected.  The user should try connecting again later.
   
   -----


POP3 administration
-------------------
By default, when a POP3 client deletes a message from the inbox, the
message is placed into the user's wastebasket.  If the user does not
normally use any other clients that can empty the wastebasket (or if
administrative scripts that empty the wastebasket are not used), this
can lead to an accumulation of deleted messages in the wastebaskets.  To
overcome this, you can set the MAILworksrc parameter deletePop3Msgs to
TRUE (the default value is FALSE).   When this is set to TRUE, then when
messages are deleted from a POP3 client, they are permanently deleted
rather than being placed into the wastebasket.  Note that this affects
only deletions requested from POP3 clients - when a delete is requested
from any other client, the message is placed into the wastebasket.


Filenames
---------
MailWorks will now preserve the filenames of message attachments when they
have been supplied by the originating client.  These filenames are
carried on local delivery, in MIME messages, and in X.400 messages in
FileTransferBodyParts.

For local delivery, the filename supplied by the originating client is
delivered with the message with no validation or re-processing of the
name.  Note that this includes optimized local delivery of messages to
local X.400 or SMTP addressees (e.g. if the MAILworksrc parameters
localSMTPAddresses and/or localX400Addresses are set).  Note also that
if a POP3 client is used to read locally delivered mail, the processing
rules for MIME in the next paragraph apply.

In MIME messages, the filename is carried in the name= clause of the
content type entry.  By default, if a filename is supplied, it will be
fixed up if necessary to make it a legal filename, then used; if no name
is supplied, the name= clause from the file .dmw_mime_send_map will be
used instead.  To describe the rules for handling filenames more
precisely:
* If no filename is supplied by the originating client, then the name=
  clause from the .dmw_mime_send_map file will be used in the MIME encoding.
* If the MAILworksrc parameter overrideSendMap is set to FALSE, then the
  name= clause from .dmw_mime_send_map will be used in the MIME encoding.
  (The default for this parameter is TRUE, so that by default, the filename
  supplied by the originating client will be used.)
* If the MAILworksrc parameter validateBPFileNames is set to TRUE, and the
  extension of the filename does not match the extension recorded in the
  Enclosure/DB file, then the filename supplied by the originating client
  will be replaced by the filename in the name= clause of .dmw_mime_send_map.
  The default for validateBPFileNames is FALSE, which means that the filename 
  supplied by the originating client will be used.
* If validateBPFileNames is FALSE (the default), and the MAILworksrc parameter
  fixupBPFileNames is TRUE (the default), then the filename supplied by the
  originating client will be "fixed up" if necessary, then used.  The "fixup"
  rules are as follows:
  -  If the name is valid according to the rule in the previous item, do nothing.
  -  Otherwise, replace any non-printable or "quotation" character with
     an underscore ('_').
  -  Add the extension for the file type from the Enclosure/DB file.
  Thus, if a Word document is send with the filename D:\samp"foo.bar,
  the filename will become D__samp_foo_bar.doc
  Note that the fixup *may* result in a filename that is longer than some
  operating systems (e.g. MS-DOS or Macintosh) will accept, but it should be
  legal in other respects.  Most importantly, most clients that depend on
  the extension to recognize file types will continue to work properly.

In X.400 messages, the filename is carried as part of the newly defined
File Transfer Body Part.  As with MIME, the oversimplified description
is that if a filename is supplied it is fixed up as necessary, and
included in a File Transfer Body Part, otherwise the attachment is sent
according to MailWorks' original rules.  In this fallback case,
attachments may be sent as General Text as a FAX bodypart, or a
bilaterally defined bodypart, etc.  Many binary files will be sent
as an Externally Defined Body Part (also called BodyPart 15).
To be more precise:
* If the MAILworksrc parameter sendFTBP is FALSE, all bodyparts will be
  sent according to MailWorks' original rules, which generally means
  that cover memos will be sent as text, and binary attachments are sent
  as Externally Defined Body Part.  The default for sendFTBP is TRUE, which
  means that MailWorks will attempt to send bodyparts using File Transfer
  Body Part, with the following qualifications.
* If the cover memo is text, it will not be sent as File Transfer Body
  Part and hence, will have no title or filename.  This is how most
  clients expect cover memos to be presented.
* If the cover memo is Rich Text Format, it will be sent as File Transfer
  Body Part with a name of "cover.rtf", so that clients that rely on the
  filename extension will recognize it as rtf.
* If an attachment does not have a filename, it will be sent according
  to MailWorks' original rules.
* If the MAILworksrc parameter validateBPFileNames is set to TRUE, and the
  extension of the filename does not match the extension recorded in the
  Enclosure/DB file, then the file will be sent as an Externally Defined Body 
  Part.  The default for validateBPFileNames is FALSE, which means that the 
  filename supplied by the originating client will be used.
* If validateBPFileNames is FALSE (the default), and the MAILworksrc parameter
  fixupBPFileNames is TRUE (the default), then the filename supplied by the
  originating client will be "fixed up" if necessary, then used.  The "fixup"
  rules are as follows:
  -  If the name is valid according to the rule in the previous item, do nothing.
  -  Otherwise, replace any non-printable or "quotation" character with
     an underscore ('_').
  -  Add the extension for the file type from the Enclosure/DB file.
  Thus, if a Word document is sent with the filename D:\samp"foo.bar,
  the filename will become D__samp_foo_bar.doc
  Note that the fixup *may* result in a filename that is longer than some
  operating systems (e.g. MSDOS or Macintosh) will accept, but it should be
  legal in other respects.  Most importantly, most clients that depend on
  the extension to recognize file types will continue to work properly.

Note that if you set sendFTBP to TRUE, you should confirm that you are
using at least version 2.0 of MAILbus400.  Earlier versions do not support
the File Transfer Body Part, and you will find a number of error number 6
reported in the x488glogs, and any message with an attachment will fail to 
deliver.  If you are using an older verion of MAILbus400, you should set
sendFTBP=FALSE.

In all cases when a message is received (either through SMTP or X.400)
with a filename, the filename is stored with the message and made available
to any client reading the message.

When a message with filenames on the bodyparts is read from the Motif
client, the list of filenames will be visible as a header field.  If you
feel that this will be distracting to users, you can set the MAILworksrc
parameter hideBodyPartNames to TRUE to hide the display of this
attribute in the Motif client only.  The default value is FALSE, meaning
that the names will be visible.

ISO Latin 2
-----------
It is now possible to configure MailWorks to use ISO Latin 2 as its
internal character set, rather than ISO Latin 1.  This is accomplished
by setting the MAILworksrc parameter useISOLatin2 to TRUE. When this is
set to TRUE, then the ISO Latin 2 (ISO 8859-2) character set will be
used when mapping characters from the Teletex (T.61) character set when
receiving Teletex X.400 fields.  This affects such fields as Subject,
Free Form Name, and other address fields such as Common Name, Surname,
Organizational Unit. When sending a message over X.400, characters in
Subject and Free Form Name will be properly mapped from ISO Latin 2 to
the Teletex character set; other fields will continue to be encoded as
Printable String.

If you will be using SMTP and MIME, you should also modify the MIME send
and receive maps to reflect this change.  

In the file .dmw_mime_send_map, you should change the entry:
    PlainText:quoted-printable     text/plain; \
                                   charset=ISO-8859-1; \
                                   Type=Text
to 
    PlainText:quoted-printable     text/plain; \
                                   charset=ISO-8859-2; \
                                   Type=Text

In the file .dmw_mime_receive_map, you should change the two entries:
    PlainText           text/plain; charset=ISO-8859-1
    TextIso8859-2       text/plain; charset=ISO-8859-2
to
    TextIso8859-1       text/plain; charset=ISO-8859-1
    PlainText           text/plain; charset=ISO-8859-2


Control elimination of duplicates
---------------------------------
MailWorks contains a feature (informally called "de-duping") which
eliminates duplicate incoming messages.  This feature can be useful when
communication with an MTA is unreliable - when the MTA transfers a
message to MailWorks, if it cannot confirm that MailWorks has properly
received the message, it may resubmit the message to guarantee that it
was received.  If MailWorks attempts to deliver a message to a user's
inbox, and finds a message with the same message ID, the same number of
bodyparts, and finds that the content of those bodyparts is identical
(it actually compares all bytes of every bodypart), then the second
message is simply discarded.  If you are uncomfortable with this
behavior and would prefer to have the duplicate messages delivered to
users' inboxes, you can set the MAILworksrc parameter deliverDuplicates
to TRUE.  The default value for this parameter is FALSE, which causes
the server to continue to eliminate duplicates on delivery.

Note that MailWorks will continue to eliminate duplicate recipients in
the TO list of an outbound message.  This might occur, for instance if
you use two overlapping distribution lists.  This behavior is not
controlled by the deliverDuplicates parameter.

Start/Stop scripts
------------------
A number of changes have been made to the startMAILworks and stopMAILworks
scripts for smoother and more reliable operation.

startMAILworks
   The startup script startMAILworks now will:
   - Verify that the script is run from the root account.
   - Verify that no other MailWorks processes are running.
   - Wait a configurable amount of time between starting the msr and
     starting all other processes.  The first action of most MailWorks
     processes is to connect to the msr process.  If the msr takes a
     particularly long time to start, e.g. if it needs to load a very long
     list of aliases, then the other servers can fail in their connection to
     the msr.  Each server will report this problem in its log file.  To
     solve this problem, the environment variable, startupMSRSleepTime, has
     been added to the MAILworksrc file.  By default, each process that
     needs to wait for the msr will wait 35 seconds.  This variable may
     be modified to wait a longer or shorter amount of time based on a
     customer's configuration.  The value for this environment variable
     is represented in seconds.  (To be precise, the startMAILworks
     script will actually start these processes immediately, but the process
     itself will wait startupMSRSleepTime before attempting to connect to
     the msr.)

stopMAILworks
   The shutdown script for MailWorks has been modified.  The following
   modifications have been made:
   - deferd processes will now be terminated (note that starting with
     ECO2, these messages are still on a queue, so stopping the deferd
     processes will not result in a loss of messages.)
   - By default, the shutdown script will wait, an unlimited amount of time,
     for all MailWorks processes to terminate.  A new environment variable,
     shutdownWaitTime, has been added to the MAILworksrc file to modify this
     new behavior.  If a customer does not want to wait an indefinite length
     of time for MailWorks to shutdown, shutdownWaitTime should be set to the
     maximum number of minutes the shutdown script should wait for MailWorks
     to shutdown.  Zero represents waiting an unlimited amount of time.


Other Usage Notes
=================
Single msr process
------------------
   If you will be using a single msr supporting several machines, then when
   you run DMW-add on the machines that are not running the msr, you will
   be given an error message.  After the DMW-add completes, you should go
   to the machine running the msr, and enter the following commands from
   the root account:
      #ali -global newaccountname node:fullpath
      #confpref newaccountname -mail_dir directorypath
      
   where:
   "newaccountname" is the MailWorks alias name for the new account, 
   "node" is the node on which the user's account is stored,
   "fullpath" is the full path specification (including the file name) for
      the user's primary message store (usually, this is
      /usr/users/newaccountname/dmw/newaccountname.po), and 
   directorypath is the path of the directory containing the user's message 
      store (e.g. /usr/users/newaccountname/dmw):
   
Valid SMTP addresses
--------------------
   If an SMTP address is entered with spaces around the @ (as in "President
   @ Whitehouse.gov"), this will be interpreted by sendmail as two
   different addresses ("President" and "Whitehouse.gov").  In most cases,
   this is not what you intend, and the message will be non-delivered, or
   will be delivered to the wrong local account.  To avoid this, simply
   enter SMTP addresses without spaces.
   
Quotes on SMTP addresses
------------------------
When TeamLinks clients are used with MailWorks for UNIX, SMTP addresses
must be enclosed in quotes.  (Without the quotes, the TeamLinks clients
interpret the address as a Message Router address, and pre-parse the
address in a way that causes the server problems.)

Because it is easy for users to forget to include the quotes, you may
want to customize the TeamLinks clients to automatically insert the
quotes when they detect an SMTP-style address.

In TeamLinks for Windows, go to Setup, pick Mail Profile, then
addressing. Click on Customize Addressing, and type a double quote (")
into the fields "Prefix to add" and "Suffix to add".  You should also
add the character > to the field "Disqualifying Characters".

In TeamLinks for Macintosh, version 2.6 and later, use ResEdit to
modify TeamLinks Mail (DMW).  Edit resource STR# 130 and add a quote to
string 1 (which is the suffix string) and string 5 (which is the prefix
string).  Note that prior to version 2.6, TeamLinks would attempt to
double-quote your prefix and suffix strings, which meant that you would
get three quotes, which did not work properly for this purpose.

For both clients, you can make this customization *before* the client is
installed, so that it can be done only once, rather than on every
individual desktop.  See the individual client documentation for details
(e.g. for the Macintosh, this is described in the Troubleshooting Guide
that is installed with the client).

Moving Message Stores
---------------------
When a message store is open, you cannot move, rename, delete or recreate
that message store without causing corruption to the data in the message
store.  A message store may be open because a user has connected
to that message store, or because a message has recently been delivered
to that message store.  A message store can also be open because a
client machine has requested notification of delivery of new mail. 
Finally, a message store is held open for approximately 10 minutes after
the last client closes it as a performance optimization (to avoid the
cost of an open in case a new message arrives for that message store). 
If you need to move, rename, delete or recreate a message store, you
should force it to be closed by using the confddb command with the
-disable option to disable that message store.

POP3 Clients
------------
Because of the sheer number of POP3 clients, we are unable to test all of
them with MailWorks.  We have tested with a number of the more popular
clients, and expect that most POP3 clients will work properly with
MailWorks.  However, some clients depend on support for UIDL (an
optional feature that has not yet been implemented in MailWorks) to
support the "leave message on server" option - with these clients, you
can retrieve messages from the server, but they will be deleted from the
server as part of that retrieval.

The following POP3 clients have been tested with MailWorks:

  Client                 Supports "Leave on Server"
  -------------------------------------------------
  Netscape V2            No
  Netscape V3            Yes
  Eudora Pro             Yes
  Eudora Light           Yes
  QuickMail              No
  Calypso                Yes
  
Registering new data types
--------------------------
Digital has created a branch of the tree of Object Identifiers for use by
customers to identify types that have not been registered by Digital.
The stem of this branch is 2B0C028773050A.  The first 127 customer-
registered types can be created by appending 2 hex digits in the range
00 through 7F to the stem listed above.  Be aware that the rules for
constructing ASN.1 Object Identifiers are complex, and cannot be
described simply here.  Do not attempt to assign types beyond 127 unless
you understand those rules.


Memory usage
------------
Virtual size of server processes
   Be aware that the virtual size of the mss process can be affected by a
   number of different factors, including both the number and the size of
   the message stores on the server.  (Note that even if a user is not
   logged in, his or her message store can be active if it is receiving
   mail.)  If you find that the virtual size of the mss process is becoming
   large, you can encourage users to empty their wastebaskets and remove
   any old or unneeded messages in their sent items folder.  On the other
   hand, there is no particular problem if the virtual size of the mss is
   large, as long as the machine has sufficient swap space (check this with
   the command swapon -s), and the process is not exceeding a process size
   limit (see the next paragraphs).
   
   Under heavy load conditions, it is possible that the mss or mcs process
   can exceed the default operating system limit of 1 gigabyte per process.
   Customers should monitor the size of the mcs and mss processes, and if they
   begin to approach this limit, the operating system should be reconfigured
   to permit them to grow beyond 1 gigabyte in virtual size.  Note that
   you should also ensure that your system has sufficient swap space to 
   accommodate such a large process.
   
   We have seen systems exceed this limit when the system has a large number
   of subscribers, and each of those subscribers has retained a large number
   of messages in their wastebasket.  In one case, the system had
   1000 subscribers, of which only 200-300 were connected at a time, and
   the mss grew to 1.3 gigabytes.  After cleaning up the wastebaskets,
   the size of the mss remained at around 400 megabytes.
   
   I'll provide a brief overview of the parameters involved below.  For 
   complete details, you should consult the System Tuning and
   Performance Management Guide  (Order number AA-Q0R3B-TE).
   
   When a process is created, its initial maximum size is determined by
   the parameter per-proc-address-space (with a default size of 1 gigabyte).
   
   After creation, the process can increase its maximum size up to the value
   of the parameter max-per-proc-address-space (again, the default is 1
   gigabyte).  Because the MailWorks processes do not explicitly increase their 
   maximum, their limit will always be determined by per-proc-address-space.
   
   The parameter vm-maxvas is an absolute upper bound on the virtual
   address space that any user process can have.  This parameter is
   essentially the same as max-per-proc-address-space, except that it is
   limited to *user* processes.
   
   So, if you find that your mcs or mss process is approaching the 1 gigabyte
   limit, you should reset the values of each of these parameters, e.g. to 
   2 gigabytes.
   
   In addition, if you observe that the size actually does begin to exceed
   1 gigabyte, you should also increase the parameters per-proc-data-size
   and max-per-proc-data-size, normally to the same limits.
   
   These parameters are all set in the file /etc/sysconfigtab - after making
   a change or addition to this file, you need to restart the system. (Note
   that it is *not* necessary to rebuild the kernel.) It is recommended
   that you use the system command sysconfigdb to modify this file.  When
   modifying this file, you will need to know that the subsystem ID for the
   parameter vm-maxvas is vm, and the subsystem ID for the remaining
   parameters is proc. 
   
   In summary, your additions to the sysconfigtab should look like the following:
   vm: 
       vm-maxvas=2147483248
   proc:
       max-per-proc-address-space=2147483248
       max-per-proc-data-size=2147483248
       per-proc-address-space=2147483248
       per-proc-data-size=2147483248

Memory usage and process size
------------------------------
The MailWorks server processes, especially the mcs and mss process,
tend to consume more virtual memory than people expect.  To help you
understand how the servers work, and what is normal, the following 
discussion describes first the virtual size of the processes, and then
talks about the resident memory size of the processes.

First: because of the way the threads system works, the MailWorks
processes will never become smaller in virtual size (although the
resident size will vary, depending on a variety of factors).  This is a
side effect of the design of the threads memory management mechanism:
when one of the MailWorks server processes allocates memory, and then
frees memory, the freed memory is held for the process to re-use when
the process allocates memory again.  Thus, while the memory is not used
by the server process, it still occupies virtual memory.  This results
in a "high-water effect": when everything else is working properly, the
virtual size of a server process will remain at its highest level.
Expressed differently, the size of the server will tend to grow the
first day, then will tend to level off, growing again only if it has a
particularly demanding task to do (e.g. if it has to deliver a large
message to every user on the system).

While the mcs process typically reaches its high-water mark in the first
day of usage, for some customers the mss process will sometimes continue to
grow over the next couple of days - this is normal.  In general, we
expect the size of the mss process to stabilize within 3-4 days

The previous paragraphs describe the ideal situation.  Prior to ECO2, the
mcs process had some significant memory leaks, that caused the process
size to continue to grow on the second and subsequent days of use.  This
forced most customers to restart MailWorks every day or every two days.
Starting with ECO2, the most significant leaks have been fixed, which in
turn means that you can restart MailWorks significantly less often than
previously. How often is it necessary to restart MailWorks?  This
depends on how large the processes get, how much real memory you have,
and how much swap space you have.  After installing ECO2, we recommend
that you start by letting the system run one day longer than with your
previous release - monitor the size of the processes and your usage of
swap space.  If you continue to have sufficient swap space (at least 20%
free), then allow the system to run for an additional day, and continue
to monitor the use of swap space and process sizes.  If yours is a new
installation, start by letting MailWorks run for a week, then as your
users' activity level rises, continue to monitor the system to confirm
that a weekly restart is sufficient.

Finally, what affects the size of the mss process?  The primary factors
that affect the size of the process are the number of message stores
that are open at one time, and the size of the folders that are opened
in those message stores.   A message store is opened by the mss when the
user opens it from a client, when a message is delivered to that message
store, or when a system manager opens the message store from the command
line (using setpms). The message store is closed by the mss
approximately 10 minutes after the user disconnects, or the message
delivery is completed.  When a TeamLinks client requests notification of
new mail delivery, that will also cause the message store to be held
open.  While a message store is open, the server will cache information
in memory for any folders that are opened.  So, what can make the mss
process grow significantly?

1) If a message is addressed to all users (or a large number of users) on the
   system, the server will need to open a large number of message stores at
   about the same time.  If the users have large inboxes, this will drive the
   memory requirements even higher.
   
2) If folders that are accessed frequently, such as the Inbox, the Outbox,
   or the Wastebasket get very large, then this can raise the memory requirements
   of the mss server.  If you encourage your users to keep these folders
   reasonably empty, this can reduce the demands on memory.
   
3) If the system manager runs a script that uses the command line interface
   to open all message stores, then all message stores will be opened at the
   same time, at least temporarily.
   
   Special note to script writers:  If your script simply uses the setpms
   command running as root user, then each execution of setpms will close
   previously opened message stores, which will allow the mss to actually
   close the message store after all other demands on the message store
   are complete.  On the other hand, if the script switches users (using
   the su command) between executions of setpms, the Command Line Server
   cannot determine that the new setpms request has come from the same
   script.  As a result, every message store will be held open until
   MailWorks is restarted.  In addition to the extra demands on memory,
   this will increase the time it takes MailWorks to shutdown, and
   increases the chances of message store corruptions in case of an
   abnormal exit of MailWorks.  In general we recommend against using su
   within such scripts; if you find it necessary, you should run such scripts
   when you will be able restart MailWorks after the completion of the 
   script.  Be sure to allow sufficient time for the mss process to finish -
   after opening *all* message stores, it can take a while to close them all.
   
4) If there is an unusually high level of incoming messages, then it is possible
   that many message stores will never reach the 10 minutes of inactivity, which in 
   turn means that many of them will remain open.  In this case, the number
   of message stores that is open can be considerably higher than the number
   of users who are connected to the server, and this in turn can drive
   the memory requirements up.
     
Note: after all clients of a message store have disconnected from it, the
mss will begin to close that message store after about 10 minutes, but
in exceptional cases, it can take the mss 15 minutes to a half hour to
completely close all of them even on an idle system.  On a busy system,
it can take much longer, since the closing is done as a lower-priority
background activity.

------------------

So much for *virtual* size - what about the real memory demands of the
server processes (also called the resident memory size).  Clearly the
real memory demands of the server are much less than the virtual demands
- this is the very nature of a virtual memory system.  Another thing to
understand is that the actual resident memory size of the servers will
go up and down with other demands on the system - the virtual memory
system will tend to balance the needs of the MailWorks processes for
memory with the needs of other processes on the system; it would not be
surprising if the resident memory size of the MailWorks processes
actually grew at times when they were relatively idle, if other demands
on the system were low at the same time.

In general, we recommend 1/3 to 1/2 of a megabyte of real memory for
every connected user - this assumes that about 1/4 of the users with
accounts are connected.  If the fraction of connected users is smaller,
which means that for every connected user there are more than 3
unconnected users, you may need more memory per connected user.  (This
is because the message stores for some of those "inactive" users may
still be open in order to deliver incoming mail.)  If you have a very
active system, you may also need more physical memory than the general
rule.

During your system's peak time, you should monitor the system
performance - you may need to add more physical memory if your system
slows down noticeably during peak system times, and if vmstat shows that
it is doing excessive paging at those times.  There is no simple rule
for what is "excessive" paging (since it depends a lot on the speed of
your disks, how many devices you are using for swap space, and your
tolerance for a slow system).  However, we have seen systems that were
performing quite well with paging on the order of 10-15 per second.

Interworking with Microsoft Exchange
------------------------------------
If you will be exchanging mail between a Microsoft Exchange server and a
MailWorks for UNIX server, you can either use SMTP and the Exchange
Internet Mail Connector, or MAILbus400 and Exchange's X.400 Connector.

When configuring Exchange's Internet Mail Connector, you should select
the Message Content Panel, and select the following options:

o  Send messages using MIME.  Messages will be transferred more
   accurately, and attachment types will be handled more conveniently than
   if you select UUEncode.

o  Under Interoperability, Select "User" or "Never" for the "Send
   Microsoft Exchange Rich Text Formatting" option. If you select
   "Always", then Exchange will always generate a TNEF attachment to carry
   the rich text formatting. This will be partially handled by the
   combination of the Exchange client and the MAPI driver, but it will
   be confusing to users of any other client. Also, any attachments will
   be encoded in the TNEF file, and will therefore be invisible to all
   users of the MailWorks server.

   Selecting "User" or "Never" will drop any rich text formatting in the
   cover memo, but will otherwise preserve the integrity of the
   message.
   
When using X.400 to communicate between MailWorks and Exchange, you
should configure MAILbus400 to convert text bodyparts to IA5Text in
messages transferred to the Exchange domain. In addition, you should
configure MailWorks to use File Transfer Bodyparts to encode files for
which a filename is available: set the MAILworksrc parameters sendFTBP
to TRUE.  The extension on the filename is important to Exchange to
recognize the file type.

The following sample ncl scripts set up MAILbus400 to use TCP and RFC1006
to communicate with an Exchange domain called EXCHANGEDOMAIN:

------------
create mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"]

set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] -
    application context mts transfer

set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] -
     presentation address """MTA""/""MTA""/""MTA""/RFC1006+16.31.999.999,RFC1006"
     ! Note that the TCP address above is the address of the Exchange server

set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] -
    local name = "MailWorks-mta" , -
    local password [type=ia5, ia5 string="MailWorksPassword"]
    ! The local name and password supplied here are also entered into Exchange 
    ! as the Remote MTA Name and Remote MTA password.

set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] -
    peer name = "EXCHANGEDOMAIN", -
    peer password [type=ia5, ia5 string="ExchangePassword"], -
    peer domain "EXCHANGEDOMAIN"

set mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"] -
    trace on, -
    archive INBOUND AND OUTBOUND

enable mta peer mta [type=manually configured, name="EXCHANGEDOMAIN"]


-----------
!
! Commands to create the 'MailWorks' domain entry.
!
CREATE MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" -
    DIFFERENT CCITT DOMAIN = TRUE
SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" DESCRIPTION -
    "The MailWorks routing domain; direct connection"
SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" DOMAIN "EXCHANGEDOMAIN" -
    ROUTING INSTRUCTION [ACTION=TRANSFER TO DOMAIN, -
    BOUNDARY MTA="MailWorks-mta"]

!
! Create the partial routing instruction to send mail to Exchange.
!
CREATE MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS -
    "C=US; A=TAN; P=EXCHANGEDOMAIN"
SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS -
    "C=US; A=TAN; P=EXCHANGEDOMAIN" ROUTING INSTRUCTION -
        [ACTION=TRANSFER TO DOMAIN, SERVER DOMAIN = "EXCHANGEDOMAIN"]
!
! This says that Exchange accepts any content type and the
! IA5Text EIT ({2 6 3 4 2}).  The "any" EIT following the IA5Text one says
! send bodyparts as-is if can't convert them to IA5Text.
!
SET MTS "/C=US/O=DEC/OU=ZKO/MTS=MailWorks-MTS" ORADDRESS -
    "C=US; A=TAN; P=EXCHANGEDOMAIN" -
    CONTENT INFORMATION [MAXIMUM CONTENT LENGTH = 0, CONTENT TYPES = -
        ("{1 3 12 2 1011 5 5 0 0}"), ENCODED INFORMATION TYPES = ( -
        "{2 6 3 4 2}", "{1 3 12 2 1011 5 5 1 0}")]

----------

When configuring the Microsoft Exchange server, in the Advanced Options for
the X.400 connector, we suggest the following choices:
* Enable "Allow BP-15"
* For "MTA conformance", choose 1988 normal mode.
* For "X.400 bodypart used for message text", choose IA5.


