yahMAIL Usage Guide

[next] [previous] [contents] [full-page]

7 - Considerations

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 Netscape Navigator/Communicator 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 Navigator has supported it (correctly) while Internet Explorer has not (or ignored it), then the 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! 


7.5 - MIME Attachments

Reading MIME attachments is made possible through a savagely hacked MUNPACK component from the MPACK 1.5 package (ftp://ftp.andrew.cmu.edu/pub/mpack/), Copyright © Carnegie Mellon University and used within license conditions. 
  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". 


7.6 - Processing Resources

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.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. 


[next] [previous] [contents] [full-page]