                               PMSMTP v0.17b
                               =============
              PMSMTP.TXT - Copyright (c) 2021, Fred C. Macall
  

Overview and System Requirements

PMSMTP and PMSMTP32 are designed to replace PMPOP's mail sending function
in a DOS Packet Driver based Pegasus Mail (PMAIL) installation.

PMSMTP and PMSMTP32 complement PMPOP's capabilities by working with
SMTP Mail Transfer Agent servers that may offer or impose an AUTH LOGIN
authentication option or requirement.  PMPOP doesn't seem to support the
AUTH LOGIN SMTP extension.  Therefore, PMSMTP should make Pegasus Mail
useful with a group of SMTP servers that can't be accessed through PMPOP.

PMSMTP32 is an enhanced version of PMSMTP.  It includes OpenSSL support for
making secure (TLS/SSL) connections to SMTP servers that require those.
PMPOP doesn't seem to support those servers, either.  So, PMSMTP32 further
enlarges the group of useful SMTP servers that can't be accessed through
PMPOP.

As PMSMTP and PMSMTP32 only send mail, a counterpart such as PMPULLR,
PMPULL, or PMPOP also will be required in one's installation, for receiving
mail.

PMSMTP should run successfully on any IBM PC compatible machine that can
run DOS, Pegasus Mail, and PMPOP.  I used to run PMSMTP, with PMAIL v3.3,
on an 8088-based PC with DOS v3.3.  And, on a '486-based PC, with various
DOS versions.  (My ISP's "transition" to Gmail, for e-mail service, put a
stop to that.  Because, Gmail requires the secure connections that
necessitate the use of PMSMTP32.)

Like PMSMTP, PMSMTP32 runs on IBM PC compatible systems, in DOS.
However, it requires an 80386 or later processer, 4 MB of RAM, or more, and
a DOS Protected Mode Interface (DPMI) service.  The full PMSMT17F.ZIP
package includes CWSDPMI.EXE, which will provide the needed DPMI service in
the absence of any existing one.  I now run PMSMTP32 and Pegasus Mail, in
DOS, on a Pentium-based PC I've named George.

PMSMTP and PMSMTP32 version 0.17b are offered in two packages:
PMSMT17L.ZIP contains only PMSMTP.EXE and its supporting files.
This package is suggested only for users with older PCs that can't run
PMSMTP32.  PMSMT17F.ZIP contains everything that PMSMT17L.ZIP contains,
plus PMSMTP32.EXE and additional supporting files, for it.  This package
is suggested for all users with PCs that can run PMSMTP32.

(Throughout this document, PMPOP is used as shorthand to refer to
PDPMPOP.EXE, one of at least two versions of PMPOP.  PDPMPOP.EXE is the
version that is used in a DOS Packet Driver environment.
During installation, it gets renamed PMPOP.EXE .  Hence, my shorthand
usage.  In a similar fashion, I will tend to use PMSMTP as shorthand for
both it and PMSMTP32.  When I refer to PMSMTP32, that will be to
distinguish it from PMSMTP.)


More About SMTP AUTH LOGIN

SMTP AUTH LOGIN authentication is an SMTP extension that provides what
amounts to a mail client login for sending mail.  This is one means of
authentication used by SMTP servers, which are ever more choosey about
whose mail they'll relay.  ESMTP servers that support AUTH LOGIN
authentication advertise this in their response to the EHLO command.
A mail client receiving an AUTH LOGIN advertisement may then expect to
initiate a fruitful login exchange by issuing an AUTH LOGIN command.
In turn, the ESMTP server issues prompts for a base64-encoded user ID and a
base64-encoded password.  Assuming that the server is satisfied with the
user ID and password supplied, the SMTP session then proceeds in the
traditional ways.

Base64 encoding only slightly obscures the ID and password sent and won't
keep them secret.  However, for contacts with a dial-up ISP's SMTP server,
the facilities between the answering modem and the SMTP server might be
expected to be contained within the ISP's premises.  And, therefore, be
secure.

File SMTPAUTH.SES, included in both PMSMT17L.ZIP and PMSMT17F.ZIP, contains
a session trace log type representation of an SMTP AUTH LOGIN exchange.
(In this illustration, the lines carrying base64-encoded data include
comments that begin with "base64".  These comments decode the base64 data
content illustrated and do not constitute part of the actual exchange
data.)


More About Secure Connection Protocols

As suggested above, a problem with SMTP AUTH LOGIN authentication is that
performing it reveals the user's ID and password to anyone able to monitor
the user's session.  Open or public WiFi Access Points provide examples of
arrangements that may allow many listeners to monitor a WiFi user's SMTP
session.  A protocol for using SSL encryption to thwart SMTP session
monitoring was defined by Netscape, beginning in February 1995.
This definition calls for starting an SSL setup procedure as soon as a
TCP/IP session has been set up.  As part of this startup, the SMTP client
is expected to check or verify the SMTP server's security certificate.
In order to recognize and abort a "man in the middle" intrusion, into the
session.  PMSMTP32 does not perform this check.  With the Netscape
protocol, nothing related to the pending SMTP session gets exchanged
(in the clear) before that SSL startup.

The Netscape definition seems to have been successful.  However, as a
practical matter, it requires a designated or separate port on SMTP
servers, for secure sessions.  This has come to be port 465.

Beginning in January 1999, RFCs 2487 and 3207 defined a somewhat different
protocol for using TLS/SSL encryption to secure e-mail submission sessions.
This newer protocol aims to avoid any need for a designated or separate
port.  It does this by beginning a session with the 220 response and EHLO
command exchange, in the clear, which is traditional for SMTP.
However, in this protocol, the response to that EHLO command contains a
different "advertisement".  A STARTTLS command gets offered, perhaps among
other things, instead of an AUTH LOGIN command.  An SMTP client prepared to
use TLS/SSL encryption then sends the STARTTLS command to signal that it is
about to begin its startup for encryption.  Such an SMTP client is also
expected to check or verify the SMTP server's security certificate.
In order to recognize and abort a "man in the middle" intrusion, into the
session.  PMSMTP32 does not perform this check.  After another 220 response
from the server, the TLS/SSL setup commences.  This protocol might be
performed using the SMTP server's well known port 25.  However, port 587
seems to be popular for this, as well or instead.

Once a secure session has been set up, a Netscape protocol using server
sends a 220 response that corresponds to the beginning of a traditional
SMTP session.  Then, both the legacy Netscape and the STARTTLS protocols
continue with an EHLO command from the client.  (In the STARTTLS case, this
will be a second EHLO command.)  The response to this command is likely to
advertise an AUTH LOGIN command.  Of course, these things and everything
that follows, in the session, will be encrypted.

PMSMTP32 supports a new smtpsec= configuration option for determining
which, if any, of those two security protocols to use.  As PMSMTP
can't perform either of the two security protocols, it ignores any smtpsec=
configuration.

The STARTTLS negotiation described here and the AUTH LOGIN negotiation
described in the previous section differ in what gets done if the expected
advertisement doesn't appear.  If AUTH LOGIN isn't offered, it isn't
attempted.  However, the SMTP session continues without it, if the SMTP
server will allow that.  On the other hand, if smtpsec=STARTTLS is
configured but STARTTLS isn't offered, PMSMTP32 will indicate what happened
and QUIT the session.  Also, with either security protocol configured, if
TLS/SSL startup fails, the session ends.  So, configuring either of the two
security protocols insures that PMSMTP32 won't send one's AUTH LOGIN ID nor
password in the clear.


How They Work

Both PMSMTP.EXE and PMSMTP32.EXE start off by looking for their shared
configuration file, PMSMTP.CFG, in the directory from which they have been
loaded.  And, if necessary, in the "current DOS directory".  Much of the
configuration data is dedicated to the included WATTCP TCP/IP
communications package.  In particular, if PMSMTP version 0.17b finds
my_ip=BOOTP or my_ip=(E)DHCP specified in the configuration file, it then
attempts to obtain its TCP/IP configuration from a BOOTP or DHCP server.
With its configuration complete, PMSMTP checks its command line
argument(s).  If the first one is /? or if there are more than one, it
displays its Usage message and terminates.  For the record, this message
reads:

Usage:  PMSMTP [/?]
        PMSMTP [base64 password data for SMTP AUTH LOGIN]

If there is a lone command line argument that doesn't match /?, it is
taken, without any further verification, as a base64-encoded password for
SMTP AUTH LOGIN.  Such a command line supplied password replaces any
b64passw= value already obtained from the configuration file.

PMSMTP then searches the maildir= specified mail directory for .MSG
file(s).  These are PMAIL's mail messages waiting to be sent.  (These files
are different from the .MSG files produced by Outlook Express.)  If any are
found, it attempts to contact the smtphost= specified mail server.
By default, PMSMTP will attempt to contact the specified mail server via
its well known TCP/IP port 25.  This port number may be changed to, say,
587 by appending :587 to the smtphost= specified mail server's name, in
PMSMTP.CFG.

Once it has contacted the SMTP host, PMSMTP32 will try to start SSL, if
smtpsec=LegacySSL is configured.  Or, if smtpsec=STARTTLS is configured, it
will send an EHLO command and look for an advertisement for STARTTLS.
(More about these things was given in the previous section.)
Otherwise, or after a TLS/SSL session has been started successfully,
PMSMTP32 will work just as PMSMTP does:  They will send an EHLO or HELO
message or command.  If both a b64usrid= mail user ID configuration value
and a base64-encoded mail user password configuration or command line value
have been specified, they will send an EHLO command.  That requests an
Extended SMTP session.  Otherwise, they will send a HELO command,
requesting only a basic SMTP session.  The full EHLO or HELO command
includes an identifier consisting of:
<hostname= configuration value>.<domainslist= configuration value> .
(Without those corner characters.)  Upon receipt of a response accepting
its EHLO command, PMSMTP searches the response for an AUTH LOGIN
advertisement.  If it finds one, PMSMTP attempts an AUTH LOGIN exchange to
transfer its b64usrid= mail user ID configuration and base64-encoded mail
user password values.

PMSMTP reports some significant events on the display as it performs the
SMTP session set up described above.  It also indicates a successful SMTP
session set up outcome by displaying the line:

Ready.  (d)

Where d indicates the type of session set up achieved as follows:
        d  Type of Session Set Up
        =  ======================
        0  SMTP
        1  ESMTP
        3  ESMTP AUTH LOGIN

PMSMTP expects PMAIL to be configured to deliver .MSG mail message files
that look like:

$$ "Sender's Real Name" <sendersmailid@sendersmailhost.dom>
T recipientsmailid@recipientsmailhost.dom
C ccrecipientsmailid@ccrecipientsmailhost.dom
B bcrecipientsmailid@bcrecipientsmailhost.dom

From:  "Sender's Real Name" <sendersmailid@sendersmailhost.dom>
To:    recipientsmailid@recipientsmailhost.dom
Date: . . .

The part of the .MSG file ahead of the first blank line is known as the
message's envelope data.  The $$ line must come first and contain corner
characters bracketing the sender's mail address, as shown.  The rest of the
envelope data identifies each of the message's To, Cc, and Bc recipient(s).
With a separate line for each recipient.  The part of the .MSG file after
the first blank line is the message, itself.

Once PMSMTP has successfully set up an SMTP or ESMTP session, it proceeds
to read and send each .MSG mail file found in the maildir= specified mail
directory as follows:

First, it sends a MAIL FROM: command and one or more RCPT TO: commands
based on the message's envelope data.  Then it sends a DATA command and the
message, itself.  While sending a long message, PMSMTP presents a number on
the display for each 28 KB buffer of message data sent.  n, the most recent
number presented, multiplied by 28 KB indicates the approximate length of
the message transmitted to that point.  Finally, PMSMTP sends a line
containing only a period to the server, to indicate the end of the data.
For the message file example above, PMSMTP would generate the following
SMTP envelope commands:

MAIL FROM:<sendersmailid@sendersmailhost.dom>
RCPT TO:<recipientsmailid@recipientsmailhost.dom>
RCPT TO:<ccrecipientsmailid@ccrecipientsmailhost.dom>
RCPT TO:<bcrecipientsmailid@bcrecipientsmailhost.dom>

(PMSMTP assumes that each message's entire envelope data will fit in a
28 KB buffer.  With mail addresses averaging about 50 characters long, that
should allow for up to about 500 recipients for a single message.
I do not know whether PMAIL is even capable of generating a message with a
28 KB long envelope.  PMSMTP no longer requires PMAIL to keep the message
data from containing any line(s) that contain only a period.  Rather, it
doubles any period(s) found at the very beginning of a line.  In turn, the
SMTP mail server is expected to restore any doubled periods found, at the
beginning of a line, to a single period.)

For each SMTP command and the message data block that it sends, PMSMTP
expects the particular SMTP Reply Code that indicates success for that
operation, from the server.  (For RCPT TO: commands, PMSMTP expects either
Reply Code 250 or 251.)  While the expected Reply Codes are obtained, the
process continues.  After successfully sending each .MSG message file,
PMSMTP attempts to rename the file with a suffix of .MS$.  If the rename
call succeeds, PMSMTP proceeds to search for another .MSG mail file to
send, in a continuation of the already established SMTP session.

Once all of the .MSG file(s) have been renamed or an unexpected response
has been obtained, PMSMTP sends an SMTP QUIT command, reports to the
display on what it has accomplished, and terminates.


Installation and Configuration

I think there may be some fairly easy ways to arrange for running PMSMTP
from PMAIL's "Send all messages" menu entry.  However, I haven't felt a need
to bother with that.  So, these instructions lead you toward running PMSMTP
from outside of PMAIL.  Also, I am assuming that you have already installed
Pegasus Mail and PMPOP, PMPULL, or an equivalent.  If you need PMSMTP, your
ability to send mail without it may be little or none.  However, you should
already be fully able to receive your mail from your POP3 server via PMPOP,
PMPULL, or an equivalent.

1.  PKUNZIP PMSMT17L.ZIP or PMSMT17F.ZIP into an empty directory.

2.  Copy PMSMTP.EXE and/or PMSMTP32.EXE into the directory where you keep
    your other Pegasus Mail programs.  If you are upgrading an existing
    PMSMTP installation, your existing PMSMTP.CFG configuration file may
    serve without change.  However, if you want to start using PMSMTP32.EXE
    and secure connections, you'll need to add an smtpsec= . . .
    configuration specification to your configuration file.  If you are
    installing PMSMTP and/or PMSMTP32 for the first time, also copy the
    sample PMSMTP.CFG file provided into the directory where you keep your
    other Pegasus Mail programs.

3.  If necessary, adjust your Pegasus Mail User Gateway Definition, through
    the PMCONFIG program, to deliver the mail message file format described
    in the How They Work section, above.

    In particular, the entry for Filename format must end in:
    .MSG
    to give your mail message file names the .MSG extension.  The entry for
    Reply address format may be:
    "~p" <~n>
    In that case, the PMUSER environment variable setting or PMAIL sign on
    user name response must include one's whole e-mail address, to yield
    the $$ line expected.  Finally, the entry for Simple message headers
    must be:
    'Glue' headers
    to specify the mail message file format described above.
    These settings are part of the set of settings that PMPOP.TXT suggests
    for use with PMPOP.  UDG.TXT provides additional information about
    these things.

4.  If necessary, edit, or tailor, PMSMTP.CFG with an ASCII text editor
    that confines the non-text or format control information that it adds
    to nothing more than new line sequences.

    In a new PMSMTP or PMSMTP32 installation, you must tailor PMSMTP.CFG
    for your own case.  At the very least, that will mean supplying your
    own values for b64usrid=, hostname=, and domainslist=.  Unless your
    mail installation happens to be a lot like mine, you also will need to
    supply appropriate values for maildir= and smtphost=.  If you don't
    mind putting your base64-encoded password into the same file, you may
    want to specify b64passw=, too.  Otherwise, you'll state it on PMSMTP's
    command line when necessary.  Finally, if your installation doesn't
    support BOOTP for TCP/IP configuration, you'll also need to specify a
    value for my_ip= .  With PMSMTP version 0.17b, that might be my_ip=DHCP
    or my_ip=EDHCP.  Otherwise, if your installation doesn't support
    (E)DHCP for TCP/IP configuration, you also will need to specify
    netmask=, gateway=, and nameserver= .  PMSMTP.CFG contains lots of
    comments describing the values needed.

5.  If you are installing PMSMTP32, you will need to arrange a
    DOS Protected Mode Interface (DPMI) service for it, if you don't have
    one you are using already.  The PMSMT17F.ZIP package includes
    CWSDPMI.EXE, which works quite well for PMSMTP32.  If you want to use
    that one, all you need to do is copy it into the directory where you
    will be keeping PMSMTP32.EXE.  Or, you may copy CWSDPMI.EXE into any
    directory listed in your PATH environment value.  PMSMTP32 will find
    and load CWSDPMI.EXE, from any of those places, if and when it needs
    it.  The DPMIREVU.HTM document included in the PMSMT17F.ZIP package
    describes several (other) DPMI services that I've also used with
    DosLynx.  Any but Borland's DPMI16BI.OVL and Japeth's HDPMI16.EXE also
    should serve for PMSMTP32.  (DPMI16BI.OVL and HDPMI16.EXE won't do
    because they only support 16-bit Protected Mode software.
    Which PMSMTP32 isn't, of course.  If you like Japeth's software, use
    his HDPMI32.EXE.)

    If your PC lacks a "Numeric Processor Extension" (NPX) or float
    arithmetic hardware, also copy the EMU387.DXE file into the directory
    where you will be keeping PMSMTP32.EXE.  That will be needed when
    PMSMTP32 is establishing a secure connection.  If your system chokes at
    that point, you also may need to issue the following SET commands:

    SET 387=N
    SET EMU387=fullpathtoemu387.dxe

    Anytime before running PMSMTP32.EXE.  You may add those SET commands
    to your AUTOEXEC.BAT file.  Or, to your SENDMAIL.BAT file, which is
    described below.


Wrapping Your PMSMTP Command in a .BAT File

Specifying both b64usrid= and b64passw= in PMSMTP.CFG will prevent you from
running PMSMTP with SMTP AUTH LOGIN authentication disabled, if and when
that is appropriate.  Also, it leaves all your secret mail identity "eggs"
in a single basket.  To avoid these problems, you should leave b64passw=
out of your PMSMTP.CFG file and state your base64-encoded password on
PMSMTP's command line when necessary.

Another alternative is to wrap the PMSMTP command(s) you issue frequently
in one or more .BAT file(s).  Specifying your base64-encoded password on
the PMSMTP command line in such a .BAT file leaves it vulnerable to anyone
who can get physical access to your system.  But, that will allow you to
separate it, in various ways, from the rest of your mail installation's
configuration.  Making it harder for a snooper to find.

File SENDMAIL.BAT, included in both PMSMT17L.ZIP and PMSMT17F.ZIP, provides
an example showing how to invoke PMSMTP with a base64-encoded password on
the command line.  In that example, the PMSMTP command line is included in
a SCRIPT command.  SCRIPT is available at:
ftp://ftp.simtel.net/pub/simtelnet/msdos/screen/script11.zip .
It runs the PMSMTP command and appends its output to a log file at the same
time as it is presented to the display!  I've now changed SCRIPT to
@SCRIPT, in the example, to keep the PMSMTP command, with its secret, from
being displayed when SENDMAIL runs.  If you want to use SENDMAIL.BAT but
don't want a log file or don't have SCRIPT, simply delete everything before
PMSMTP from the @SCRIPT command's line.  Either way, you'll also need to
change that base64-encoded password to your own, of course.  And, change
PMSMTP to PMSMTP32 if you want that one run.

If you don't want copies of your mail saved in .MS$ files, you can add a
DEL *.MS$
command to your own SENDMAIL.BAT file.

By now, you may be wondering how to base64-encode your mail ID and
password.


Base64-Encoding

PMAIL v3.3, at least (I am not experienced with earlier versions), contains
base64-encoding code within its MIME support.  MIME-encoding is simply
base64-encoding with extra rules about line lengths and formats.
So, you can use Pegasus Mail's MIME support to base64-encode your mail user
ID and password.

You simply enter each of those items into a separate file and mail them as
MIME attachments to a note to yourself.  You may view the resulting .MSG
file with a text editor.  Or, use Pegasus Mail's
"Display the message anyway" menu entry, on the received note's Binary data
Sections, to view the MIME-encoded files.  The data you want will be at the
end of the displayed message.  The encoded data will consist entirely of
displayable text characters.  (That's the whole purpose of MIME encoding.)
An ID or password value n characters long will be encoded into exactly
4 * INT((n + 2)/3) characters.

To enter your mail user ID into a file named, say, USERID, command:
COPY CON USERID
at your DOS system's CONsole.  Then, type your mail user ID and end with
Ctrl-Z and Enter.  (For Ctrl-Z, hold a Ctrl key down while typing the Z
key.)  Use the TYPE and DIR commands to verify that your ID is right and
that there is nothing extra (like a new line sequence) in the file.
(For a seven character ID, DIR should report USERID's size as exactly 7.)
Don't neglect the case or shift of your ID's letter(s).  If you notice a
mistake while typing your ID, simply end with Ctrl-Z and Enter.  Then,
DEL USERID
and start over.  Use the same technique to enter your mail password into
another file named PASSWD.

With your USERID and PASSWD files ready, command PMAIL and take its
"Send a mail message" and "Compose a new message" menu entries.  Then, use
F9 - More options, to verify that MIME features? is set to Y(es).
Next, start a message to yourself and use F7 - File attachments.  For each
file to be encoded (USERID and PASSWD), use the Ins key to start an
attachment entry and enter the file's name.  For File type, use Binary.
For Encoding, use Basic MIME.  To finish, commit your attachments and
complete and commit your message.  You will be able to read your
base64-encoded data from the resulting message as explained above.

In the interest of security, remember to delete all files containing
un-encoded or even encoded versions of your password, including mail and
mail log files, developed in the course of this exercise.


History

I make both DosLynx and PMSMTP using a single WATTCP TCP/IP software
library.  As a result, many of the changes made in PMSMTP, between
versions 0.14b and 0.17b, stem from improvements made in that library.
These improvements have been described in some of the history.txt documents
accompanying my more recent DosLynx releases.  If you want to know all the
gory details, search for WATTCP and/or TCP/IP, in those documents.
The most recent of these is the history.txt document for DosLynx v0.44b.
Presently, it may be found at:
http://macall.net/history.txt .
In its introduction, that history.txt document tells where all of my
previous DosLynx history.txt documents may be found.  Review the
history.txt documents going back to DosLynx v0.34b to be aware of all the
developments since PMSMTP v0.14b was made.

PMSMTP32 made its first appearance in the version 0.15b release.
It follows from the DosLynx 32-bit Protected Mode version, DosLynxS.
That one's initial release came in version 0.36b.  So, the last six
DosLynx history.txt documents provide most of the background information
available for PMSMTP32.

Need for PMSMTP version 0.16b resulted from limitations in version 0.15b's
provisions for recognizing an AUTH LOGIN advertisement in the SMTP server's
possibly multi-line response to the EHLO command.  In particular,
250 AUTH PLAIN LOGIN
wasn't being recognized as equivalent (for PMSMTP's purposes) to
250 AUTH LOGIN

PMSMTP32 version 0.16b also includes improvements in its provisions for
recognizing a STARTTLS advertisement in the SMTP server's possibly
multi-line response to the (session's first) EHLO command.

You may notice that PMSMTP and PMSMTP32 v0.16b both provide more thorough
reporting of what they receive in response to their EHLO command(s).

PMSMTP32 version 0.17b is made with an OpenSSL v1.0.2u library.
This should insure its ability to negotiate secure connections with
servers which now tend to shun PMSMTP32 v0.16b's best efforts.
Also, it increases the size of PMSMTP32 by almost 50 percent.

The PMSMT17F package also includes an updated CWSDPMI executable and
documentation which support ever larger systems.  Both the PMSMT17L and
PMSMT17F packages include a PMSMTP version updated to identify itself as
version 0.17b.


Credits and Copyright Notices

PMSMTP.EXE v0.17b and the libraries, materials, and tools used to make it
contain the following Copyright notices:

  PMSMTP.EXE - Copyright (c) 2021, Fred C. Macall

  Copyright (c) 1994, University of Kansas, All Rights Reserved

 Written by and COPYRIGHT (c)1993 to Quentin Smart

Copyright (c) 1990, 1991, 1992, 1993 Erick Engelke

Borland C++ - Copyright 1991 Borland Intl.

  Copyright (C) 1990 by Marty Del Vecchio

LZEXE.EXE  Version 0.91   (c) 1989 Fabrice BELLARD

PMSMTP32.EXE has been implemented through use of DJGPP v2.05 resources and
tools, in DOS!  These include an elegant 2 KB "stub loader", the
GNU GCC v8.3.0 compiler, and the UPX v3.02 eXecutable Packer.
I have supplemented these with the Borland C/C++ resources and tools,
acknowledged above, and the MASM v6.11d assembler.

The 32-bit version's source comes from the same sources used for making
PMSMTP.EXE.  All of these have been dragged into compliance with the
GCC v8.3.0 compiler's and MASM v6.11d assembler's requirements.
So, about 99 percent of the PMSMTP source is shared in common among both
variations or versions.

I expect that you may obtain all the DJ Delorie resources and tools
including UPX v3.02, as I did, from:
http://www.delorie.com/djgpp/ .

PMSMTP32.EXE's TLS/SSL support has been implemented by linking PMSMTP with
an OpenSSL v1.0.2u installation or library included in DJGPP's collection
of resources.  OpenSSL is available from:
http://www.openssl.org/ .

The detailed PMSMTP32/OpenSSL linkage has been adapted from one of
Mark Mentovai's lynx-ssl patches.  Those used to be available from:
http://www.moxienet.com/lynx/ .

Now, they seem to be gone from there.  However, they may still be found
in mirror site(s) such as:
http://mirror.optus.net/sourceforge/m/ma/math-linux/lynx-282-ssl.patch .

The DJGPP, GNU, Microsoft, UPX, and OpenSSL resources and tools carry far
too many copyright notices to thoroughly list them here.  What appear to be
the key or principal copyright notices for these and for PMSMTP32, itself,
read as follows:

 PMSMTP32.EXE - Copyright (c) 2021, Fred C. Macall

The STUB.EXE stub loader is Copyright (C) 1993-1995 DJ Delorie.
Permission granted to use for any purpose provided this copyright
remains present and unmodified.
This only applies to the stub, and not necessarily the whole program.

          GNU LIBRARY GENERAL PUBLIC LICENSE
              Version 3, 29 June 2007

 Copyright (C) 2007 Free Software Foundation, Inc. (http://fsf.org)
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

 gcc.exe (GCC) 8.3.0
 Copyright (C) 2018 Free Software Foundation, Inc.

Microsoft (R) Macro Assembler Version 6.11d
Copyright (C) Microsoft Corp 1981-1995.  All rights reserved.

 This file is packed with the UPX executable packer http://upx.sf.net
 UPX 3.02 Copyright (C) 1996-2007 the UPX Team. All Rights Reserved.

 Copyright (C) 1995-1998 Eric A. Young, Tim J. Hudson
 (eay@cryptsoft.com)
 This product includes cryptographic software written by Eric Young
 (eay@cryptsoft.com).

 Copyright (c) 1998-2019 The OpenSSL Project.  All rights reserved.
 This product includes software developed by the OpenSSL Project
 for use in the OpenSSL Toolkit  (http://www.openssl.org/)

Neither PMSMTP.EXE v0.17b, PMSMTP32.EXE v0.17b, nor any of the rest of the
contents of the PMSMT17L.ZIP and PMSMT17F.ZIP packages may be copied, except
by individuals for their own personal evaluation or use in an e-mail
installation based on Pegasus Mail.  Permission for copying for any other
purpose(s) must be arranged in advance with the package's author,
Fred C. Macall.


Disclaimer

This software is published in the hope that it will be useful, but without
any warranty;  Without even the implied warranty of merchantability or
fitness for a particular purpose.


Fred C. Macall
1019 Pennfield Road
Cleveland Heights, Ohio, 44121, U.S.A.
(216) 382-3415
(For e-mail contact, please display FCMEMADR.GIF .)

22 October 2021
