Increasing the Maximum Size of Mail Messages
Considerations
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.
Tasks
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 :-
00elric
01newton
02bra0130
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 |
| capability |
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.
Return to the top of this page.
|