[next] [previous] [contents] [full-page]7.1 - Client-Server
7.2 - Concurrent Access
7.3 - Page Layout and Behaviour
7.4 - Browser Behaviour
7.5 - MIME Attachments
7.6 - Processing Resources
7.7 - System Impact
7.8 - Security
7.9 - Change Summary
yahMAIL does not pretend to be the ultimate solution in
supporting Web access for VMS mail. It provides a basic, but functional
service. It has many trade-offs, not least of which is available development
time (see Page Layout and Behaviour below). Initial releases have
proved popular (and certainly better than none at all for some sites) so it may
be expected that the user interface will receive more attention as time
permits. Comments and suggestions are welcome.
7.1 - Client-Server
VMS Mail was never really intended for a client-server environment.
The opening and closing of mail files and contexts with each request adds
significant overhead to the transaction and system alike, particularly when
folders have large numbers of items.
7.2 - Concurrent Access
Nor was Mail intended for multiple, concurrent access (although of
course VMS' file system competently handles any contention for resources at
that level). It is not recommended that this interface be used in environment
where it is likely multiple clients will be accessing the one account during
the same periods. Messages do not have a unique identifier and it is difficult
to establish whether a file and/or folder has had it's contents modified
between transactions so it becomes possible to inadvertantly specify an
unintended message (e.g. delete the right message number but the wrong message
item!)
7.3 - Page Layout and Behaviour
Page layout and behaviour is always a compromise between available development time, varying browser behaviours, personal preferences (e.g. frames vs. non-frames), lots of graphics vs. 33kbps modem speeds, tables vs. free-form, plenty of white-space and scolling vs. compact but busy pages, etc., etc.
For dynamic mail environments, such as a user's personal account, it is reasonable to remove the responsibility from the user for the refresh of folders etc., as the contents change with message movements, deletions, etc. For keeping this state infomation, and other reasons of functionality, a limited use of JavaScript is undertaken. It is deliberately limited so as not to make yahMAIL totally dependent on it, but still capable of being used with a non-JavaScript enabled browser (albeit with some functionality reductions).
A moderately dull format but generally functional approach is used, based
on a single, "flat" page containing all activity. To restrict large
history list contributions (i.e. lots of nesting pages) the JavaScript limits
all folder activity to a single page (opening another folder never creates
another page) with all messages read in a single child of that folder page,
with the replying or forwarding it, or obtaining a plain-text copy, creating a
third page. After opening dozens of folders and reading hundreds of messages,
at most three back buttons should remove the user from
yahMAIL completely.
7.4 - Browser Behaviour
The software has been developed against the latest releases of OpenVMS Mozilla, Netscape Navigator/Communicator (OpenVMS and non-OpenVMS) and Microsoft Internet Explorer. When differences in behaviour have been noted, where feasable, both have been allowed for. However, where a facility has required a particular, either standard or well accepted behaviour, and Mozilla/Navigator has supported it (correctly) while Internet Explorer has not (or ignored it), then the Mozilla/Navigator behaviour has been implemented for.
A small but typical example.
Adherence to the MIME content-type specified in an HTTP response. Make a response's content-type "text/plain" and return a body containing HTML markup tags and Navigator displays the contents as plain text. Not so Internet Explorer, it insists on displaying an HTML-rendered page, despite you specifically requesting otherwise!
Copyright 1993,1994 by Carnegie Mellon University Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation
Sending MIME attachments is supported for mailing environments using Innosoft (iPlanet?) PMDF. For some other environments this is also possible ... just! See the descriptive prologue to YAHMAIL.C for further detail.
Variable-Length Record Format
When uploading attachments from a VMS system (via the filename-entry field or associated browse button) the files cannot be variable-length record format (at least with Netscape Navigator 3.n). Files must be stream, fixed or undefined record format. The general symptom is the request "hanging".
The times associated with the processing of large email messages, generally those containing MIME attachments, must be taken into account. This includes not only the times required to upload or download messages or attachment files, which may demand adjustments to server period timeout parameters, but also the time required for the VMS mail system and associated script to process the message. Although yahMAIL is built for processing messages using dynamically allocated storage, both script process resources and the above mentioned processing constraints put practical limits on the sizes of messages and associated attachments. It may also be expected that scripts eventually will exceed process quota limits with large messages. The results when sending and receiving these large messages is therefore somewhat indeterminate.
As some indication of what may be expected; a 2890kB MS Word document sent
as a Mail attachment using Netscape Communicator 4.6 on a 128Mb, Pentium NT 4.0
system, via an intranet to a WASD HTTPd on an Alphaserver DS20 500 Mhz, took
approximately 3 seconds to upload, then a further 32 seconds processing time,
with 6 seconds CPU time, to complete the mailing.
7.7 - System Impact
The opening and closing of mail files and contexts with each request incurs
a not-insignificant overhead. If items such as sender names, subject contents,
etc., are being selected against this adds futher processing
overhead as record comparisons are made. Of course, access to users' active
VMS Mail environments is not possible without this but the serving of mail
archives in this fashion involves very much greater processing than from
static, "flat" files. For sites with very large or high demand archives
another approach should be considered.
7.8 - Security
Any generally accessable facility with an enhanced privilege is a concern. yahMAIL requires SYSPRV to access protected Mail files, and through the callable Mail interface to the SYSUAF (access to Mail username detail). Every effort has made to guard against programming error and/or bug making this a security loophole.
Making a system's Mail available on-line has obvious appeal in many circumstances. However this should not be undertaken lightly. It introduces yet another possible vulnerablility.
Compounding this are the capabilities of a POSTMASTER. This must be expressly enabled, both in the configuration file and as a qualifier against the script before anyone can be mapped against it. There may still be philosophical objections to having an easy interface into other users' mail, even for system administration purposes. The author sees no problem in providing such a capability, after all the are a number of other impersonation facilites for VMS, and anyone with SYSPRV must be implicitly trusted anyway :^) otherwise it couldn't be risked giving it to them!
Reasonable care must be exercised in managing the YAHMAIL$CONFIG file. Access assessment is designed to restrict rather than allow where there is no rule explicity providing access.
Of course there is always concern with the transmission of clear-text
username/password information, particularly for access to system resources. It
is therefore well advised only to use this facility over standard HTTP within
the most secure of internal LAN environments. If used with Secure Sockets
Layer (SSL) encryption over HTTPS there is far less reason for concern, even
for access via the Internet (particularly when using full-strength, 128 bit
keys). See 6.3 - Authorization for one method WASD
installations may employ to restrict authenticated access to SSL transactions.
7.9 - Change Summary
v1.6, March/June 2002
Some minor bugfixes have been added during 1.5.0 to 1.5.3, also problems
preventing correct operation with non-English language versions have been
addressed (thanks Frank Weichert). In addition, message header fields with
"encoded words" are now decoded and displayed (assuming the browser
supports the character set), and quoted-printable message bodies are displayed
decoded. In both cases to see the original message choose "text" with
either the VMS or RFC812 header displayed. All message header addresses now
have VMS Mail transports stripped before display (e.g.
SMTP%"Mark.Daniel@vsm.com.au" is shown as
Mark.Daniel@vsm.com.au). There are two new configuration
directives; [encoding] allowing specification of how outgoing messages containg
8 bit characters should be encoded, and [vmsmailfooter] and it's associated
guide.
v1.5, January 2001
A couple of minor bugfixes. CGILIB can now interface with CSWS V1.0-1
(OpenVMS Apache 1.3.12). A new private setup long line wrap item
allows message read wrap long lines to be permanently set.
Configuration directive [localtosmtp] allows a local VMS username destination
address to be delivered via the SMTP agent.
v1.4, October 2000
Very minor changes. CGILIB is now delivered by object module. The
addition of a message read checkbox allowing the message to be
reloaded with long lines wrapped.
v1.3, April 2000
This most-requested feature, sending mail messages with MIME
attachments, is now available for some platforms (see
7.5 - MIME Attachments). The original YAHMAIL.C code module had grown
far too unwieldly and has been split into a number of modules, based on
essential functionality. The DELETE! button has been bugfixed and now again
deletes messages immediately (with the corollary that it also purges the
WASTEBASKET at the same time). The number of rows of the create-send edit
window can now be specified in setup. A pre-edited message can be uploaded
into the create-send edit window. Additional footers providing
on-line "help" material in major windows.
v1.2, January 2000
Contains a significant bugfix from the v1.1 release. The only
functional change is the addition of a JavaScript-driven checkbox that allows
checking/unchecking of all message checkboxes on a private browse page (it's
interesting how many things become desirable once you start using something
yourself :^)
v1.1, December 1999
Added private browser page setup fields with the ability to locate
selected functionality above or below the message list, and
"convenience" buttons MAIL, SENT, WASTEBASKET and EMPTY. These are
intended to make it a little easier to perform common actions such as
relocating read mail, copy-self, and grouping discarded mail (then deleting it
as a whole).
v1.0, August 1999
Initial release.