Blank Blank
Blank Blank Blank Blank Blank Blank
Navigation Bar
Increasing the Maximum Size of Mail Messages
This item was originally published on the OfficePower web site on
26th March 1999


Increasing the Maximum Size of Mail Messages


Each mail item distributed by OfficePower mail comprises an envelope and a content.

Normally the "content" to any good letter contains a list of all the primary people you are sending "TO" in addition to all the secondary people you are "CC"-ing to. This is to enable each person to know who has seen the content. It also contains the subject matter, sender, urgency, time of sending and any attachments.

The envelope contains the distribution information for the postman; for example, recipients, sender, urgency and time of sending - this is in addition to them being in the content as described above.

At the originating postroom the envelope duplicates all the recipients found in the content. But as the mail item passes from postroom to postroom, the recipients on the envelope are typically discarded as deliveries are made or the mail item is split for transfer along different routes.

The two factors which mainly affect mail item size are therefore the number of recipients and size of the attachments.

OfficePower controls delivery in two ways.

Firstly, the RTS which transfers mail items between postrooms. The RTS accesses fully encoded mail items (both envelope and content) as single UNIX files. The RTS limits the size of a mail item to 4Mb by default. This limit also requires that the UNIX 'ulimit' allows the postroom to operate on files of this size. A default 'ulimit' of 4Mb is found on many UNIX systems; a breach of the RTS limit would result in non-delivery with the message 'transfer failure'.

Secondly, the postroom prevents delivery or transfer of mail items whose content size exceeds a value configured for a destination route. These values are selected when a capability is chosen for a destination route in the postroom configuration. Breach of the content size limit also results in non-delivery but with the message 'content too long'.

The default limits provided by OfficePower can be changed but this needs to be planned across a network of OfficePower systems. Further consideration should be given when connecting to non-OfficePower systems where it may be necessary to negotiate appropriate values for maximum mail item size and maximum content size with the system administrators.

The most likely reason for increasing the size limits is to allow larger or more attachments to be transferred. Having chosen a suitable value it is then necessary to make an allowance for the maximum number of recipients (to be found in both envelope and content). It is often the case that large attachments are sent to few recipients and that mail items to many recipients have small attachments (if any).

The postroom provides an additional control which can be used to limit the number of recipients in a mail item which by default is about 32K. When this limit is breached mail items are non- delivered with the message 'too many recipients'. To amend the value see the section "Limiting the number of recipients in a mail item" in the manual OfficePower Mail and Communications Administrator's Guide.

There are several reason to be wary about changing the size parameters and any administrator taking on the task should consider the changes made if the users of the system start complaining of problems. One final consideration to bear in mind when changing RTS parameters is that any subsequent rebuild of the postroom (when adding or removing a path, for example) may cause the RTS values to be reset, and this should be borne in mind if you experience problems after any such changes.


To increase the size of mail items permissible through your Postroom you need to perform the following tasks.
  • - increase "-maxoctets" parameter for the RTS initiators and responders
  • - increase the value of the "Maximum content size" for selected public capability records
  • - increase the UNIX 'ulimit' to accommodate larger mail items handled by the RTS

Examples of the changes required

Changing maxoctets value.

Check the names of your initiators and responders, this can be done by ls -l of [ICLMAIL]/miq/0Ainit or 0Cresp which will give you a list like :-


These are the directories that hold the queues of mail for onward transmission to another postroom, usually of the name following the first 2 characters, in this example 00 to 02.

Then you need to run the rts configurer program mrt.cfg.x with the following parameters:

[iclmail]/x/mrt.cfg.x OAinit 00elric iclmail -maxoctets 4194304

In the above example the first [iclmail] is the home directory for iclmail which in most cases is /iclmail, the second iclmail is the user iclmail not the home directory.

The 4194304 is the default decimal size provided and is currently 4 megabytes which caters for the envelope and content as described above.

Updating the capability records
This should be done from within OfficePower as user public.

The capability datafile has read only permissions and must be changed to allow write access, this can be done from within OfficePower or from a UNIX shell. Either:

chmod 644 [public]/pathdata~fl/capability~tb

from the UNIX shell, or use the OfficePower function "Change Datafile Group/Permissions" from the category "User defined Applications".

When the permissions have been changed to allow write access you can then update the datafile. The datafile and form to use are:

public public
pathdata stkforms
capability English

The following are examples of the records you will see in the datafile. When you open a record to edit it you will see the field "Maximum content length: 2048 (kbytes)" and the value should be increased as required, say 4096.

X400 CCITT X.400 1984 + ODA
X400+ CCITT X.400 1984 + ODA + ISO 6937
X488 CCITT X.400 1988 + ODA
X488+ CCITT X.400 1988 + ODA + General Text
Local OfficePower users
OP7.0 OfficePower 7.00

You need to increase the value for each record including the one with no name but a notes heading of Local OfficePower users (this controls delivery to local recipients). Beware that these values are not reset when reinstalling the capability datafile, this may be done by an RRP if we are adding new capabilities.

Top of page Return to the top of this page.

Home | Support | Download | Guide | Fact Sheets | User Group

Page last updated 31/May/2004 All rights reserved. Copyright © Brightkite Limited 2004