soyMAIL

Surprisingly Capable Web-mail for OpenVMS

Installation and Administration

Published January 2021 for soyMAIL v2.0.0

Document generated using wasDOC 2.0.0

soyMAIL – Copyright © 2005-2021 Mark G. Daniel

Apache License, Version 2.0

License

Licensed under the Apache License, Version 2.0 (the "License");

[email protected]
A pox on the houses of all spamers. Make that two poxes.

All trademarks within this document belong to their rightful owners.

The latest release of soyMAIL is available for download from

http://wasd.vsm.com.au/wasd/

Release notes for this version:

../release_notes.txt

Table of Content

1.Introduction

yahMAIL

soyMAIL is a native VMS application that executes as an HTTP server script providing authenticated Web access to an account's VMS Mail. All that is required at the client end is a (relatively) modern browser supporting CSS2/3 (Cascading Style Sheets 2 and 3). HTTP cookies are required for autogenous authentication. soyMAIL has been built on experience gained hacking about with its progenitor yahMAIL but unlike yahMAIL was designed from the start to satisfy all the basic requirements for a Web-based email interface. It is the author's (perhaps) humble opinion that soyMAIL is a more than worthy successor as the 'son of yahMAIL'.

soyMAIL was originally developed against these browsers

• Firefox 3.n (Win32, Linux)
• Mozilla 1.7 (Win32 and VMS)
• Opera 9.n, 10.n (Win32, Linux)
• MSIE 8.0, 7.0 and 6.0 (Win32)
• Apple Safari 4.0 (Win32)
• Google Chrome 5.0 (Win32)

• Chrome 63+ (MS Windows and macOS)
• Edge 21+ (MS Windows 10)
• Firefox 57+ (MS Windows and macOS)
• Opera 49 (macOS)
• Safari 11+ (macOS and iOS)

• Apache (SWS) 2.2 and 1.3
• OSU 3.10
• WASD 11.n, 10.n, 9.n

• Alpha
• Itanium
• x86-64?
• (VAX is no longer supported)

soyMAIL supports

• receiving and sending
• native VMS Mail messages
• Internet (SMTP) mail messages
• MIME messaging and attachments
• HTML (rich) message text
• messages of non-Latin characters and directionality
  (for example Arabic, Cyrillic, Greek and Hebrew)
• message content search
• contact (address) maintenance
• VMS style mailing lists
• context-sensitive help
• user options (including supported language)

soyMAIL has a private access mode that allows authenticated access to an underlying VMS account's email facility. This is where it provides the 'classic' web-mail functionality. It also provides a public access mode which requires no authentication (though it is not forbidden either) and provides controlled access to a specific folder, in a specific mail file, in a specific VMS account, intended to allow general access to a managed subset of a users Mail.

soyMAIL has been carefully and extensively optimized to perform well within the general VMS environment and when using callable Mail.

It uses VMS callable mail to access an accounts mail repository and to perform native VMS messaging.

Messages are originated via SMTP by connecting directly to an SMTP server (usually but not necessarily on the localhost), and therefore requires access to an (at least local) SMTP relay, in much the same manner as many client-based email agents.

JavaScript required

soyMAIL was originally designed to have the essentials usable without having JavaScript available or enabled. Increasingly the functionality allowed using JavaScript has become more entrenched in both browsers and soyMAIL so that now while it may be still be possible to use soyMAIL without it the developer neither has that as an objective nor tests that any functionality works without it. Similarly, backward compatibility with browsers originally developed and tested against is not guaranteed. If you are not using a relatively up-to-date browser then you should be, if only from the security consideration.

2.Installation

soyMAIL requires some configuration before use. It is recommended that this entire document be read and carefully considered before installation and attempted usage. Please use the facilities described in 7.1 Run-time Problem Solving when troubleshooting an installation.

soyMAIL soyMAIL is distributed as a source-code/run-time resource ZIP archive, with optional supplementary object code archives for each of the VMS platforms. For example, version two would be packaged

It may be built from the primary archive using DECC 6 and later, or link-only using in addition one of the supplementary object code archives.

Brief installation and other relevant information can be obtained from the archive using the UNZIP option.

Link-only

A link-only build has the following alternate steps which can be used in any environment described below.

Update

An update (which does not overwrite the configuration file) has the following alternate step and can be performed in any of the environments described below.

Run-time Components

The following table describes the run-time components. The installation procedure described below places these in the default locations the startup procedure expects to find them. Of course the default location and procedures are not mandatory. Components can be placed anywhere the site requires and a small, local startup procedure developed to use them from there.

The contents of the [.LANG], [.HELP], [.THEME] and [.TINYMCE] subdirectories in the soyMAIL distribution must be available to the server and script.

The INSTALL.COM procedure should provide a default run-time installation for each of the listed server environments.

2.1Authentication

soyMAIL can be configured to depend on the supporting Web server to perform authentication and authorization using the standard HTTP challenge/response or to use it's own (autogenous) authentication and state management.

The configuration guidelines in following sections contain both file mapping and authorization configuration examples. The file mapping configuration is always required to allow the client browser to access thematic resources. The authorization rules should not be configured when using soyMAIL autogenous login and state management. See 4. Autogenous Authentication.

2.2Apache (SWS)

This installation information is per SWS version 2.1. If you have a different version the requirements may require adjustment.

Apache requires the extra, script 'wrapper' procedure SOYMAIL.COM, so that the process-level logical name DECC$FILE_SHARING defined in the Apache scripting environment can be deassigned before the C-RTL is activated by the soyMAIL executable. This setting interferes with some soyMAIL file operations.

Mapping and authorization examples:

Depending on the planned authorization source it may also be necessary to check that the OpenVMS authorization module is configured.

Private access URI:

2.3OSU

It is suggested to place the soyMAIL kit under WWW_ROOT:[000000].

After installation files are located as follows.

Mapping and authorization examples:

Private access URI:

2.4WASD

With WASD the soyMAIL kit occupies the usual location for source under the WASD_ROOT:[SRC] directory.

Mapping and authorization examples:

Private access URI:

CGIplus

WASD provides the persistent scripting environment CGIplus. soyMAIL (1.6 and later) can execute in this environment. It remains resident and active for a period configured by the server. This can reduce response latency and system overhead significantly (request duration measurements indicate reductions of between 50% and 80% depending on activity). Just map soyMAIL into CGIplus space prior to other soyMAIL required rules.

Proctor

soyMAIL may be proctored (not sure what this means? — check section "Script Proctor" in "WASD Scripting Environment" document).

2.5SMTP Relay

soyMAIL originates SMTP Mail by directly communicating with a site's SMTP server. This requires that server to be enabled as an SMTP relay for at least the VMS system soyMAIL will be run on. The configuration for allowing relay varies on the TCP/IP and/or mail package in use (i.e. TCP/IP Services, MultiNet, TCPware, MX, PMDF, etc.)

The following example shows a possible configuration for HP TCP/IP Services (a.k.a. UCX) to provide this for the local VMS system running the soyMAIL script. The configuration option to enable relaying must be set.

And an entry placed in the plain-text configuration to enable access for allowed SMTP clients (the localhost).

The SMTP server that the soyMAIL script connects to is commonly running on the same (VMS) system as the script. It does not need to be. The configuration directive [SMTP-server-host] (see 3.1 Directives) can be used to specify and alternate host name or IP address (and non-default port if required) for soyMAIL to connect to.

2.6HTML Editor

TinyMCE is supplied as an integrated element of soyMAIL. Although soyMAIL itself has no specific requirement for installation on an ODS-5 volume, TinyMCE has file names containing multiple periods. UNZIPing the soyMAIL archive on an ODS-2 volume will generally result in UNZIP converting non-ODS-2 syntax elements into something legal for the file-system. Illegal periods are substituted with underscores. Of course TinyMCE will still be expecting multiple periods so the soyMAIL script is given these to munge into underscores on behalf of the file-system (well it's given all resource file requests but only munges those necessary). This does introduce some additional latency for non-ODS-5 environments. The capability requires some mapping rules.

These are the WASD example (modify to suit your web server):

3.Configuration

soyMAIL configuration is provided using a plain-text file located using the logical name SOYMAIL_CONFIG. The configuration file must exist or all access is denied. The installation procedure copies an example configuration file allowing private access and requiring some customization. Updates do not subsequently change this file. Comments may be included by prefixing the line with a '#' character. Each directive name is delimited by '[' and ']' characters and directive parameters comprise all text until the next comment or directive opening '['. Reserved characters may be escaped using the backslash character. Leading and trailing white-space is trimmed. Comments and directives must begin in column 1.

Tpical configuration file might look something like

Comments, directive names and directive data can be seen.

3.1Directives

The following table provides a summary of all directives, with those requiring more explanation expanded in following sections.

3.2[compose-charsets]

By default soyMAIL message composition is performed using the character set specified by the user-optioned language ([lang_charset] in the language file, commonly ISO-8859-1). The [compose-charsets] directive allows composition of a message in another character set and can be enabled in the user option file (for a per-user configuration) or the soyMAIL configuration file (for site-wide availability). Each item is then displayed in a selection list on the message composition page.

The format for each item of the directive is

The following example provides a selection of Arabic, Greek and Hebrew.

An equivalent field is available in the user options.

During message composition the desired character set must be selected by the user before entering any message text.

3.3[compose-user-from]

When this directive is ENABLED the message composition page provides an additional "From:" text entry field (immediately above the"To:" field) allowing the user to easily change the message origination (From:) address. Of course while there are legitimate uses for this facility it does provide potential for a certain no-brain email spoofing. If DISPLAY then the same field is provided for informational purposes but cannot be modified.

When ENABLED it also allows one or both of two additional directives to be prepended to a user signature. When the signature is appended to a message these directives set the From: and/or Reply-to: fields of the message. This facility allows various email "personas" to be maintained simply and associated with messages as required.

An example showing the specification of both:

Note that there already exists the user option [SMTP-from] that allows specification of prefered From: field. To administratively disable this facility completely override the user option with a configuration specifying an exclamation point, such as:

3.4[html-editor-load]

soyMAIL supports plug-in JavaScript HTML editors for HTML message composition.

TinyMCE is provided as part of the soyMAIL package. This is enabled by having an asterisk as this directive's parameter; disabled by having the parameter empty.

Another editor may be used if desired. The functions htmlEditorContent() and htmlEditorLoad() must be present, being an onload=target for the document. If the parameter contains a script> keyword the JavaScript overrides the default TinyMCE initialisation.

The following is an example:

3.5[logout-realm]

This configuration directive only applies when using Web server authorization. It is not needed and is not used when using soyMAIL own authentication and state management (see 4. Autogenous Authentication). The following description only applies to Web server HTTP authorization.

The soyMAIL [logout] button and functionality is based on a Kludge that tries to hoodwink the browser into thinking its cached credentials are no longer valid. It does this by returning an HTTP 401 response (authentication required) itself as a response to hitting the [logout] button. The idea is to present to the browser a refusal to use the supplied username/password against the request path whereupon the browser purges the entry from its credential cache.

As described above this is a Kludge with a capital K. Why HTTP/1.1 didn't include a 418 (authorization canceled) cancelled or some mechanism such as this or know! Not only are there inconsistencies in the way browsers handle this (hence the credential clear, [ok] and final [cancel]) there are some issues in getting a CGI application issued Status: 401 authorization required through the server sufficiently unscathed and functional as to be recognised by the browser as an authorization refusal. So...

WASD handles all this with its usual panache :-)

VMS Apache and OSU need some additional working-around. Hence the [logout-realm] directive. Unless this is set the [logout] button is greyed-out (italicised) and the functionality disabled. This must be set to exactly the same string used by the authorization realm configured against the soyMAIL path in the servers configuration. If it not exactly the same string some servers go into infinite loops, some browsers re-request ad-infinitum, etc. You have been warned!

For an Apache configuration of:

the soyMAIL configuration would be set

The soyMAIL configuration directive may also be set to a single hyphen to disable the logout button and functionality.

3.6[private-access]

Private-access is a term used to describe a client making authenticated access to an underlying VMS accounts email facility.

The private access URI must have been made subject to either Web server authorization, or to soyMAIL autogenous authentication (section 4. Autogenous Authentication). If there is no browser username/password dialog, or no login page, then it's not configured correctly!

soyMAIL identifies private access when the path has the leading characters /~. For example, in the case of Apache and WASD

Alternatively, a site-specific private sentinal can be configured using the [private-request] configuration directive (see 3.7 [private-request]).

There needs to be a explicit configuration directive to enable private access and optionally to map between authenticated users and VMS usernames. The general format is

The realm allows WASD authentication realms to be factored into the mappings but almost always will remain an asterisk.</p> <p class="western">If there is a one-to-one correspondence between the Web-server authenticated user name (as it is common to use some form of SYSUAF-based authentication this is usually the case) then a simple rule against the directive is enough to allow any user access to Mail.

Specific accounts can be denied access by deliberately disrupting the mapping. In this case the SYSTEM and ANOTHER accounts are mapped to non-existing accounts _SYSTEM and _ANOTHER.

Using the same mechanism a non-VMS-account remote user may be mapped into the mail of an existing VMS username.

Postmaster

POSTMASTER is a flag that can be placed against any user name. It allows a username to be specified in the soyMAIL path different to that of the authenticated username (normally this will result in a soyMAIL “insufficient privilege or object protection violation” fatal error). For example

This postmaster can then do anything using soyMAIL the specified username can do. Such an account is flagged in the following manner.

Note that POSTMASTER here is not an account. It is a soyMAIL characteristic flagged against the username. The parentheses are required.

3.7[private-request]

By default the leading characters /~ of the path indicates to soyMAIL a private access request. This directive overrides that tilde sentinel and allows any request to be recognized for private access. It intended to be used inside a conditional configuration test (see 3.12 Conditional Configuration) based on some characteristic of the request reflected in a CGI variable.

The following example shows a configuration test for the presence of a REMOTE_USER variable indicating it is a request subject to server authorization.

This effectively directs soyMAIL to consider any such authorized request is private access.

The second example shows a test based on the request script name and assumes that the server has mapped the path /mail onto the soyMAIL executable.

The first leading caret indicates it is a regex pattern; the second a regex 'beginning of line' symbol; then the string used to activate soyMAIL; and a regex 'end of line' dollar symbol. This makes it an exact match test.

Note that the [private-request] directive must be specified before the use of any directives </font></samp>that rely on recognition of private or public access (e.g. [if-private], [if-public], [private-access], [public-access], etc).

3.8[public-access]

This facility is intended to allow general access to a managed subset of a users Mail. Public access requires no authentication (though it is not forbidden either). There are three variations on public access. The first rigidly controls access to a specific folder, in a specific mail file, in a specific VMS account. The second, a wildcard folder specification, allows access to any folder in the specified mail file and account. The third, also a wildcard specification, prohibits access to the account MAIL and NEWMAIL folders.

The general format is

Both wildcard variants allow an initial folder to be specified

The public path string is used in the URL and need not be related to any part of the real components of the mail access.

The first rule would map the URL

The third rule maps the URL

3.9[search-control]

Mail message searching can be a very compute and I/O intensive activity. Essentially soyMAIL searching is performed on two levels with significantly different expenses.

• Message header content. From, to, cc, subject and date parameters are all available via callable Mail without needing to access the message body. This makes searching on these very inexpensive.
• Message body content. This requires not only reading the body of the message but also commonly decoding the MIME content of messages and can be quite expensive. In addition performing a textual search of the body of a message is obviously a source of intense CPU activity.

Regular expression matching is significantly more CPU intensive than keyword matching.

The following parameters to the [search-control] directive allow fine control of the extent of search capability to assist in managing the system impact of this activity. Conditional configuration (see below) makes it possible to apply these to some requests and not others. One or more, space-separated, can be used against the directive.

3.10[smtp-default-host]

This directive allows a host/domain name to be automatically appended to an unqualified user name (i.e. an address with a local but no @domain part). With this set to the.host.name entering an address of Mark.Daniel would result in a send to [email protected].

soyMAIL adds the default host/domain part before sending or whenever the page is refreshed. The modification to the address can be requested at anytime by selecting the [compose] button and thereby refreshing the page.

Setting this directive disables a default send via VMS Mail. VMS Mail can still be used by prepending a node name to the address (e.g. '0::DANIEL', 'DELTA::DANIEL', etc.)

3.11[update-last-login]

For sites with a requirement to track continued account usage this directive results in the SYSUAF interactive or non-interactive (default) last-login datum being updated with each initial access. An initial access is defined as a startup GET request from entering the private access URL into the browser or selection of a bookmark/favourite. Continued use of an established session (using the buttons or new mail check facility) does not result in updates to the last-login date/time.

Parameter to this directive should be INTERACTIVE or NON-INTERACTIVE.

3.12Conditional Configuration

soyMAIL has a useful facility allowing dynamic configuration of soyMAIL processing based on request characteristics and CGI variable content. This allows a single configuration file to support multiple site appearances or capabilities.

Conditional directives begin with a test. Some are booleans. For CGI tests it either looks for the keyword provided with the test directive in the specified CGI variable value, or uses it as a regular expression (regex) to match against the variable value (EGREP compliant). A regular expression must be prefixed by a caret character ('^') which of course is not used as part of the expression. If a CGI variable doesn't exist it is treated as an empty string.

Keyword Example

Equivalent Regex Example

Regex Equivalents of Common Wildcards

Tests

Empty and non-empty strings may be tested for using an empty parameter to the directive.

If the variable contains a value then the following test will be true. If the variable does not exist or has an empty value then it will be false.

If the variable does not exist or contains an empty value then this second test will be true. If it contains a value then it will be false.

Conditional Configuration Example

3.13Regular Expression Overview

soyMAIL employs the GNU RX1.5 regular expression package. Evaluation is done using case-insensitive, EGREP-compatible matching. A detailed tutorial on regular expression capabilities and usage is well beyond the scope of this document. This summary is only to serve as a quick mnemonic. Also see

https://en.wikipedia.org/wiki/regular_expression

The following operators are used to match one, or in conjunction with the repetition operators more, characters of the target string. These single and leading characters are reserved meta-characters and must be escaped using a leading backslash ("\") if required as a literal character in the matching pattern.

Repetition operators control the extent, or number, of whatever the matching operators match. These are also reserved meta-characters and must be escaped using a leading backslash if required as a literal character.

Checking Regular Expressions

soyMAIL can be used at the command line to check the results of regular expression pattern matching. This can assist with creating conditional configuration. Assign soyMAIL as a foreign verb and use as illustrated.

4.Autogenous Authentication

Access to private Mail via soyMAIL always requires user authentication. This may be performed as HTTP authorization by the supporting Web server (and passed as CGI variable REMOTE_USER), or by having soyMAIL maintain it's own authentication state. This section describes the latter.

The main advantage in allowing soyMAIL to manage it's own authentication environment is a clearly defined login-usage-logout life-cycle, something at best a kludge with HTTP authorization. It provides a one-click [logout] button that really works!  

The client browser must support and have enabled HTTP cookie functionality. A cookie is used to store and propagate the authentication state. The cookie expires at the close of the browser. The cookie value is encrypted using the industry standard RC4 algorithm. This data is only present as plain values inside the processing of soyMAIL.

soyMAIL authentication

• accepts the VMS username and password via it's own login page
• verifies those credentials
• maintains verified credentials for the duration of the session
• session is terminated by using the [logout] button, or fully closing the browser

In addition soyMAIL

• continues to verify the credentials periodically
• will request the credentials be reentered after an idle period

The internal authentication mechanism (site-specific, external authentication is possible, see 4.4 External Authentication Agent) depends on the VMS platform and version.

• For Alpha and Itanium with VMS V7.3 or later it uses the ACME authenticator and $ACM system services. This is a vendor maintained service and so may be considered as-good-as bullet-proof. It supports everything ACME supports including DOI, external authentication, intrusion management, etc.
• For VAX and VMS versions earlier than V7.3 it uses a combination of $SCAN_INTRUSION, $GETUAI and $HASH_PASSWORD to parallel most of the relevant functionality provided by ACME. These include intrusion management and account login constraints. It's potentially not as bullet-proof as the vendor solution and should be used advisedly.

Further discussion will be confined to ACME authentication.

With autogenous authentication any account that can normally login to the supporting VMS system can access soyMAIL. To restrict an account it is necessary to deny access using the [private-access] directive (section 3.6 [private-access]).

Technical detail on the encryption algorithm, authentication code, cookie structure, etc., can be obtained from the descriptive prologue of the LOGIN.C source code module.

4.1Configuration

If Web server authorization for soyMAIL is currently configured then disable this before proceeding further. Behaviour with both enabled is indeterminate.

Autogenous authorization is enabled by configuring a value against the soyMAIL configuration directive [login-secret]. This is used as a key to encrypt the soyMAIL credential cookie value. When this directive has a value against it soyMAIL attempts to establish it's own authentication state. As this is an encryption key care should be taken to ensure it is

• as long as practicable (soyMAIL insists on a minimum of 24 characters)
• comprises a 'random' mix of mixed-case alphanumeric and punctuation characters
• kept secure (SOYMAIL.CONF is not world-accessible, etc.)

An example configuration might be

4.2Password Change

soyMAIL authentication will detect an expired password for DIALUP, LOCAL and REMOTE login types. ACME does report expiration for NETWORK (the default). An expired password will fail unless [login-no-pwdexp] is ENABLED or soyMAIL password change is configured and the password must be changed at login.

Password change is enabled by specifying the location of the change dialog HTML (also see 4.6 CHANGE.HTML). Using the default file that would be

As with authentication password change is either performed by ACME or a soyMAIL code path. The latter is rudimentary and does not include such desirable facets as dictionary and password history checking. Platforms without ACME available should avoid enabling password change.

The following configuration directives will modify the login type from the default NETWORK. Choose a type in-line with site policy.

4.3Login Alias

For autogenous authentication the configuration directive [login-alias] allows the supplied user name string to be mapped to another string before being used for authentication. For example, this might allow the user email address, or local mailbox name, to be used as the user name and mapped to an actual VMS username before authenticating against the SYSUAF. In fact any arbitrary string can be mapped to any other. The alias mapping is performed using a case-insensitive match.

The format is one alias mapping per line, with the supplied user name to be matched on the left, a forward-slash, and the username to be authenticated against on the right.

If a match is not made and no mapping has occurred the default (drop-through) behaviour is to use the original supplied user name string and so in the above configuration both "Mark.Daniel" and "DANIEL" would authenticate against the DANIEL account, "Fred.Bloggs" and "BLOGGS" against BLOGGS. Of course any other supplied user name could also authenticate directly. To prevent any other than an aliased user name being used for authentication conclude the list with "*/-".

In the above example only "Mark.Daniel" and "Freg.Bloggs" can be authenticated.

The (somewhat redundant) mapping "*/*" will terminate alias processing and explicitly direct authentication to occur using the supplied user name (the default drop-through behaviour anyway).

The configuration directive [login-alias-smtp-from] when ENABLED uses any such mapped alias as the local part of a compose page self address ("From:") In this way an alias such as "Mark.Daniel" would be used to build an address [email protected]

4.4External Authentication Agent

This provides a site-specific, external-to-soyMAIL authentication mechanism. If the [login-agent] configuration directive exists then it activates an external authentication DCL procedure within a subprocess. The DCL procedure must be specified following an '@' symbol and must have execute permission for the scripting account. For example

Optional parameters can be provided as part of the configuration directive:

When activated the procedure has a further three parameters appended to any supplied in the above configuration directive; "<username>", "<password>" and "<remote_addr>", to be used in the authentication processing.

The procedure should exit with any success status (e.g. SS$_NORMAL) to indicate successful authentication or any error status (e.g. SS$_NOPRIV) to indicate authentication failure.

This is a (very simple) example.

This would probably be more like a working one.

4.5LOGIN.HTML

The HTML used in the login page is derived from a file. The default is [.THEME]LOGIN.HTML and contains a functional login form and layout. This can be customized to include a site theme, logo, information, etc. Care must be taken not to disturb any of the core functionality of the HTML form, form fields, etc.

So that subsequent updates to not overwrite modifications to the base LOGIN.HTML It is suggested to copy this to something like _LOGIN.HTML and then set that as the login page via soyMAIL configuration.

4.6CHANGE.HTML

The HTML used by the password change page (see 4.2 Password Change) is also derived from a file. The default is [.THEME]CHANGE.HTML and contains the required elements to support the change dialog. Like the login page it can receive some customisation where care is taken not to disturb its core functionality.

As with the login page it is suggested a copy be modified and configured.

4.7Access Log

When autogenous authentication is in use the Web server does not perform the authorization function itself and as a result the 'remote user' datum, usually included in server-access logs, is not available. Which accounts are using soyMAIL is often useful or mandatory audit information and so soyMAIL provides this as a supplemental access log file.

A configuration directive enables the facility and allows a file specification to locate the log.

To assist in the maintenance of such logs soyMAIL will rotate the file name based on time using (perhaps familiar) formatting directives included in the configuration directive. For example, to include the year in a soyMAIL access log file name use

In a similar fashion, to include the month add a second numeric formatting string, and the day-of-month a third, as illustrated in the following two examples.

soyMAIL enables SYSPRV to access the file and so it may be located in a protected area of the file-system.

This file is provided in the NCSA-style 'combined' format only to allow processing by common access log file tools if desired. All fields are present and valid except the 'bytes' datum which always contains zero. Of course this log is only intended to supplement the server log, not supplant it.

5.Customization

soyMAIL provides three levels of customization.

• locale
• site
• user

5.1Locale

The [.LANG] directory contains the default English language message file, EN.TXT. This can be copied to another, language-indicative file name and the text of the messages modified appropriately. The content of these files is not intended to be used for site-local changes to messages. Directives in the soyMAIL configuration file are for this purpose. The language files are global components of the soyMAIL distribution.

If you wish to put a language-specific message file together for soyMAIL please contribute it back into the soyMAIL community. Note that messages can be used in all sorts of contexts, particularly inside string literal quotes - both single and double. It is therefore necessary to substitute the HTML entities &quot;, &rsquo;, etc., for anything that might be misinterpreted as JavaScript code quotes (i.e. " (0x22) and ' (0x27)). If soyMAIL reports a message file fatal error the SOYMAIL$WATCH facility (see 7.1 Run-time Problem Solving) can be used to help determine the underlying problem.

The [.HELP] directory contains the default English language, on-line, content-sensitive help files. These contain the help information and HTML markup. Each file name contains an indication of the language, where the English version might be HELP_EN.HTML, the French language version HELP_FR.HTML, etc. These files are dynamically accessed and composed by soyMAIL when a user accesses on-line help. The users language option is used to search for a possible file with that language indicated in the name. If not found it supplies the default English language version. One or (preferably) all of each of the help topic files can be copied to a language-specific instance and translated. As with message files please make any such resources available to the general soyMAIL community.

5.2Site

The soyMAIL configuration file has several directives intended to allow site-specific information to be included in soyMAIL pages at appropriate locations.

• [help-about-site]
• [help-local-text]
• [message-list-footer]
• [page-title]
• [page-title2]
• [print-header]
• [print-footer]
• [soymail-at-title]

The SMTP host and apparent source of messages can be specified.

• [SMTP-server-host]
• [SMTP-from-host]

The obviously VMS-specific portions of soyMAIL (e.g. the VMS options panel, the extract button) may be 'hidden'.

• [VMS-occluded]

Local User Option Defaults

Users options may be defaulted and overridden.

• [user-options-default]
• [user-options-override]

For example; to provide a language default other than English, perhaps German:

To force a site to use a particular (perhaps corporate) theme

The user option to specify a "From:"address line can be disabled with

Two Notes

• The user-option directives used as parameters in these examples must be escaped.
• Themes beginning with an underscore will never be overwritten by a soyMAIL update. soyMAIL never will include themes beginning with an underscore.

Local Help

In addition a site-specific help file can be created in the [.HELP] directory. It must be named SITE_language>.HTML (note the leading underscore, which means it will not be overwritten by a soyMAIL update, and the language component). If this file is found during help composition it is appended to the primary help page (that obtained in help by using the [help] button) and is intended for providing site information and/or links of local relevance.

5.3User

The options button in the main menu provides on-line access to user option settings.

In addition there are some less commonly used options that must be manually edited into the options file. The file is named SOYMAIL_OPTIONS.TXT and located in the user's mail area (with MAIL.MAI). Once inserted they are propagated during on-line option changes.

6.soyMAIL User Files

soyMAIL creates and maintains several files in the same directory as the users MAIL.MAI file. The names are all prefixed with SOYMAIL_ (an underscore). Needless-to-say these files should not be deleted or edited without good reason and care. Doing so potentially disrupts the users soyMAIL environment. Some, all, multiple instances, or none of these may be present at any given time.

Extracted Files

The soyMAIL message read attachment (message part) extract button (where not VMS-occluded) allows message components to be written to the VMS user account home directory. All files created have the name prefixed with SOYMAIL- (a hyphen) and the rest generated from the attachment/part name. If that part name contains a file type (e.g. .GIF, .PDF, .TXT) then that is used in the name. If it does not contain such a type then soyMAIL attempts to generate one from the MIME content-type.

7.Miscellaneous Topics

Miscellaneous soyMAIL features and other topics.

7.1Run-time Problem Solving

When an error is reported, either fatal or in the status panel, the source code module name and line number of the reporting point is included as an HTML comment (the page source needs to be opened and searched) to assist in locating and rectifying issues.

Defining the system-level logical name SOYMAIL$WATCH to either TRUE or the IP address of the client to be observed provides a plain-text report designed to assist in solving configuration or software issues with soyMAIL.

7.2Inconsistent State Data

To prevent data corruption and inconsistent behaviours soyMAIL performs integrity checks on the state data it propagates from request to request. It is possible for a user session spanning a soyMAIL update (version release) to see the following error status message.

This is of no concern. The change in version has been noted by the software and to prevent any potential inconsistencies in data structures causing subtle or gross problems it has reinitialized the state data resulting in an effectively empty session. The user should just reopen (<u>not</u> refresh/reload) the particular page.

The second variation of this message is a little more concerning.

soyMAIL maintains a hash of the state data which is propagated with it. The hash is recalculated and compared at the next request. This error reports the comparison failed and indicates data corruption in the request state. The session is effectively emptied as a precautionary measure. Instances of this message should be very rare and if persistent carefully investigated.

7.3Site Contact / Mailing Lists

The logical name SOYMAIL_CONTACT_LIST can be used to specify a logical list of contact lists (in addition to any personal contacts). This functions as a multi-value logical name with each value being the logical name for, or actual file specification of, an LDIF list or a traditional VMS-style mailing list (each line in the file contains a single address). For example:

Where ALL_USERS_LIST is a VMS-style, so are GROUP1_USERS_LIST and GROUP2_USERS_LIST. MAILING_LIST_LIST is a file containing a VMS-style mailing list of the mailing lists supported by the system. For the above it might contain five lines with:

These can then be selected to mail to the entire list.

LDIF Address Lists

Even large LDIF address lists (hundreds or thousands of items), such as might be exported from corporate MS Exchange servers, can be loaded relatively efficiently by soyMAIL. This can be further improved through processing the list using soyMAIL as a command-line utility.

This purges all but soyMAIL relevant elements from the data.

7.4General Access To Help

Context-sensitive help is available to authenticated users accessing private mail. A page built from the consolidated help information (and distinctly resembling the print page for context-sensitive help) is available for unauthenticated (general) access. Use the following URL to access this page.

8.Index