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: . . (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" T recipientsmailid@recipientsmailhost.dom C ccrecipientsmailid@ccrecipientsmailhost.dom B bcrecipientsmailid@bcrecipientsmailhost.dom From: "Sender's Real Name" 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: RCPT TO: RCPT TO: RCPT TO: (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