Subject: [Info-WASD] soyMAIL
From: [email-masked]
To: [email-masked]
Date: Wed, 23 Jul 2025 14:57:51 +0930

son of yahMAIL  in 2006 grew from the 1999  yet another hyperMAIL 
━   ━  ━  ━━━━                              ━   ━       ━    ━━━━
itself borrowed from the also borrowed idea of Jonathan Boswell's
HYPERMAIL.FOR for accessing native VMS email using callable MAIL$.

Summarised by Jonathan in his 2002 cover note:

 "Finally, Mark Daniel created YAHmail [sic] (yet another hypermail)
  for his WASD server, and then ported it to other servers as well.
  This is probably the package of choice for those who want simply
  to read their own VMS mail via the web."

  http://newtrumpet.org/hypermail/

2005 saw the final release of yahMAIL and early 2006 superseded by soyMAIL
which from a less developed (but fully functional) beta has continued adding
capability for some twenty years.  Written by "one of the stampeding hordes
who have known only C" (not really, I started off with Pascal, then COBOL,
never FORTRAN).

Echoing Jonathan's summary;

  soyMAIL is probably the package of choice for those who want
  simply to read their own VMS mail via the web.

I've been eating this brand of dog food for a quarter century 😐

Most of the elements mentioned in this article can be seen in

  https://wasd.vsm.com.au/wasd_root/src/soymail/doc/soymail_overview.html

Functional Elements
~~~~~~~~~~~~~~~~~~~
Legend has it, VMS MAIL originated as a '70s weekend 'skunkworks'꙳¹ project,
available via an unofficial API in the '80s, rewritten in C in the '90s, and
currently documented as the callable MAIL$꙳² API.  Naturally, a
significant portion of soyMAIL functionality deals with this API and the
underlying RMS files providing the on-disk storage.

soyMAIL can provide VMS-only mail.  That is, account-to-account email.
But in the '80s wider communication, via SMTP꙳³ and various client
protocols꙳⁴, became essential.  Hence, another major functional element
is the Internet facing code with access to other (mail) systems using TCP/IP.

The third element provides for multi-part and multi-media email content.
The MIME component.

Lastly, the web interface which integrates all the functional elements for
the client browser.

'Surprisingly Capable'
~--------------------~
soyMAIL was conceived as being an 'enterprise' level application for VMS.
Now bills itself as the more modest (some would say more accurate)
'Surprisingly Capable Web-mail for OpenVMS'.  

It does provide for language-specific customisation.
Currently; German, English, Spanish, French, Italian, Netherlandic.
All (except one) provided by the end-user community.

Message display and composition provides for any script (characters) a client
browser supports, including script directionality (e.g. left-to-right;
English, French, and right-to-left; Arabic, Hebrew).

Options allow for signifiant user-level customisation.

Context specific help (when reading, composing, etc.) is available via a page
[Help] button (currently German and English only).  A useful [About] on the
help page provides soyMAIL and server information.  Help may be reviewed at

  https://wasd.vsm.com.au/cgiplus-bin/soymail?help

HTML Content
------------
soyMAIL is fundamentally a plain text oriented application.  As noted below,
it does provide for rendering HTML-only email content as plain text.  It also
provides for editing HTML when replying to, or originating, HTML content.
This HTML is always sanitised before rendering.

Message Presentation
--------------------
The processing varies on the message content source, plain-text or HTML.

1) Plain text undergoes minimal processing.  It can be sourced from a vanilla
text massage, or a MIME (perhaps but not necessarily multipart) text/plain
content-type.  Escaping HTML entities (e.g. '<'), limiting line lengths, and
making obvious URLs clickable.

2) Plain text generated from an HTML-only message, either in-line HTML or
MIME (not necessarily multipart) text/html component.  soyMAIL sanitises HTML
content to strip out potentially disruptive (e.g. <style>) or even dangerous
elements (e.g. <script>) and transmuting white-space tags (e.g. <p>) and HTML
entities (e.g. &lt;) into plain-text equivalents.

3) Rendering HTML (via [Read HTML] button) requires sanitisation somewhat
akin to plain-text generated from HTML but seeks to preserve more of the look
and feel, and some other content, of the HTML original.  By its very nature,
HTML sanitising is a bit hit-n-miss.  Well structured content remains well
structured.  Content relying on the machinations of DOM and CSS, less so (I'm
lookin' at you here MSO).

Of course the HTML original, in all its glory and potential downsides (e.g.
tracker pixels*⁵), can be rendered using the "[message_part_𝑛][^]{text/html}"
button at the bottom of the message page.

Buttons also allow access to the entire raw message and the raw RFC header.
This allows ready inspection of either, particularly the header can be
instructional regarding the real origin (in contrast to that reported) and
delivery path of a particular email.

Attachments are listed after the message body and any un-named parts by
original file name.  Images will ([Option]-ally) be displayed in-line.  Other
content-types generally allow downloading.  A content type edit box allows
tweaking the file content-type (e.g. application/octet-stream to
application/pdf of a .PDF file for in-browser display rather than download).

Message Composition
-------------------
The main folder page has a [Compose] button, allowing an empty composition
page to be opened.  Displayed messages can be [Reply]-ed to, as well as
[Reply to all]-ed, [Forward]-ed, and [Edit as new]-ed (opened in a
composition page with blank header elements).

A [Preview] button displays the rendered message much as it will appear to
the receiver.  It is often useful to check the preview as errors seem more
obvious in a non-composition context.

The [Send-Close] mails the message and closes the composition page, while
[Send] leaves the page open, allowing the same message to be sent
independently, with or without modification.

A *very* useful 'Confirm Send [x]' checkbox can prevent premature mailing.

A [Save] button stores the message in a 'Draft Items' folder (named via
[Options]) and [Restore] will list the 'Draft Items' folder allowing a saved
message to be opened again.

External files of all types may be attached to the email; images, video, ZIP
archives, etc.  These are uploaded and stored on the soyMAIL system, linked
to the current message.  They are only attached when the message is actually
sent and by default are then deleted from the server.

To repeat, soyMAIL is fundamentally a plain text application but does provide
a WYSI(almost)WYG HTML editor.  When reading an HTML message a [Reply] will
bring up the HTML editor.  A [Compose] page may be switched to that editor by
using [Edit HTML].  Switching back and forth between [Edit plain] is *not*
recommended when the page has content.

A list of contacts can be managed and used for mailing addresses.

JavaScript (ECMAscript)
----------
yahMAIL and originally soyMAIL, eschewed JavaScript (in common with other
bah-humbug curmudgeon authors not used to client-side processing).

However early on soyMAIL implemented some functionality using JavaScript and
from 2014 made it an essential element.  That role is largely relegated to
GUI actions improving the efficiency and behaviours of soyMAIL.
soyMAIL itself remains significantly server based.

  Why not a pure JavaScript client?

  Good question.  Could be done (using a suitable MAIL$ back-end**).
  soyMAIL (and yahMAIL) always was a generic CGI program intended for all
  VMS web servers (which precludes the likes of WebSocket).  Same-origin
  constraints largely limit browser actions to the original server.

  soyMAIL was a lot of code; has become more-so; has tailored capabilities;
  an established look-and-feel; and I haven't gotten any younger or more
  enthusiastic over twenty years maintaining and improving soyMAIL.
  So it's care-and-maintenance with incremental changes.

  ** The soyMAIL CALLMAIL.C module contains the core MAIL$ interfaces.
     Go on.  Knock yourself out.

Documentation
-------------
https://wasd.vsm.com.au/wasd_root/src/soymail/doc/soymail_overview.html
https://wasd.vsm.com.au/wasd_root/src/soymail/doc/soymail_admin.html
https://wasd.vsm.com.au/wasd/#soyMAIL

References
~~~~~~~~~~
https://en.wikipedia.org/wiki/Skunkworks_project ꙳¹
https://docs.vmssoftware.com/vsi-openvms-utility-routines/#MAIL ꙳²
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol ꙳³
https://en.wikipedia.org/wiki/Post_Office_Protocol ꙳⁴
https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol ꙳⁴
https://en.wikipedia.org/wiki/ECMAScript
https://en.wikipedia.org/wiki/Spy_pixel ꙳⁵

PS. Needless-to-say, this article has been composed, sent
    and displayed (online) using soyMAIL v2.2.0  Woof!

    DECUServe provides soyMAIL as a facility.

This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional