(NOTE:  This is a text version of the Connect2SMTP documentation.
A version of the documentation in Word for Windows format is also
available.  To retrieve, send a message to Library@Infinite.ihub.com
with a subject of C2SDOC.)


Connect2SMTP Introduction
=========================

Connect2SMTP provides a completely integrated solution for
connecting MHS-based electronic mail directly and seamlessly 
with SMTP-based electronic mail.

Connect2SMTP runs as a single, uninterrupted program on a 
dedicated PC.  It doesn't use complex batch files or other 
programs to get the job done.  

Connect2SMTP doesn't need any routing tables, user name 
tables, or alias tables when minimally configured.  And 
monitoring tools provide all of the information you need to tell 
what's happening in real time.

Connect2SMTP is a completely integrated solution, containing 
its own caching queue system, its own 386 memory manager, 
its own protected mode dos-extender, and it contains its own 
high-performance Mach2 TCP/IP protocol stack that runs 
directly on Novell ODI drivers or Clarkson Packet Drivers, and 
it also contains its own drivers for the asynchronous SLIP or 
PPP dial-up protocols.

Connect2SMTP is capable of supporting as many as 100 SMTP 
mail sessions simultaneously, and it provides the fastest 
throughput of any PC-based SMTP product.  Connect2SMTP is 
the most powerful, yet flexible, MHS to SMTP gateway 
available today.

Connect2SMTP natively supports NetWare environments, but 
may also be used with full capabilities on other network 
platforms such as Lantastic, Lan Manager, and others.

  

Connect2SMTP Features
======================
Connect2SMTP:

- Automatically handles inbound and outbound file 
attachments in both uuencode and MIME formats
 
- Provides extensive support for both inbound and 
outbound MIME formatted messages.  Including; full 
decoding and encoding of all MIME encoding 
methods (i.e. BASE64, Quoted-Printable, 7BIT, 8BIT 
and Binary).  Automatically decodes to separate file 
attachments.
 
- Supports a variety of return receipt options
 
- Returns delivery errors in both directions with 
optional copies to the MHS administrator
 
- Has separate log file options for errors, inbound, and 
outbound message traffic
 
- Complies with RFC-821, 822, 1055, 1332, 1334, 
1521, 1661, and 1662
 
- Requires minimal administration.  Address 
conversion does not use alias or look-up tables 
making addressing from both sides simple
 
- Supports MHS 1.1 through 2.0 (SMF-64, SMF-70, 
and SMF-71)
 
- Can handle up to 100 inbound or outbound SMTP 
sessions concurrently
 
- Includes extensive debug tools, such as PING, 
NSLookup (name serverlookup), Telnet/25 (telnet to 
another SMTP host) for troubleshooting
 
- Provides separately configurable scroll back buffers 
for each loaded module (i.e. MHS, SMTP, etc.), 
allowing easy access to their current and previous 
activity at any time
 
- Includes the high-performance Mach2 TCP/IP 
protocol stack that runs directly with Novell ODI 
drivers, or Clarkson Packet Drivers
 
- May also function as a high-performance TCP/IP 
router between an Internet Service Provider and a 
local network, and provides other TCP/IP services 
such as responding to name server queries from local 
nodes
 
- Can be configured to pass all outbound mail to a 
nearby UNIX host or it can extensively use DNS to 
directly connect to any host for which it has outbound 
mail
 
- Provides multi-line asynchronous support for dial-in 
and/or dial-out, SLIPSLIP" or PPP PPP" connections.  
Provides a scripting language  scripting language" for 
interactive dial-out SLIP logins.  And, allows any 
number of configured users to dial in directly with 
SLIP or PPP for remote TCP/IP access to the 
network. 

Note:  Base license supports two asynchronous 
connections.  Licenses to support additional connections 
are available from Infinite Technologies.



Pre-Installation
================
Before you begin installing Connect2SMTP, you should review 
the following minimum system requirements and host 
configuration information.

System Requirements

Hardware
========
IBM PC XT/AT Compatible
640 KB Conventional Memory*
Network Interface Card
Modem (if connecting via a service provider)

Software
========
Novell NetWare ODI driver or Clarkson Packet Driver 
for each Network Interface Card

MHS
===
Connect2SMTP works with Infinite Technologies 
Connect2, or NetWare MHS versions 1.1, 1.5, and 2.0 
(SMF-64, SMF-70, and SMF-71), and automatically 
adjusts to the differences and capabilities of each level .

Memory
======
Performance may be enhanced by using extended or 
expanded memory, and optionally running natively in 
protected mode.  See the section entitled "Memory 
Utilization" in the Technical Reference for more 
information.



Types of Connectivity
=====================
In general, there are two ways to connect to the Internet:

For small installations, or for companies with many 
geographically dispersed installations, obtaining a dial-
up SLIP or PPP account from a local service provider  
is a cost effective means to acquire direct  access to the 
Internet.

Larger locations may have a functional TCP/IP 
network capability already in place with the Internet, 
and/or with other organizational subnets, through the 
use of one or more existing TCP/IP routers, and all 
you need to do is attach Connect2SMTP to the existing 
TCP/IP network.

Regardless of which one describes your situation, before you 
can install and configure Connect2SMTP, you will need:

To decide what your MHS Gateway Name will be - 
(MHS e-mail users may have to use this name when 
they send mail through Connect2SMTP to an SMTP 
user).  If your MHS e-mail application doesn't have an 
easy-to-use template feature, or if your MHS transport 
does not support Internet address mapping, your MHS 
users may have to type the gateway name often, so 
consider keeping it short. 

A TCP/IP Host Name (from your local domain 
administrator or service provider) - Remote SMTP 
users will use this name when they send mail to your 
MHS users through Connect2SMTP. 

A dedicated IP Address (from your local domain 
administrator or service provider) for Connect2SMTP's 
computer - An IP Address is a number comprised of 4 
digits separated with dots (sometimes called "dotted 
notation"), that is the unique identifier on the Internet 
for your SMTP Gateway. 


Pre-installation Considerations for Each 
Method of Connection.


Connectivity via Asynchronous Dial-Up
To use Connect2SMTP for Internet access via a telephone 
connection, you should contact a local service provider to obtain 
a dial-in SLIP or PPP account.  Internet Service Providers can 
typically assign an IP Address to your site, and can assist with 
selecting your domain name, and they will usually handle the 
details of getting your domain name registered.  You should try 
to negotiate a domain name that is representative of your 
company name and/or location.

In addition, you will need a dedicated, or leased, phone line for 
Connect2SMTP to use when connecting to your service 
provider.  

Note that since Connect2SMTP can provide direct support for 
SLIP and PPP connections to a Service Provider, there is 
normally no need to purchase separate router hardware (i.e. 
don't let the service provider tell you that you have to buy 
"their" router).

Domain Name Services 
The Domain Name Service (DNS), is a protocol that provides a  
mechanism for translating a host name into an IP Address, and 
for resolving which mail hosts are alternate delivery points for 
mail destined to any particular host.

To receive mail from the Internet, Connect2SMTP's TCP/IP 
host name must be registered with the authoritative name server 
for your domain. This allows users on the Internet to send mail 
to your MHS users via Connect2SMTP by specifying 
Connect2SMTP's TCP/IP host name in the address.

Some organizations (normally with a large installed base of 
TCP/IP hosts) setup and maintain the authoritative name server 
for their domain, while smaller sites may find it preferable to let 
their service provider do this for them.

If your organization already has a domain name server, you will 
need to coordinate with its administrator to have the host name 
for Connect2SMTP registered.

Note that it is also possible for Connect2SMTP to act as a 
domain name server for your domain.  This is done with an 
optional add-on product, the Mach2 Domain Name server 
module, also from Infinite Technologies.

If you are not already running a domain name server for your 
domain, and plan to setup other TCP/IP services such as FTP, 
World Wide Web, etc., you may wish to investigate this option.

Configuration Decisions
One of the most important configuration decisions in setting up 
Connect2SMTP is defining the address mapping between the 
MHS and SMTP environments.  

Connect2SMTP supports several different mapping algorithms 
to translate an MHS "user@workgroup" address into a valid 
SMTP/Internet address.

For the following examples, we will assume that 
Connect2SMTP has been configured to use an internet domain 
name of "mydomain.com".

Single Workgroup Configuration
If your MHS configuration consists of a single MHS 
workgroup, then you will probably want to keep your SMTP 
addresses as simple as possible, such that an MHS address of:

user@workgroup

translates to an SMTP address of:

user@mydomain.com

This type of address conversion is configured by setting 
ExcludeHubName=Yes in the [MHS] section of C2SMTP.INI.

Please note that this setting should be used only if all users of 
the C2SMTP gateway are part of the same MHS workgroup.

Multiple Workgroup Configuration
If users from multiple MHS workgroups will be using the 
Connect2SMTP gateway, then it will be necessary for C2SMTP 
to include both the MHS user and workgroup names in the 
SMTP address.

The "InverseHubSyntax" setting is the preferred address  
mapping technique for a multiple workgroup configuration.  If 
InverseHubSyntax=Yes in the [MHS] section of C2SMTP.INI, 
then an MHS address of:

user@workgroup

would translate to an SMTP address of:

user@workgroup.mydomain.com

If you decide to use InverseHubSyntax, all MHS workgroups 
that will receive SMTP mail must be registered as individual 
hosts with your domain's name server, or a "wildcard" MX 
record must be configured within your domain's name server to 
direct mail for any host under your domain to the 
Connect2SMTP host.

The alternative to InverseHubSyntax in a multi-workgroup 
MHS environment is to include the MHS workgroup name to 
the right of the "@" symbol, together with the user name.

The HubDelimiter setting in the [MHS] section of C2SMTP.INI 
determines which character will be used to separate the MHS 
user and workgroup names.  Valid HubDelimiter settings are 
"%" or ".".

Therefore, an MHS address of:

user@workgroup 

would translate to either:

user%workgroup@mydomain.com
or:
user.workgroup@mydomain.com


Including or Excluding the TCP/IP Host Name

Unless InverseHubSyntax is active, C2SMTP defaults to 
including the configured TCP/IP host name when building 
SMTP addresses.

Assuming that the TCP/IP host name of your C2SMTP host is 
C2SMTP, yielding a fully qualified host name of 
C2SMTP.mydomain.com, by default C2SMTP will use the 
combination of the TCP/IP host name and domain when 
building SMTP addresses.

Therefore, in a single user workgroup configuration with the 
ExcludeHubName setting active, an MHS address of: 

user@workgroup

would translate to:

user@C2SMTP.mydomain.com

To exclude the TCP/IP host name from the address, it is 
necessary to set ExcludeHostName=Yes in the [MHS] section 
of the C2SMTP.INI file.



Installation & Configuration
============================

This section guides you through installing the product, 
configuring MHS for Connect2SMTP, configuring 
Connect2SMTP, and initially testing communications.

Upgrading from a Previous Version
If you are currently using a previous version of Connect2SMTP, 
which uses a configuration file named C2SMTP.CFG, you will 
need to convert it to a file called C2SMTP.INI.

An automated converter, CONV2INI.EXE, is included to help 
make the transition as easy as possible.  Almost all of the 
previous field names have changed, and the C2SMTP.INI file is 
now formatted using a [section] name structure similar to that 
used in Microsoft Windows.  CONV2INI.EXE automatically 
converts the C2SMTP.CFG file into the new C2SMTP.INI file 
format.

A detailed description of C2SMTP.INI file parameters and 
settings can be found later in this manual.

Installation
Before starting the installation, you will need to know 
Connect2SMTP's TCP/IP host name, IP Address, and MHS 
gateway name.

The steps to install Connect2SMTP are:

1. Copy the Connect2SMTP files.
2. Add a gateway name under MHS.
3. Edit Connect2SMTP's configuration file C2SMTP.INI.
4. Use the REGISTER.EXE program to apply any serial 
   numbers you have purchased, or to start your evaluation 
   period.
5. Modify the NET.CFG file.

Copying the Connect2SMTP Files
There are two ways to install Connect2SMTP.  You can install it 
on the local hard drive of the PC that will run it, or you can 
install it on a network drive.

If you install the Connect2SMTP files on the local hard drive, a 
command line parameter is available that can log a user into 
NetWare, so the computer does not need to be logged in before 
starting Connect2SMTP.

If you install the Connect2SMTP files on a network drive, you'll 
have to write a login script or batch file to login to the file 
server and map drives before you run Connect2SMTP.  (An 
example for each option is provided in the section entitled 
"Starting Connect2SMTP".)  MHS e-mail users do not need any 
disk privileges to Connect2SMTP's directory.

Once you've decided where you'd like to install Connect2SMTP, 
make a directory and copy all of its files there.  For example, if 
you choose to install the gateway on a file server, and the drive 
where Connect2SMTP will reside is drive G:, then:

G:\> MD \SMTP
G:\> CD \SMTP
G:\SMTP> XCOPY A:*.*

Adding a Gateway Name under MHS
This installation procedure assumes you are installing 
Connect2SMTP with NetWare MHS 1.5 or prior.  For 
instructions on installing Connect2SMTP with NetWare Global 
MHS, see the section entitled "Native SMTP Syntax" in the 
Technical Reference.  For instructions on installing 
Connect2SMTP with Connect2, see the section entitled "Adding 
a Gateway Name under Connect2" immediately following this 
section.

Adding the MHS gateway that Connect2SMTP uses is done 
from within the MHS program.  When MHS adds a new 
gateway, it automatically builds a directory structure for the 
gateway under its mv\MHS\MAIL\GATES subdirectory.

1. Start MHS and press the <Esc> key within the first 
   few moments.  Instead of running the Connectivity 
   Manager, you will be prompted to log in.
2. Log in with the MHS administrator's password. 
3. Select "Directory Manager" (under MHS 1.5 it is 
   called "Manage Directories").
4. From the Directory Manager menu, select "Routes to 
   Workgroups, Hosts, and Gateways".
5. Select "Add entry", then choose "Define a gateway".
   The following is a list of recommended settings for using 
   Connect2SMTP with MHS:

Host Name:   SMTP

Description: Connect2SMTP

Gateway Version: Enter your level of MHS: 64, 70, or 71

Gateway Commands: blank


Adding a Gateway Name under Connect2
You may either run the C2SETUP.EXE or select "System 
Configuration" from the Connect2 console menu.

1. Log in with the Connect2 administrator's password, if 
   one is installed. 
2. Select "Maintain Hosts and Gateways ".
3. Press <Insert> and enter the following suggested 
   information: 

   Host Name: SMTP

   Description: Connect2-SMTP

Gateway Version: 70

Gateway Commands: blank


The appropriate directory structure for the gateway under 
Connect2 will be built in the mv\MHS\MAIL\GATES 
subdirectory.

Configuring Connect2SMTP
Once you have setup Connect2SMTP's gateway entry in MHS, 
GMHS, or Connect2, you are ready to begin its configuration.

A sample C2SMTP.INI configuration file is included with 
Connect2SMTP and is fully commented.  If you need more 
details on any of the options, refer to the section entitled 
"C2SMTP.INI Configuration Settings" which provides a 
complete description of each option.

C2SMTP.INI is an ASCII text file and may be edited with any 
standard text editor, like EDIT.COM or EDLIN.COM.

Using REGISTER.EXE
After you've created the gateway name under MHS and edited 
Connect2SMTP's configuration file (C2SMTP.INI), you're ready 
to use the REGISTER program.

The REGISTER program is primarily used to enter product 
serial numbers, or to start an evaluation period.  It can also be 
used to assign proper NetWare directory rights to the login 
name that Connect2SMTP will run under.

For NetWare installations, the REGISTER program requires the 
current login to be a Supervisor (equivalent).

  
Serializing Connect2SMTP
If you are installing a purchased copy of Connect2SMTP, insert 
the distribution diskette in Drive A (or Drive B and make the 
appropriate change to the prompt), and then press <Enter>.

If you are installing a 30 day trial version, change the drive 
prompt to use the current directory by replacing "A:\" with a 
single period (".").

The Register program next scans the directory entered for .LIC 
files and displays a prompt.

Select the Connect2SMTP option and press <Enter>.   

If you are installing a 30 day trial version, leave 
"EVALUATION" in the Serial Number field and advance to the 
Company Name field.  If you are installing a purchased license, 
the serial number will be filled in automatically and you can 
advance to the Company Name.  After entering an appropriate 
value for your company name, the Register program will 
attempt to serialize your installation.

Entering Additional Host Licenses
If you purchased additional licenses (i.e. an Additional MHS 
Host License or an Unlimited MHS Host License), return to the 
Main Menu and repeat the preceding sequence for each separate 
product diskette.

Granting Directory Rights to Connect2SMTP
If you are using Connect2SMTP on a NetWare LAN, the 
REGISTER program can be used to grant appropriate MHS 
directory rights to the user that will be logged in when you run 
Connect2SMTP.

Before you can use REGISTER to do this, the user name must 
already exist.  If the NetWare user hasn't been created yet, exit 
REGISTER and use the appropriate NetWare utility to create 
the user and then re-run REGISTER.

From the Main Menu, select "Grant MHS Directory Rights". 

Use the cursor keys, mouse, or press the "C" key until C2SMTP 
is highlighted, then press <Enter>.  (Assuming C2SMTP is the 
login name that will be used, if not, select the appropriate user 
name displayed.)  To ensure proper privileges in the MHS 
directory structure, the user name selected is granted 
[SRWCEMF] trusteeship to the mv/MHS\MAIL directory 
structure.

Limiting Workgroups that can Use Connect2SMTP
If you have a Connect2SMTP license for more than one host, 
but fewer than unlimited, you must tell Connect2SMTP which 
MHS workgroups (hosts in the licensing terminology) should be 
allowed to use the Connect2SMTP gateway.

Note that if you have an unlimited host license, this procedure 
can still be used to limit which workgroups may use your 
gateway.

To specify which workgroups can use the Connect2SMTP 
gateway, Connect2SMTP looks for a HUBLIC.DAT file in its 
home directory.  This is an ASCII file that allows one 
workgroup name per line.

For example, if the workgroups ACME and ACME2 should be 
allowed to use your Connect2SMTP gateway, the contents of the 
HUBLIC.DAT file should be:

ACME
ACME2

Note:  the number of workgroups listed in the HUBLIC.DAT 
file cannot exceed the number of hosts licensed for your copy of 
Connect2SMTP.

Modifying NET.CFG
The Mach2 TCP/IP protocol stack included with Connect2SMTP 
directly supports both Novell ODI drivers and Clarkson Packet 
Drivers.

If you are using an ODI driver, you will probably need to make 
a small modification to the NET.CFG file to add the appropriate 
TCP/IP frame type to the board (network card) you want Mach2  
to use.

ETHERNET_II is the frame type most commonly used for 
TCP/IP on Ethernet LAN's.  Other LAN topologies, such as 
Token-Ring or FDDI, may require a different frame type.  Here 
is a list of some popular ODI TCP/IP Frame Types:

Network Type
TCP/IP Frame Type

Ethernet
ETHERNET_II

TOKEN-RING
TOKEN-RING_SNAP

FDDI
FDDI_SNAP


Here is an example NET.CFG after the ETHERNET_II Frame 
Type has been added:

Link Driver NE2000
	PORT 300
	INT 5
	MEM D000
	FRAME ETHERNET_802.3
	FRAME ETHERNET_II

If changes to NET.CFG are necessary, you will need to reboot 
the computer before using Connect2SMTP.

If you will be using Connect2SMTP to make a SLIP or PPP 
connection to your service provider, then please refer to the 
section "Asynchronous SLIP and PPP Driver support" for 
information on configuring that interface.

Initial Testing & Troubleshooting
The first thing you will usually want to do after setting up a new 
TCP/IP host is make sure it can communicate with another 
TCP/IP host.  This may be done after starting Connect2SMTP 
by using the Ping and NSLookup options from the SMTP 
Console.

Starting Connect2SMTP

To start Connect2SMTP:

* the current drive and directory must contain C2SMTP.EXE, 
  or the drive and directory it resides in must be in the DOS 
  PATH.

* either a user with the proper directory privileges must 
  already be logged in to the file server or Connect2SMTP 
  must be configured to perform the login by providing a user 
  name on Connect2SMTP's command line

Normally you would want the AUTOEXEC.BAT file to run 
Connect2SMTP every time the computer is started, which might 
look something like this if Connect2SMTP was installed on the 
local hard disk:

@ECHO OFF
PATH C:\DOS
PROMPT $P$G
CD \NWCLIENT
  LSL
  NE2000
  IPXODI
  NETX
CD \C2SMTP
  C2SMTP [C2SMTP[,password]]

If you installed Connect2SMTP on a network drive rather than 
the local hard disk, the AUTOEXEC.BAT file will also have to 
login to the file server, and map a drive to the right server 
volume before Connect2SMTP is run.  For example:

@ECHO OFF
PATH C:\DOS
PROMPT $P$G
CD \NWCLIENT
  LSL
  NE2000
  IPXODI
  NETX
CD \NETUTILS
  ATTACH fs/C2SMTP
  MAP F:=fs/VOL1:C2SMTP
  F:
  C2SMTP

This example assumes:

You've copied the ATTACH.EXE and MAP.EXE files 
from SYS:PUBLIC to C:\NETUTILS on the computer 
that will run Connect2SMTP.

A user name (without a password) called C2SMTP 
exists in the bindery and has been granted directory 
privileges to the MHS directory structure (with 
Connect2SMTP's REGISTER program).

Connect2SMTP's overlays and configuration files are 
installed in a subdirectory on VOL1: called 
"C2SMTP".

Command Line Switches and Syntax
Connect2SMTP has the following command line syntax:

C2SMTP [login_name[,password]] [switches]

Whether you need to specify a login name on the command line 
depends on where you installed Connect2SMTP's files, as 
discussed in the section entitled "Copying Connect2SMTP's 
Files".

The command line switches below are generally used to control 
a cosmetic or temporary behavioral component of the program, 
while C2SMTP.INI, (documented later in this manual) controls 
the handling of mail:

-B
This switch causes Connect2SMTP to intercept NetWare 
console broadcast messages (station messages are 
discarded) and display them on the MHS monitor (and 
also written in the error log file, if defined).  With or 
without the -B switch Connect2SMTP always intercepts 
broadcast messages ( -B just causes them to display), so 
there's no need to CASTOFF before running 
Connect2SMTP regardless of whether you use -B.


-E
This switch causes error messages generated by modules 
other than the MHS module (i.e. SMTP and M2TCP) to 
also display on the MHS console (and also written in the 
error log file, if defined)


-I
When this switch is used, each ICMP message received is 
displayed in the SMTP Monitor.  Without it, received 
ICMP messages are suppressed (with the exception of an 
ICMP echo reply from a PING request).  This switch is 
provided primarily for debugging purposes.  The screen 
output, with it enabled, can get confusing and also use up 
the scroll back buffer.


-N
This switch causes DNS (domain name server) lookups 
(along with queries received from local nodes) to be 
more verbose in the SMTP Monitor.  This is primarily 
meant for debugging purposes.  The screen output, with it 
enabled, can use up the scroll back buffer very rapidly.


-L
Tells Connect2SMTP to use Logical File Locking as its 
means for file access arbitration.  Without the -L switch 
Connect2SMTP will use sharing mode open calls, which 
should be more compatible and less likely to cause a 
conflict.  But, if you have trouble involving queue files, 
try using the -L switch.


-P
Starts Connect2SMTP in protected mode if a compatible 
VCPI memory manager is loaded.  Operation in protected 
mode can be sensitive to the 386 memory manager 
loaded, and a number of other boot configuration issues.  
For more information refer to the section entitled 
"Protected Mode" in the Technical Reference.


-T
Enables verbose tracing of all serial activity within 
Mach2.  (The same serial tracing can also be enabled or 
disabled on-the-fly from within M2TCP's <D>ebug 
menu.)  Using the serial trace can be very helpful when 
trying to setup a dial-out (SLIP) script for the first time, 
or for troubleshooting inbound serial connections.


-Vnn
Overrides automatic detection of the MHS version 
number.  For instance, if you are running MHS 2.0 
(SMF-71) but you want Connect2SMTP to behave as if it 
were MHS 1.5 (SMF-70), use a -V70  command line 
switch.  It is not recommended that you tell 
Connect2SMTP to use a higher version of MHS than is 
actually installed.  Valid switch options are -V64, -V70, 
and -V71.

This switch is provided for temporary usage.  A 
permament SMF version override can be set using the 
SMFVersion=  option in C2SMTP.INI



Initial Testing
Note: Testing Connect2SMTP may require the assistance of your in-house 
Unix DNS administrator or a technical representative from your 
service provider.

Once Connect2SMTP has been started, a utility called "Ping", 
which is provided by the SMTP module, may be used to do 
preliminary TCP/IP testing.  Press <Alt-S>, or <Tab> several 
times to rotate from the MHS console to the SMTP console.

Complete the following steps to test if the Mach2 TCP/IP 
protocol stack is functioning properly:

1. Find out the IP address of another local TCP/IP host 
   and try pinging it.  Do not use its host name.

   If this fails to work, check the netmask used with the 
   bind statement in C2SMTP.INI, and ensure it's set to 
   the right value for your subnet.  See the netmask 
   parameter for the Bind option in the section entitled 
   "Configuration Settings - M2TCP"

2. If pinging another local TCP/IP host works, the 
   network card is working OK, ARP is working OK, and 
   the subnet mask is set correctly.

3. Try pinging a remote TCP/IP host using its IP address 
   (not its host name) to see if network traffic through 
   your router is working.

   If this doesn't work, check the ROUTE statement in 
   C2SMTP.INI (see the Route option in the section 
   entitled "C2SMTP.INI Configuration Settings - 
   M2TCP") and ensure that it contains an entry with a 
   valid IP address for the router that provides remote 
   access to other networks.

   If the router's IP address is in question, try pinging the 
   router itself with the same IP address.

4. Try using Ping with the host name of a remote host 
   instead of its IP Address.  This ensures that the name 
   server entries in C2SMTP.INI are set correctly and 
   that they are responding.

   If there's a problem with name server lookups, try 
   using the <N>SLookup option with a well known 
   host name and watch what happens.  The DNS 
   interactions from a NSLookup are quite a bit more 
   verbose than with a <P>ing or <T>elnet/25 
   command (unless you ran Connect2SMTP with a -N 
   switch).

   If you have problems with the Ping or Telnet/25 
   commands, the only options in C2SMTP.INI that could 
   have an effect are the Bind and Route statements if the 
   problem is with an Ethernet host.  If the problem is 
   with a host on the other end of a SLIP or PPP 
   connection, refer to the SLIP and PPP statements in 
   C2SMTP.INI. 

5. Try "bouncing" a message through Connect2SMTP by 
   addressing an MHS message to another user in your 
   own MHS workgroup (or your own MHS workgroup 
   name).  For example, if Connect2SMTP's TCP/IP 
   hostname is "acme.com", and its MHS gateway name 
   is "SMTP", address an MHS message to "joe@SMTP 
   {joe@acme.com}".

This will test that:
-MHS is properly routing messages to Connect2SMTP.
-Connect2SMTP is receiving and converting MHS 
 messages.
-The SMTP module and its queue system are working OK.
-Connect2SMTP can talk to itself through Mach2.
-MHS is receiving and routing SMTP messages converted by Connect2SMTP. 
 
6. Try sending a message through Connect2SMTP to a 
   user in another domain.  You can watch how the 
   SMTP messages are processed by switching to the 
   SMTP console. 

Note: Successfully receiving Ping replies from another host does not 
necessarily mean that its SMTP capability is working.  
Occasionally, an SMTP server may stop accepting connections even 
though the host will respond fine to an ICMP Ping.  The only way 
to fully test a remote host's current status of receiving mail is by 
using the Telnet/25 command


Using the Consoles
==================

The various activities of each loaded module can be be viewed 
and evaluated from their respective console screens.  This 
section reviews how to use the console screens, and the tools 
that are available to the Connect2SMTP administrator.

The Connect2SMTP Screen Layout
At startup, Connect2SMTP displays the console screen of the 
first module loaded (as determined by module load order in 
C2SMTP.INI).

The four top-most screen lines are a header area that remains 
undisturbed across all operations within Connect2SMTP.

The bottom-most screen line is the status line, which normally 
displays items of high-interest continuously in real-time.  When 
the status line is active, its format remains the same regardless 
of which console is active.  (This line is also used temporarily 
by each module when they display a verbose list of their 
commands, and when needed to accept keyboard input.)

The status line is also used to temporarily display the console 
commands available for the active module.  To do this, press 
either the <Esc> or <Tab> keys.  (The keyboard commands a 
module recognizes are always active regardless of whether they 
are displayed.)

If the <Tab> key is pressed again (while console commands are 
displayed), the active console rotates to the next loaded module.  
If the <Esc> key is pressed while console commands are 
displayed, the status line returns back to normal status display.

In addition to using the  <Tab> key to rotate between consoles, 
each loaded module can also be accessed directly with a hot-
key, which are:

Module   Hot-key

MHS      Alt-M

SMTP     Alt-S

M2TCP    Alt-T


Scroll Back
You can scroll back through previous activity in all console 
screens, by pressing either the <Up>, <PgUp>, or <Home> 
cursor keys (to initiate the scroll back mode).

While scroll back is active, use the standard cursor keys (<Up>, 
<Dn>, <PgUp>, <PgDn>, <Home>, and <End>) to 
manipulate the screen within the scroll back buffer.  To 
manually cancel scroll back, press the <Esc> key.  Scroll back 
automatically cancels after 5 minutes of inactivity.

When scroll back is active, an "SB" is displayed in the bottom 
right corner of the status line, and the screen is considered 
frozen, which means Connect2SMTP will not scroll it 
automatically if new activity occurrs.

See the section entitled "Console Scroll Back and Memory 
Usage" in the Technical Reference for more information.

The MHS Console
The MHS module handles message conversion to and from 
SMTP format.

The MHS Console displays a condensed list of mail activity that 
has passed through the gateway.  Each line represents a message 
that was sent to a particular recipient.  If a single message was 
addressed to more than one user, a separate line is used for each 
recipient.

At the MHS Console, you can press <Esc> to temporarily 
display the commands available.

The following commands are active from the MHS Console:

S - SysInfo - Displays information about the system's 
environment. Use Page Down to review additional information:

C - Configuration - Shows all possible C2SMTP.INI field 
names and their parsed values.

L - Lists - This command activates a submenu that enables the 
following two commands:

F - Forward - Displays all forwarding that has been set up 
using the FORWARD file, similar to the following:

H - HubLic - Displays a screen that shows the MHS workgroup 
names that are considered part of the basic license, and a list of 
additional MHS workgroups that are licensed (authorized) from 

Ctrl-C - Cycle - Forces Connect2SMTP to scan for messages 
without waiting for the next scan interval.  This is most often 
used when watching mail go through the gateway, and you don't 
want to wait for the next scan interval.

Ctrl-S - Suspend - This command suspends MHS conversion 
activities.  This is mainly useful for troubleshooting purposes 
when trying to salvage a file from one of Connect2SMTP's 
queue directories.  This command does not permamently 
suspend conversion activities, it simply extends the time till the 
next cycle by 1 hour.  To resume normal scanning, press <Ctrl-C>.

Q - Quit - This command exits Connect2SMTP.  If shutting 
down would adversely affect an operation in progress (such as if 
an SMTP connection is active, or if a MHS conversion is 
active), Connect2SMTP will display a warning of this condition 
before it actually shuts down.  If this is the case, you may then 
select to stop Connect2SMTP immediately, cancel the Quit 
command, or perform an orderly shutdown (recommended), 
which causes all in-process activity to be completed prior to 
exiting.  If no such conditions exist, Connect2SMTP will issue a 
simple "are you sure" prompt just to double check that you 
really want to shutdown.  While either of these two types of 
prompts are active, Connect2SMTP will not start any new 
activitiy and will reset any new SMTP connection attempts 
received.

Note:   The operation of the Quit command is the same regardless of which 
console is active.

MHS Activity Indicator
When the MHS Console is active, the MHS module displays an 
indication of its activity in the bottom right-most corner of the 
status line.

When the MHS module is idle, it displays a count down value 
that represents the number of seconds remaining until the next 
scan cyle.

When the MHS module is converting a message, it displays a 
code that indicates what stage of the conversion process is 
active, as follows:

Code       Description

MS:nn      File scanning for new outbound MHS messages

MC:nn      Converting outbound MHS messages

SS:nn      File scanning for new inbound SMTP messages

SC:nn      Converting inbound SMTP messages

SF:nn      Forwarding inbound SMTP messages (FORWARD file)


The number (nn) displayed is the number of repetitions 
processed during the current cycle.

MHS Message Codes
When the MHS module converts a message (in either direction) 
it may display a code following the recipient address that 
indicates some type of special handling, a messaging attribute, 
or that the message had file attachments.

These codes are defined as follows:

Code       Description

[RCPT]     The sender requested a return receipt

[SCRAP]    The message had an attachment that was discarded 
	   because the filename matched the value of a 
	   DiscardAttachName statement in C2SMTP.INI

[M:ATCH]   The message had body text or attachments that were 
	   encoded in MIME format

[U:ATCH]   The message had attachments that were 
	   UUENCODED



The SMTP Console
The SMTP module performs the SMTP server functionality 
defined by RFC-821.

Each screen line displayed in the SMTP Monitor begins with 
either:

A number that indicates which active process generated the 
line

A "$$:" which indicates a system-level error or message (i.e. 
an asynchronous error, the SMTP task dispatcher, or the 
module's foreground handler)

An "NS:" if a domain name server ICMP message is 
received asynchronously

When <Esc> or <Tab> is pressed, the commands available at 

The SMTP Console provides a number of commands that can 
help test connectivity with other TCP/IP hosts:

F - Filter - Normally the output from all active SMTP processes 
is displayed in chronological order, and will be intermixed if 
more than one process is active simultaneously.  This command 
allows the screen to be filtered to show only the output of one 
particular process.  When a filter is active, a "F:nn" is displayed 
in the bottom right corner of the status line.  Pressing the <Esc> 
key cancels an active filter.

M - MailQ - This command displays a submenu that shows 
messages pending in the outbound queue.  The screen is 
refreshed every 10 seconds.

N - NSLookup - This command initiates a domain name 
service lookup for a particular host name.  This can be useful for 
checking the proper operation of the name servers identified in 
C2SMTP.INI, or for determining whether a particular host name 
is valid, and if so, what its IP address is, or MX records are.

If an IP Address is entered instead of a host name.  The SMTP 
module will automatically invert it to the IN-ADDR. format and 
do a reverse name lookup to find its host name.

P - Ping - This command initiates a series of ICMP echo 
requests with another TCP/IP host (the default is one per second 
for 10 seconds).  This is a good way to check if 
Connect2SMTP's basic TCP/IP connectivity is working 
properly, or to test if another TCP/IP host is alive (or reachable 
through your router).

The Ping command has the following syntax:

Ping: host [count [size [interval]]]

The host can be given as either a host name or an IP Address.  If 
a host name is used, it may take a couple seconds to resolve the 
IP Address before pinging actually starts.

The value of count is the total number of packets to send (the 
default is 10 if not given).

The size is the data portion of the ICMP packet (total size sent 
also includes an IP header and an ICMP header, another 28 
bytes).  The default is 64 bytes.

The interval is the frequency at which packets are sent.  This 
value is given in CPU clock ticks.  Clock ticks fire 18 times a 
second, so a value of 18 produces one packet per second (the 
default value is 18 - or one packet per second).  If a value of 
zero (0) is explicitly given for the interval, the SMTP module 
will send an almost constant barrage of Ping packets to the 
destination host (some hosts may have trouble keeping up if the 
machine C2SMTP is running on is equal to or faster).

R - Route - This command does a function similar to the UNIX 
CheckRoute function.  It accepts an IP Address (or host name), 
asks Mach2 to route the address, and then displays which 
interface and NextHop IP Address would have been used.  This 
is useful when testing the routing table (especially if more than 
one interface is involved), or that a default route is working 
right, etc.  If tests with this command don't seem to be working 
right, the statements in C2SMTP.INI that have an influence are: 
ROUTE (under [M2TCP]), and NETWORK (under a SLIP or 
PPP definition).

S - Stats - This command displays running statistics 
accumulated by the SMTP module.

T - Telnet/25 - This command initiates a Telnet session with 
another host using port 25, the port which the SMTP service 
runs on (port 23 is the normal Telnet port).  This is a good way 
to check if another TCP/IP host is ready to receive inbound 
SMTP mail, or if it is refusing new connections.

After a connection is established with this command, the remote 
host thinks you are an originating SMTP server.  Most SMTP 
servers will respond to "HELP" and "QUIT" commands.  
Pressing <Esc> will also quit a connection.

Note: There are a number of text-based commands available that might 
prove useful, but they are beyond the context of this documentation.  
Refer to RFC-821 for details.

Q - Quit - This command quits Connect2SMTP.  Refer to the 
same command described under the MHS Console for more 
information.

Mach2 TCP Console
The M2TCP module is an interface module that dynamically 
links the Mach2 TCP/IP protocol stack into Connect2SMTP's 
environment, and it also provides a user interface that allows 
you to browse various statistics, tables, and configuration 
information relating to its operating environment.

The M2TCP Console initially shows information related to the 
loading and binding of the stack.

If any TCP/IP errors occur while Connect2SMTP is running, 
they are logged on this screen.  (And in the error log if the -E 
command line switch was given at startup.)

The M2TCP Console provides the following commands:

S - Stats - Displays a submenu from which you may select 
statistics for all Interfaces that have been defined, or statistics 

^S - Sockets - Displays a summary of sockets in use. 

T - Tables - Displays a screen that shows a number of items 
related to Mach2's current operating status, such as the 
Interface Table (all defined interfaces), Local IP Address 
Table, (all local Ethernet IP Addresses), the Routing Table 
(derived from ROUTE commands in C2SMTP.INI and from RIP 
information received, if enabled), and the ARP Cache Table.

If you are using a SLIP or PPP interface, a Serial Device Table 
is also displayed, which shows real-time information pertaining 
to each serial port, and their connection status.

Q - Quit - This command quits Connect2SMTP.  Refer to the 
same command described under the MHS Console for more 
information.
  

Addressing
==========
This section covers the basics of addressing between MHS 
based e-mail programs and users of SMTP mailers.  For 
additional options, see the section entitled "Complex  
Addressing" in the Technical Reference section of this manual. 

SMTP to MHS Addressing
When an SMTP message is sent to an MHS user, it can be 
addressed in a number of different ways depending on how you 
configure Connect2SMTP, and also depending on how your 
TCP/IP mail domain is configured in your domain name server.

Connect2SMTP supports several different mapping algorithms 
to translate an MHS "user@workgroup" address into a valid 
SMTP/Internet address.

For the following examples, we will assume that 
Connect2SMTP has been configured to use an internet domain 
name of "mydomain.com".

Single Workgroup Configuration
If your MHS configuration consists of a single MHS 
workgroup, then you will probably want to keep your SMTP 
addresses as simple as possible, such that an MHS address of:

user@workgroup

translates to an SMTP address of:

user@mydomain.com

This type of address conversion is configured by setting 
ExcludeHubName=Yes in the [MHS] section of C2SMTP.INI.

Please note that this setting should only be used if all users of 
the C2SMTP gateway are part of the same MHS workgroup.

Multiple Workgroup Configuration
If users from multiple MHS workgroups will be using the 
Connect2SMTP gateway, then it will be necessary for C2SMTP 
to include both the MHS user and workgroup names in the 
SMTP address.

The "InverseHubSyntax" setting is the preferred address  
mapping technique for a multiple workgroup configuration.  If 
InverseHubSyntax=Yes in the [MHS] section of C2SMTP.INI, 
then an MHS address of:

user@workgroup

would translate to an SMTP address of:

user@workgroup.mydomain.com

If you decide to use InverseHubSyntax, all MHS workgroups 
that will receive SMTP mail must be registered as individual 
hosts with your domain's name server, or a "wildcard" MX 
record must be configured within your domain's name server to 
direct mail for any host under your domain to the 
Connect2SMTP host.

The alternative to InverseHubSyntax in a multi-workgroup 
MHS environment is to include the MHS workgroup name to 
the right of the "@" symbol, together with the user name.

The HubDelimiter setting in the [MHS] section of C2SMTP.INI 
determines which character will be used to separate the MHS 
user and workgroup names.  Valid HubDelimiter settings are 
"%" or ".".

Therefore, an MHS address of:

user@workgroup 

would translate to either:

user%workgroup@mydomain.com
or:
user.workgroup@mydomain.com

  
Including or Excluding the TCP/IP Host Name

Unless InverseHubSyntax is active, C2SMTP defaults to 
including the configured TCP/IP host name when building 
SMTP addresses.

Assuming that the TCP/IP host name of your C2SMTP host is 
C2SMTP, yielding a fully qualified host name of 
C2SMTP.mydomain.com, by default C2SMTP will use the 
combination of the TCP/IP host name and domain when 
building SMTP addresses.

Therefore, in a single user workgroup configuration with the 
ExcludeHubName setting active, an MHS address of: 

user@workgroup

would translate to:

user@C2SMTP.mydomain.com

To exclude the TCP/IP host name from the address, it is 
necessary to set ExcludeHostName=Yes in the [MHS] section 
of the C2SMTP.INI file.

MHS to SMTP Addressing
When MHS mail is sent through Connect2SMTP to an SMTP 
user, the message is addressed to Connect2SMTP's MHS 
gateway name (GatewayName in C2SMTP.INI); much like 
addressing to another MHS hub.

The actual SMTP address is then enclosed in curly braces (an 
MHS "extended" address), as follows:

user @ host {extended_address}

For example, if Connect2SMTP's gateway name is called 
"SMTP", and an MHS user wants to send mail to 
"joe@acme.com", the message is addressed as follows:

email @ smtp {joe@acme.com}

When running Connect2SMTP with Connect2 or NetWare 
Global MHS, it is possible to specify SMTP addresses directly 
(if your e-mail application supports it), without having to use 
MHS extended addressing.

To enable this option in Connect2, run C2SETUP.  From the 
main menu select "Configure Internet/SMTP Addressing".  In 
the screen that follows, specify the C2SMTP gateway name 
(usually SMTP) and an address mask appropriate for this 
gateway such as MAIL@SMTP{?}.  Refer to your Connect2 
manual for additional information.

Using native SMTP addressing with NetWare Global MHS is 
also possible.  To configure this mode you must first set 
NativeSmtpSyntax=Yes in the [MHS] section of C2SMTP.INI.

Next, in the NGMHS NGMADMIN.NLM utility, you must 
ensure that C2SMTP was installed as an SMF-71 gateway.  
From the NGMADMIN Main Menu select "This Server", then 
"SMF Gateways".  Then, select the gateway defined for 
C2SMTP.

Within the "SMF Gateways Menu", you will also need to tell 
NGMHS how to recognize internal addresses and pass them to 
the C2SMTP gateway.  Select "Additional Address Formats 
Supported".  Then, press <Insert> to add each relevant SMTP 
root domain using the following format:

**@**.com
**@**.org
**@**.edu
**@**.gov
**@**.mil

Note:  When adding additional address formats, the menu will 
also prompt for a priority number.  For most configurations, this 
value will not matter.  Refer to the NGMHS documentation if 
you would like more information on this feature.

Overriding Outbound Encoding 
Connect2SMTP supports both MIME and Uuencoding methods 
of encoding file attachments.  When an MHS message has 
binary file attachments, the attachments must be encoded using 
one of these two techniques (otherwise they would almost 
definitely violate the rules of SMTP message transport)

But only one or the other can be the default (which is 
Uuencoding unless MIME=Yes under the [MHS] section of 
C2SMTP.INI).

If you enabled MIME as the default, there may be occasions 
when a user would rather send binary file attachments 
UUENCODED instead of in MIME's BASE64 format, because 
the recipient's mail system does not support MIME but does 
support UUDECODING.

Or, you may decide not to use MIME as the preferred (default) 
method of outbound encoding (because a number of other 
SMTP gateways still don't support it), but there may be 
occasions when an MHS user wants to send a message to an 
SMTP user in MIME format even though UUENCODING is 
the default.

To support these situations, the preferred method of outbound 
encoding can be overridden on a per message basis using two 
different types of addressing syntax:

Prefix Overrides
The preferred method of outbound encoding can be overridden 
by prefixing an SMTP address with one of the following text 
strings:

Prefix     Description

MIME:      Forces a message to use MIME encoding when 
	   Uuencoding is the default.

UUENCODE:  Forces a message to use Uuencoding when 
	   MIME is the default.

RCPT:      Requests a return receipt.


For example:

To: JOE @ SMTP {mime:joe@acme.com}
To: JOE @ SMTP {uuencode:joe@acme.com}
To: mime:john@acme.com

A delivery receipt override can also be expressed in this manner 
by using a "RCPT:" prefix (in the event MHS return receipts 
have been disabled), and multiple prefixes can be expressed if 
necessary.  For example:

To: JOE @ SMTP {rcpt:mime:joe@acme.com}

Prefix overrides, as the name implies, must be expressed before 
the start of the SMTP address.  Connect2SMTP won't recognize 
these flags if they occur at any point after the address has 
started.

If you have a mail system (such as DaVinci eMAIL) that reacts 
to the colon before the message is given to Connect2SMTP, a 
forward slash (/) can also be used to separate the prefix text 
from the address.  For example:

To: JOE @ SMTP {rcpt/mime/joe@acme.com}

Address Switches
Address switches start with a forward slash and can be used in 
the SMTP address either after the user name, or after the host 
name.

Switch     Description

/M         Forces a message to use MIME encoding when 
	   Uuencoding is the default.

/U         Forces a message to use Uuencoding when 
	   MIME is the default.

/R         Requests a return receipt.


For example, if MIME is the preferred encoding, messages can 
be addressed as follows to force UUENCODING instead:

To: JOE @ SMTP {joe@acme.com/u}
To: JOE @ SMTP {joe/u@acme.com}

Address switches are not recognized if the character 
immediately following the switch is not one of the expected 
delimiters (i.e. an "@", the closing curly brace, etc.).  This 
prevents false recognition if some part of an SMTP address 
actually uses a slash character.

In the event an outbound message is sent to multiple recipients, 
the message can only be built using one of the encoding 
formats.  If the encoding format is overridden, the override 
applies to all recipients. If more than one address in the 
recipient list uses an override, the last override encountered will 
control the encoding format.

Both types of overrides are automatically removed before the 
message is actually sent.

Using the SMTP address field to override the default encoding 
allows the use of address books, nicknames, or templates as a 
method to save (or shorten) the addressing syntax needed if 
repeated use is required.

Templates For E-Mail Programs
To make addressing SMTP mail easier for your users, create a 
template for Connect2SMTP addresses.  Here are templates for 
ExpressIT!, BeyondMail and Da Vinci to assist you.

Note: The following examples assume that Connect2SMTP was installed 
with a gateway name of SMTP.

ExpressIT!
The following method may be used 1) by the user to edit their 
Personal Address Book or 2) by the System Supervisor when 
running EXNICNAM.EXE to add to the system address book.  
Create an entry as follows:

Name:         SMTP

Description:  Connect2SMTP Template

Address:      ??Connect2SMTP??SMTP@SMTP{?Address?}


The text between the double question marks ("Connect2SMTP" 
in the example) is displayed as the dialog box title followed by 
"Recipient" .  The text between the single question marks 
("Address" in the example) is displayed to the user for entry.

BeyondMail
BeyondMail stores templates in a file called BMAILNAM.TPL 
in the BeyondMail PUBLIC directory.  Edit this file and add an 
entry that looks like this:

name "SMTP"
format "SEND@SMTP {^0}"
part 0,0,"Address","^0","",N,1,50,N
end

When users modify their address books they will see an SMTP 
template that prompts them for an SMTP address.

Da Vinci eMAIL
The mail administrator must add templates to Da Vinci name 
lists.  The name should be added as follows:

Name: #SMTP
e-mail: SEND@SMTP{(%1)};Address:50

Users may then select the template when creating a message, 
and they will be prompted for an SMTP address.


Asynchronous SLIP and PPP Driver Support
========================================
Introduction - Asynchronous SLIP and PPP Driver Support
Using the PPP (Point to Point) or SLIP (Serial Line Interface) 
protocols over an asynchronous (serial) dial-up connection with 
off-the-shelf modems has become a viable and cost-effective means 
to add the enormous additional level of connectivity available on the 
Internet (and/or with other private TCP/IP networks), to your 
local network.

Almost all Internet service providers now provide unlimited 
(non-metered) use of 14,400 or 28,800 baud dial-up accounts 
for relatively low cost.  If your area has a local service provider 
that does not meter dial-in accounts, and if the phone call to 
your local service provider is local (non-metered), you can 
remain connected indefinitely without incurring additional cost.

But one obstacle still remains for some organizations - the 
additional start-up cost of purchasing router hardware (needed 
to provide the link between your network and the service 
provider).

Connect2SMTP (through the Mach2 TCP/IP protocol stack) 
removes the need for special router hardware by completely 
implementing the PPP and SLIP protocols internally.  
Combined with Mach2's ability to forward IP packets 
asynchronously between other nodes on your network,  
Connect2SMTP becomes a high-performance, cost-effective 
router.  But that's not all, Connect2SMTP also lets you extend 
this connectivity to other remote sites or dial-in nodes just by 
adding more modems.

Since Connect2SMTP runs on a standard PC, your dependency 
on this important capability is not based on special hardware.  If 
something breaks, you're simply dealing with a normal PC and 
modems.  If something needs to be re-configured, you don't 
have to deal with an alien operating system - you only need to 
modify one text file under MS-DOS, and then restart 
Connect2SMTP.  If you need a status report, you can enable the 
tracing option (-T) and Connect2SMTP shows you on the 
M2TCP Console screen (with scroll-back), all asynchronous 
connection(s) activity.

Features
-High-speed asynchronous (interrupt-driven) RS-232 
 drivers with automatic support for 16550 FIFOing 
 UARTS.
-Can support any number of serial devices (modems or 
 direct connections) for dial-in or dial-out usage.
-Supports any number of interface definitions (SLIP or 
 PPP) as dial-in or dial-out accounts
-Supports login scripting for dial-out SLIP and PPP 
 interfaces (usually not necessary for PPP).
-Complies with RFC's 1055, 1332, 1334, 1661, and 
 1662.
-Supports interactive (user-id and password) prompting 
 for dial-in connections (with automatic cross-over to 
 PPP link establishment if a PPP host is dialing in).
-Connections can be configured as constant (if broken, 
 they are automatically reconnected), or timed so that 
 they are disconnected automatically after a configured 
 period of inactivity.
-No need for special hardware, Connect2SMTP runs on 
 a standard PC.
-Can be run in either real-mode, or as a native high-
 speed, protected mode application with direct access to 
 all extended memory available.

Technical Concepts and Limitations
==================================
Before configuring Connect2SMTP for use with PPP or SLIP, it 
could prove helpful to review some of the technical issues and 
concepts involved.

The Mach2 TCP/IP stack maintains two logically separate lists:

  Serial Devices
  Interface Definitions

Each serial port available to Mach2 is configured as a serial 
device.  Each SLIP or PPP connection, whether dial-in or dial-
out, is configured as an interface definition.

When configuring a serial device, you describe the elements 
that pertain to the communication port and the modem attached 
to it (e.g. baud rate, modem initialization string, etc.).

When configuring an interface definition, you describe the 
elements involved with establishing the PPP or SLIP connection 
(e.g. phone number, user-id, password, etc.).

As mentioned, serial devices and interface definitions are two 
different lists.  This allows interface definitions (PPP or SLIP 
connections) to be dynamically linked and unlinked with serial 
devices based on demand.

For instance, when a PPP interface is configured as a non-
dedicated connection, the first time an IP packet is sent to the 
PPP interface when it isn't currently connected, Mach2 searches 
the list of serial devices for one that isn't in use, links it to the 
PPP interface, and then tells the serial device to initiate a 
connection using the configuration defined in the PPP interface.

Serial Devices
Serial devices are the COMM ports Mach2 uses to drive a SLIP 
or PPP interface.  When configuring a serial device, you define 
the characteristics of the serial port (and the modem attached to 
it).

Mach2 can support as many serial devices as your hardware will 
allow.  Connect2SMTP provides a license for two serial devices 
as part of the basic product license.  Additional serial device 
licenses can be purchased separately.

Serial devices are driven completely asynchronously in the 
background using efficient interrupt handlers for both data 
transmission and reception.

Each serial device contains its own "intelligence".  That is, they 
asynchronously manage all aspects of establishing a dial-out 
connection, and if so configured, all phases of handling a dial-in 
connection; such as logging in the caller, and after successfully 
identifying the inbound call, "waking up" and linking the serial 
device with the caller's interface definition in order to start the 
data connection - all without disturbing whatever process is 
running in the foreground.

UART performance is optimized by using small, quickly 
addressable ring-buffers for data reception and transmission.  
This technique has an almost completely transparent impact on 
the performance of processes running in the foreground, even 
when supporting baud rates as high as 128,000.

UARTS
If a serial device has a 16550 FIFOing UART installed, Mach2 
will automatically detect it and adjust its operating 
characteristics for optimum use with the 16550.

Using a 16550 UART is highly recommended for baud rates of 
9600 and higher.  (In fact, Mach2 displays a warning each time 
it starts if you configure a serial device for a baud rate of 9600 
or higher that doesn't have a 16550 UART.)

Shared Interrupts
If you have a multi-port serial card that uses the same interrupt 
for more than one port (such as a digi-board), Mach2 will not 
talk to it "intelligently", but Mach2 will share interrupts 
internally (it won't pass an interrupt back to a previously 
installed DOS handler though because some default handlers 
are known not to reset the interrupt controller).

So, you can successfully define more than one serial device on 
the same interrupt as long as all COMM ports for that interrupt 
are handled by Mach2.  This not only holds true for multi-port 
serial cards like the digi-board, but also for standard I/O cards 
on COM1, COM2, COM3, and COM4.

Mach2's interrupt handlers are so efficient it's likely you 
wouldn't see a performance difference with multiple COMM 
ports using the same interrupt until you start using more than 16 
ports on the same interrupt.

Interface Definitions
Each SLIP or PPP connection is defined as a separate interface, 
which is similar in concept to an Ethernet interface except that 
SLIP and PPP interfaces need some additional information that 
describes how to establish and maintain the connection using a 
serial device.

From the TCP/IP packet handling level, Mach2 sees a SLIP or 
PPP interface the same as an Ethernet interface.  It's only when 
an IP packet is given to a SLIP or PPP interface for actual 
transmission that the differences begin.  As mentioned earlier, 
when a SLIP or PPP interface receives packet traffic and is not 
connected, Mach2 automatically tries to allocate an available 
serial device, and then asks the serial device to use the 
connection information defined for the SLIP or PPP interface to 
start the data connection with the remote host.  After that, the 
serial device completely manages all aspects of initiating and 
establishing the connection asynchronously (as a background 
task), while Mach2 (along with the higher levels such as SMTP), 
go on and do whatever else they can be doing until the 
connection is established.

SLIP and PPP interface definitions internally emulate a Novell 
ODI (MLID) driver.  When transmitting and receiving data, they 
asynchronously use a linked list of ECB's (a Novell term that 
means Event Control Block) which, along with buffer space 
needed, are allocated and deallocated on-the-fly by the interrupt 
handlers in the background as conditions warrant.  This means 
they borrow from the same pool of ECB's and buffers that an 
Ethernet driver uses, but it allows IP packets being received to 
be built concurrently with data reception so that when the frame 
end is detected, the packet can be handled immediately by the 
upper layers of Mach2.

SLIP vs. PPP
SLIP and PPP are similar in that they both carry IP packets 
across a serial link, but that's where any likeness ends.

The preferred protocol depends on a number of factors.  If your 
service provider only supports one, there isn't much choice.  
However, Mach2 supports both; and given a choice, most people 
usually opt for PPP.

The following sections are technical descriptions of each 
protocol.  Understanding the descriptions is by no means 
necessary; Mach2 insulates you from most of it.  However, you 
might find it helpful.

The SLIP Protocol
=================
SLIP (Serial Line Interface Protocol) is a simple protocol; its 
RFC (1055) is only six pages long, three of which are a source 
code example.  Basically, what SLIP does is transmit IP packets 
over the RS-232 port as-is, followed by a frame-end character.  
To prevent mishandling if a frame-end character happens to 
occur within the IP packet, the heart of the SLIP protocol is how 
the frame-end character is escaped when it occurs within the IP 
packet, and then how to escape the escape character.

Since SLIP is so simple, and has had a good head start, there are 
more SLIP implementations than PPP implementations.  
Strangely, though, SLIP was never adopted as a "standard"; but 
that hasn't prevented it from becoming a popular de-facto 
standard.

The simplicity of SLIP causes it to lack a number of desirable 
features.  One is that there is no means to build-in an 
authentication mechanism.  So, when dialing into a SLIP 
account, you almost always first receive a text-based interactive 
login prompt first.  After you successfully identify yourself, 
(and sometimes after also having to type an additional 
command), then the host starts a SLIP session.  This is why a 
scripting capability is desirable when dialing into most SLIP 
accounts.

Another shortcoming is that there is no method to exchange or 
negotiate capabilities, which means both ends must be 
configured identically beforehand, or it probably won't work.

A final shortcoming is that there is no checksum or CRC check 
performed on data received over SLIP.  SLIP relies on the 
medium to be relatively error-free, and if not, that the various 
IP-level checksums will catch any transport-induced errors.

Note:   Mach2's SLIP implementation DOES NOT support VJ header 
compression.  If you are configuring a SLIP interface, make sure 
that the other end does not use header compression.

The PPP Protocol
================
PPP (Point to Point Protocol) is newer and much more robust 
than SLIP.  All of the shortcomings mentioned before under 
SLIP are addressed by PPP.  But PPP is so much more complex 
that it has taken PC-based solutions a significantly longer time 
to implement the protocol, some of which are still a work in 
progress.  In fact, PPP's level of complexity parallels that of 
other multiplexing protocols such as ODI.  This, although rare, 
creates more room for confusion and incompatibility between 
different implementations.

Configuration
Defining a SLIP or PPP interface, and defining the serial 
device(s) they will use, begins in the [M2TCP] section of the 
C2SMTP.INI file.

There are three statements used in the [M2TCP] section that 
involve configuring a SLIP or PPP interface:

SerialDevice=
SLIP=
PPP=

A minimum configuration would define one serial device, and 
an interface that uses the serial device.

For example:

[M2TCP]                      ;Mach 2's section start
   
  SerialDevice=COM1          ;Define a serial device
  PPP=PSI                    ;Define a PPP interface
  
[COM1]                       ;Serial device section name
  Comm=1                     ;Uses std COM1 port/irq
  Baud=38400                 ;Baud rate
  InitString=ATX4&H1&B1&K3   ;Modem init string

[PSI]                        ;PPP interface section name
  NextHop=199.34.2.21        ;Svc provider's IP Address
  Network=0.0.0.0            ;Route all packets to us
  DialString=ATDT555-1234    ;Phone number to dial
  UserID=s123ab              ;Our login user name
  Password=xxxxx             ;Our login password

This example is almost a working PPP sample configuration!  
(Except for missing a few other things from the [M2TCP] 
section if a local Ethernet network is present.)

[M2TCP] Statements
===================

SerialDevice=      section_name

This statement defines and configures a serial device (comm 
port) that will be used by a SLIP or PPP interface.

This statement can occur more than once to define as many 
serial devices as your hardware supports.

The value specified by the statement refers to the name of 
another [section] within C2SMTP.INI that then describes the 
serial device.

For a complete list of serial device statements, and other issues 
regarding the configuration of a serial device, refer to the 
section entitled "Serial Device Configuration".

SLIP=   section_name
PPP=    section_name

These statements define and configure a SLIP or PPP interface.

These statements can occur more than once in order to define as 
many different SLIP or PPP interfaces required.

The value specified by the statement refers to the name of 
another [section] within C2SMTP.INI that then describes the 
SLIP or PPP interface.

For a complete list of interface statements, and other issues 
regarding the configuration of a SLIP or PPP interface, refer to 
the following section.

Interface Configuration
=======================
Defining and configuring a SLIP or PPP interface is performed 
using SLIP= and PPP= statements in the [M2TCP] section of 
C2SMTP.INI.

For example:

[M2TCP]                      ;Mach 2's section start
  SerialDevice=COM1          ;Define a serial device
  SLIP=Digex                 ;Define a SLIP interface
   
[Digex]                      ;SLIP interface section name
  NextHop=199.34.2.21        ;Service provider's IP Address
  Network=0.0.0.0            ;Route all packets to us
  DialString=ATDT555-1234    ;Phone number to dial

Note that the [M2TCP] and [Digex] sections are not complete.  
The example only intends to show how the SLIP= statement 
points to another [section] which then defines the SLIP 
interface.

The above example also holds true for a PPP interface.  The 
statements used under both types of interfaces are identical, the 
distinction between whether an interface is PPP or whether it is 
SLIP, is based solely on whether SLIP= is the statement that 
referred to the definition, or whether PPP= was the statement 
that referred to the definition.

There is no restriction on what you name the section that 
defines a SLIP or PPP interface other than that the section name 
cannot exceed 9 characters, and it cannot match the name of 
another section already defined (both of which will produce an 
error when Connect2SMTP initializes).

Sample SLIP Definition

[M2TCP]                           ;Mach 2's section start
  Bind=199.10.1.4, 255.255.255.0  ;Bind the Ethernet card
  IPForward=Yes                   ;Enable packet forwarding
  SerialDevice=COM1               ;Define a serial device
  SLIP=DIGEX                      ;Define a SLIP interface

[COM1]                            ;Serial device section name
  Comm=1                          ;Uses std COM1 port/irq
  Baud=38400                      ;Baud rate
  InitString=ATX4&H1&B1&K3        ;Modem init string

[DIGEX]                           ;SLIP intf section name
  NextHop=199.34.2.21             ;Svc provider's IP Addr
  Network=0.0.0.0                 ;Route all packets to us
  DialString=ATDT555-1234         ;Phone number to dial
  ConnectScript=SCRIPT1           ;Login script to use

[SCRIPT1]                         ;Login script for DIGEX
  WaitFor=Login:                  ;Wait for this text
  Send=s123ab                     ;Then send our login name
  WaitFor=Password:               ;Wait for this text
  Send=xxxxx                      ;Then send our password
  WaitFor=Beginning....           ;And make sure SLIP starts

As with the other examples so far, this one also does not use all 
of the options possible under the serial device (COM1), or the 
SLIP interface (DIGEX), or the login script (SCRIPT1).  But, 
this is a representation of a minimum SLIP configuration, and 
the other options possible could well default to the correct 
values needed.

In this example, we also bind to an Ethernet card that is 
presumably connected to a local LAN with a Class C subnet.  
(The BIND command creates an Ethernet interface.)

Since the IP forwarding option is enabled, Mach2 will route 
packets between the Ethernet interface and the SLIP interface.

The Network= statement under the SLIP interface creates a 
default route in Mach2's routing table, which causes all IP 
packets destined for an unknown network to be routed through 
the SLIP interface.

Since a ConnectTimeout= isn't given under the SLIP interface, 
Mach2 will consider the SLIP interface one that should be 
constantly connected, and will immediately try to establish the 
connection when Connect2SMTP starts up.

This simple configuration might be all you need to create a fully 
capable router between your network and the Internet.

Sample PPP Definition

[M2TCP]                           ;Mach 2's section start
  Bind=199.10.1.4, 255.255.255.0  ;Bind the Ethernet card
  IPForward=Yes                   ;Enable packet forwarding
  SerialDevice=COM1               ;Define a serial device
  PPP=PSI                         ;Define a PPP interface

[COM1]                            ;Serial device section name
  Comm=1                          ;Uses std COMn port/irq
  Baud=38400                      ;Baud rate
  InitString=ATX4&H1&B1&K3        ;Modem init string

[PSI]                             ;PPP interface section name
  NextHop=199.34.2.21             ;Svc provider's IP Addr
  Network=0.0.0.0                 ;Route all packets to us
  DialString=ATDT555-1234         ;Phone number to dial
  UserID=s123ab                   ;Our login user name
  Password=xxxxx                  ;Our login password

A PPP interface gets even simpler.  Since most service 
providers auto-recognize a PPP configure-request packet, the 
login script is not normally needed.  (But can be used if 
necessary.)

Aside from the missing script, the only other differences 
between this example and the previous SLIP example are the 
UserID= and Password= statements under the PPP interface 
definition (PSI).  These statements are normally required for a 
PPP interface (unless your service provider happens to let you 
connect without authenticating yourself) because Mach2's PAP 
protocol extracts them from these variables.  (For a SLIP 
interface, the UserID= and Password= statements are only 
needed if the interface is being defined for a dial-in node - they 
serve no purpose for SLIP dial-out).

This example also binds to an Ethernet card that is presumably 
connected to a local LAN with a Class C subnet.

Since the IP forwarding option is enabled, Mach2 will route 
packets between the Ethernet interface and the PPP interface.

The Network= statement under the PPP interface creates a 
default route in Mach2's routing table which causes all IP 
packets destined for an unknown network to be routed through 
the PPP interface.

And, since a ConnectTimeout= isn't given under the PPP 
interface, Mach2 considers the PPP interface one that should be 
constantly connected, and immediately tries to establish a 
connection when Connect2SMTP starts up.

  
Additional Considerations

Serial Device Issues

In the above examples we've shown how a serial device is 
defined and configured while also showing how an interface is 
defined.  Based on those examples, you may feel that you can 
successfully configure your serial device, which may well be 
true.

The biggest serial device configuration issues are making sure 
the modem has:

 -The baud rate locked
 -Proper DTR & CD handling

Both items should be configured properly with the modem 
initialization string.  More information is available in the 
section entitled "Serial Device Configuration".

Header Compression
If you are configuring a SLIP interface, Mach2 does not support 
IP header compression (sometimes called "VJ" compression 
after its author Van Jacobsen). Make sure the other end does not 
enable header compression.

For PPP interfaces, Mach2 will negotiate that it does not support 
IP header compression.

When There is No Local Network
When you are using Mach2 as a stand-alone remote node with 
just a PPP or SLIP interface and no Ethernet interface(s), then 
the NextHop= statement takes on the meaning of your local IP 
Address, not the service provider's router IP Address.

Mach2 automatically knows that since the SLIP or PPP interface 
is the only interface it can use, that all packets should be sent 
through the serial interface (loopback issues are handled 
automatically and not sent through the serial interface).

Adding Additional Dial-in Accounts
Mach2 can easily handle additional dial-in accounts (or, though 
not described here, dialing out to more than one network 
simultaneously).

In fact, you can actually use Mach2 to get in the business of 
service providing yourself, by adding as many modems as you need to 
support dial-in accounts.  If you're using more than one modem 
for dial-in, you'd probably want to set them up with the phone 
company to rotate if busy, so that dial-in nodes only have to 
know about one phone number.

For each dial-in modem needed:

1. Define a new serial device that describes the comm 
   port to which the modem is attached.
2. Ensure that the serial device's AnswerProtocol= is set 
   to either SLIP, PPP, or both, so that the modem will 
   answer incoming calls.

For each dial-in account (node):

1. Define a new PPP or SLIP interface that describes the 
   dial-in account.
   a) Set the ConnectTimeout= to a non-zero value.
   b) Set the NextHop= to the IP address assigned to 
      the node.
 
 Note: Mach2 will automatically respond as a 
       surrogate for the remote node to any ARP 
       requests for the IP Address of the remote node 
       on all local Ethernet networks.

   c) Do not use the Network= parameter unless the 
      node dialing in is the router for another 
      network, and not just a single computer.  If the 
      dial-in node is another router, set the 
      Network= statement with the net mask of the 
      remote network.  Add additional Network= 
      statements for any other networks that are 
      reachable through this node.
   d) Use the UserID= statement to give the account 
      a unique name (even if it's a SLIP interface). 
   e) Use the Password= statement to give the 
      account a password (even if it's a SLIP 
      interface).

Interface Statements

NextHop=                n.n.n.n
--------------------------------
This statement tells Mach2 what the IP address is for the other 
end of the SLIP or PPP connection (which is the next hop that 
IP packets make when leaving your network).  This is normally 
the IP Address of your service provider's router, unless the 
interface being defined is a dial-in account.

When configured as a stand-alone remote node, the NextHop= 
address should be your local IP Address.

This field may be set to 0.0.0.0 for a PPP interface definition, 
indicating that the peer needs to identify its IP Address.

Network=        n.n.n.n
------------------------
When this statement is present, it tells Mach2 to add the network 
address specified as a static route in the routing table that goes 
through this interface.

If the interface is a connection to an Internet Service Provider, 
you would normally use a "Network=0.0.0.0" to create a simple 
default route for non-local packets through the interface.

If needed, this statement can be given more than once in each 
interface, to create several routing table entries for that 
interface.  (Which would be the case if several networks are 
available through the interface and none of the networks are a 
default route.)

You can check or verify the effect of Network= statements on 
the routing table by using the <T>able's menu option in 
M2TCP's Console.  An additional way to check changes to the 
routing table is to use the SMTP Console's <R>oute command.

MaxWindow=      nn
------------------
When this statement is present in a SLIP or PPP interface, the 
interface uses this value for the maximum TCP window size 
instead of using Mach2's default MaxWindow setting.  Refer to 
the MaxWindow setting under [M2TCP] for more information.
Device= [section_name,] section_name
This statement limits the serial devices a SLIP or PPP interface 
can use to just those that are specified.

Each serial device listed must have been defined with a 
SerialDevice= statement in the [M2TCP] section.

If this statement isn't used, a SLIP or PPP interface is 
considered free to use any of the serial devices defined.

DialString=     "text"
----------------------
This option specifies the dial string sent to the modem when 
Mach2 initiates a dial-out connection.

If the dial string needs to contain a semi-colon, the entire dial 
string must be enclosed in (double) quotation marks.

A carriage return is automatically appended to the dial string 
when sent to the modem.

The standard "AT" command prefix must be included in the 
string.

For example, a dial string might look like this:

DialString= "ATDT1805-555-1234".


DialTimeout=    nn
------------------
This statement controls how long Mach2 will wait for the 
modem to connect (in seconds) after it has issued the 
DialString.  If the modem's S7 register is set to a lower value, 
this timeout should never occur.

The default is 60 seconds.

RedialDelay=    nn
------------------
This statement controls how long Mach2 will wait (in seconds) 
after a failed dial-out attempt, before trying to initiate the dial-
out connection again.

The default is 10 seconds.

ConnectScript=  section_name
----------------------------
This statement defines a connect script that will be executed 
during a dial-out connection after carrier is detected.

The value given is the section name of the script to execute.  If 
this statement isn't given, no connect script is used.

PPP interfaces don't normally need to use a connect script, but 
must instead define the UserID= and Password= statements.

For more information refer to the section entitled "Login 
Scripting".

ConnectTimeout= nn
------------------
This statement determines whether the interface should be 
connected constantly, or whether the interface connects only 
when there is packet traffic going to the interface:

If this option is set to zero (or not specified), Mach2 will assume 
a constant connection mode and immediately initiates a dial-up 
sequence when it starts-up, and will immediately try to 
reconnect if the connection is ever lost.

If this option is set to a non-zero value (in seconds), Mach2 will 
not initiate a connection sequence until there is packet activity 
destined for the interface.  After connected, Mach2 
automatically disconnects if the specified period of inactivity 
occurs.

(Dial-in connections must use a non-zero value!)

UserID= "text"
--------------
The value given for this statement is used in a number of 
different ways:

If the interface is PPP, this value is sent during dial-out 
connections when the peer requires authentication.

When a dial-in PPP connection is received, all PPP interfaces 
are scanned for a UserID that matches.

If a dial-in SLIP connection is received, the text-based login 
prompt will search all SLIP interfaces for a UserID that 
matches.

When Mach2 authenticates a dial-in connection, the UserID is 
not case sensitive.  However, when Mach2 sends the value of the 
UserID to authenticate with the peer of a dial-out PPP 
connection, it sends the text exactly as it is given, without any 
case conversion.  Most UNIX-based  peer's are case-sensitive....

No two interfaces can have the same UserID.  This is for remote 
dial-in reasons because these UserID's essentially become a 
database of users allowed to dial-in on SLIP or PPP interfaces.  
If more than one UserID were the same value, we wouldn't be 
able to tell which interface belonged to the dial-in caller (or 
which Password to use for authentication).  If more than one 
interface has the same UserID at startup, a duplicate-name 
warning message is displayed.

Password=       "text"
----------------------
This value is paired with the UserID= statement whenever dial-
out or dial-in connections require authentication.  Refer to the 
UserID= statement for more information on those situations.

When Mach2 authenticates a dial-in connection, the Password is 
not case sensitive.  However, when Mach2 sends the value of the 
Password to authenticate with the peer of a dial-out PPP 
connection, it sends the text exactly as it was given, without any 
case conversion.  Most UNIX-based  peer's are case-sensitive, 
so be careful.
  
Login Scripting
===============
  
Defining a Script
Login scripts are defined from within a SLIP or PPP interface 
[section] by using the ConnectScript= statement. Using a login 
script for a dial-out PPP interface is not normally necessary.  
The interactive login prompt of most service providers 
automatically recognizes a PPP configure-request packet and 
then starts the PPP establish phase.  For a PPP interface you 
always have to give the UserID= and Password= statements, but 
you don't normally need to define a connect script.  If the 
service provider's login prompt does not automatically 
recognize a PPP configure-request packet, then go ahead and 
use a login script to get past it.

Example of  a login script:
[M2TCP]                      ;Mach 2's section start
  SerialDevice=COM1          ;Define a serial device
  SLIP=Digex                 ;Define a SLIP interface
   
[Digex]                      ;SLIP interface section name
  NextHop=199.34.2.21        ;Service provider's IP Addr
  Network=0.0.0.0            ;Route all packets to us
  DialString=ATDT555-1234    ;Phone number to dial
  ConnectScript=SCRIPT1      ;Login script to use
  
[SCRIPT1]                    ;Login script for DIGEX
  WaitFor=Login:             ;Wait for this text
  Send=s123ab                ;Then send our login name
  WaitFor=Password:          ;Wait for this text
  Send=xxxxx                 ;Then send our password
  WaitFor=Beginning....      ;And make sure SLIP starts

The value referred to by the ConnectScript= statement is the 
name of another [section] within C2SMTP.INI, that then defines 
the script.

More than one interface can point to the same script, however 
the chances are small that the prompts and login sequences for 
two different SLIP or PPP connections will be the same.

Login scripts are basically very simple; you use one statement 
to wait for text, and another to send text, which is the nature of 
almost all interactive login sequences.

When the last script statement is executed successfully, Mach2 
terminates the script, considers the channel successfully opened, 
and proceeds to the network open state (unless the script is used 
with a PPP host - in which case the PPP establishment phase 
then begins).

To create a script, you will need to know what text the remote 
host sends before it prompts for things like your User ID and 
Password.  There are a number of ways to find that out.  One is 
that you can use a regular communications package to call the 
host and go through the login sequence manually, writing down 
the text it sends right before each of the various prompts.  
Another way is to use a bogus value in a WaitFor= command 
and run Connect2SMTP with the -T switch, observing what 
happens on M2TCP's console screen.

For example, if the remote host sends this text when you 
initially connect:

Express Access Online Communications Service 800-555-1234
Communication Settings are eight bits no parity.

Access: _

And you type your user name, and the remote host then sends 
this text:

Access Login: Joe Smith<cr>
Password: _

And you type your password, and the remote host then sends 
this text

Password: XZW712<cr>
SL/IP Session with 199.34.20.3 Beginning...

A script to automate that would look like this:

[SCRIPT1]               ;Login script for DIGEX
  WaitFor=Login:        ;Wait for this text
  Send=Joe Smith        ;Then send our login name
  WaitFor=Password:     ;Wait for this text
  Send=XZW712           ;Then send our password
  WaitFor=Beginning     ;Wait for this text
  
Note: It's a good idea to end a script with a WaitFor= command 
      to ensure that Mach2 doesn't proceed into the network open 
      state unless the remote host has also done so (and accepted the 
      password).

  
Script Statements
=================

WaitTimeout=    nn
------------------
This statement overrides the default WaitFor= timeout.

When the WaitFor= statement is encountered in a script, Mach2 
starts waiting for the text that was specified.  WaitTimeout= 
governs how long Mach2 will do that before giving up on the 
connection attempt.

You might want to adjust this value downward a bit if you 
frequently have problems with the other end not recognizing a 
new connection.  That is, if your modem dial's another host, 
gets connected, but the remote host fails to recognize it and send 
a login prompt, why wait 60 seconds before timing out and 
starting over.

Although you can give this statement more than once in the 
same script, the result is that Mach2 will use the last one given.  
This is because scripts are compiled initially at startup, and 
when this statement is encountered its value is simply used to 
overwrite the current timeout setting.

The default is 60 seconds.
WaitFor=        "text"
This script statement tells Mach2 to pause script execution until 
the text given is received from the remote host.

This statement does not include a carriage return as part of the 
comparison, nor is it case sensitive.  If the text specified needs 
to contain a semi-colon, the text must be surrounded by double 
quotation marks.

When the text specified occurs anywhere within the stream of 
data coming from the host, the WaitFor= statement is satisfied 
and script execution immediately advances to the next statement 
in the script.  Its always a good idea to use enough text to ensure 
uniqueness.

Send=   "text[;]"
-----------------
This script statement sends text to the remote host.

A carriage return is automatically appended to the text given 
unless the text ends with a trailing semi-colon.  If you don't 
want the carriage return appended, since the semi-colon is the 
global character to start a comment, the text and the semi-colon 
must be enclosed in double quotation marks.  In the event that 
you actually want a semi-colon sent as the last character, use 
two semi-colon's in sequence (also enclosed in quotes).

There is no pause after this statement.  Script execution 
immediately continues with the next statement in the script.


Delay=  nn
----------
This script statement pauses the script execution for the 
specified number of seconds.  This is sometimes necessary at 
the beginning of a script, allowing the other end some extra time 
to wake up.

Serial Device Configuration
===========================  

Defining a Serial Device
The SerialDevice= statement in the [M2TCP] section defines 
and configures a serial device (COMM port) that can be used by 
SLIP or PPP interfaces.  This statement can occur more than 
once in order to define as many serial devices as your hardware 
supports.

For example:

[M2TCP]                 ;Mach 2's section start
  SerialDevice=COM1     ;Define a serial device
  
[COM1]                  ;Serial device section name
  Comm=1                ;Uses std com1 port/irq
  Baud=38400            ;Baud rate

Note that the [M2TCP] and [COM1] sections are not complete.  
The example only intends to show how the SerialDevice= 
statement points to another [section] which then defines the 
serial device.

There is no restriction on what you name the section that 
describes the serial device other than the section name cannot 
exceed 9 characters, and it cannot match the name of another 
section already defined (both of which will produce an error 
message when Connect2SMTP initializes).  Since in this case the 
serial device defines COM1, that's what we chose to call the 
section name - but, you don't have to.


Modem Initialization and Hardware Issues
Proper SLIP and PPP operation is largely dependent on 
understanding the hardware-related dependencies Mach2 has on 
the modem (and/or its cabling), and making sure the modem 
initialization string includes the right commands.

These issues are:

  - The modem's CD (carrier detect) line must accurately 
    reflect the current carrier detect state (AT&C1), which 
    of course must then properly pass through the modem 
    cabling.
  - When the DTR signal is lowered, the modem must 
    hang-up (AT&D2).
  - Command echo mode should be turned off (ATE0).  
    (For cosmetic purposes.)
  - For high-speed modem's (9600+), the baud rate must 
    be locked.
  - For high-speed modem's (9600+), hardware flow must 
    be used.

Since the modem commands needed to configure the first three 
items are pretty much standard across all brands of modems, 
Mach2 automatically issues a pre-initialization modem 
command of "ATE0V1&C1&D2^M" before sending the user-specified 
modem initialization string.

Unfortunately, the modem commands to lock the baud rate, or 
to specify hardware flow control, are rarely the same between 
different modem manufacturers (and sometimes not even 
between different models from the same manufacturer).  So, for 
these two items you'll have to refer to your modem's 
documentation for the proper values to use in the modem 
initialization string of the serial device.

Serial Device Statements
=========================

Comm=   1 | 2 | 3 | 4
---------------------
This option defines a standard IRQ and Port Base Address 
combination for serial devices using one of the four normal 
comm port configurations (COM1 through COM4).  If the 
communications port uses a non-standard interrupt or port base 
address, than the IRQ and/or PORT options below must be 
used.

Irq=    0 - 15

This option overrides the normal IRQ assignment.

For instance, COM1 normally uses IRQ 4, but if the comm port 
for the serial device uses a different interrupt, than it must be 
overridden with this option.
Port=   0x0000 - 0xFFFF
This option overrides the normal port base address assignment.

For instance, COM1 is normally found at port address 0x3F8, 
but if the comm port for the serial device uses a different 
address, than it must be given here.

Remember to prefix the value with a "0x" if the value is 
expressed in hex (port addresses almost always are).
Baud=   300|1200|2400|4800|9600
	19200|38400|56000|128000
This defines the baud rate used between the computer and the 
modem.

The serial device driver DOES NOT automatically adjust to 
different connect speeds.  It remains constant at the baud rate 
specified by this option.  The modem must be likewise 
configured to lock its baud rate at the speed of the last AT 
command (or at the baud rate specified by this option), which 
should be one of the items given in the modem initialization 
string.

DataBits=       7 | 8
----------------------
Sets the number of data bits (7 or 8).

The default value is 8.

StopBits=       1|2
-------------------
Sets the number of stop bits (1 or 2).

The default is 1.
Parity= None | Even | Odd
Sets the parity used (None, Even, or Odd).

The default is None.

FlowControl=    [CTS], [DSR]
-----------------------------
Sets the type of hardware flow control used.  Either "CTS" 
and/or "DSR" can be specified.  For high speed modems, some 
type of hardware flow control must be used.  Do not enable 
XON/XOFF flow control in the modem!  If hardware flow 
control is enabled with this option, it must also be enabled in the 
modem (by giving that option in the modem initialization 
string).

The default is CTS.

RxBufferSize=   128 - 65535
----------------------------
This is an advanced option that allows the size of the internal 
asynchronous receive buffer to be changed.  There is normally 
no need to change this value.


RxFifoThreshold=        1,4,8,14
--------------------------------
This parameter configures the FIFO threshold on a 16550 
UART.  It is an advanced setting that should only be used for 
testing.

Setting this value to 1 may help installations who are receiving 
occasional "LSR Character Receive Overrun" errors.


TxBufferSize=   128 - 65535
---------------------------
This is an advanced option that allows the size of the internal 
asynchronous transmit buffer to be changed.  There is normally 
no need to change this value.


NoLoopBackCheck         Yes | No
--------------------------------
When Mach2 initializes a serial device, it does an operational 
check on the UART to make sure the port is functioning 
correctly. 

However, this test may fail in a multi-tasking environment 
where access to the port is virtualized.

The SIO driver for OS/2 is known to produce this symptom.

Set this option to Yes to disable this initialization test, and allow 
the port to be used even if the test fails.


InitString=     "text"
----------------------
This specifies an initialization string that is sent to the modem 
when Connect2SMTP initializes the serial device at start-up.

If the string needs to contain a semi-colon, the entire string must 
be surrounded in (double) quotation marks.

If the carrier detect line is high at start-up, the initialization 
string is not sent.

A carriage return is automatically appended to the initialization 
string.  The standard "AT" prefix must be included at the start 
of the string, Mach2 does not insert it automatically.

Before this string is issued to the modem, Mach2 automatically 
sends a short pre-initialization string that disables the modem's 
echo (ATE0), enables proper carrier detect operation (AT&C1), 
and enables proper DTR operation (AT&D2).  The modem 
initialization string given for this option should not 
countermand the intended effect of the pre-initialization modem 
commands!  In the unlikely event that your modem does not 
react to the pre-initialization commands as intended - you 
should include the proper commands necessary in this string.  
On the same note, you should not use an ATZ in the 
initialization string if it will reverse the effect of the pre-
initialization string (ATE0V1&C1&D2).

Modem commands that should be given in the initialization 
string:

  - Telling the modem to lock the baud rate at the last 
    "AT" command (or specifically to the baud rate given 
    in Baud=).
  - Telling the modem to use hardware (CTS/RTS) flow 
    control. 

Additional modem commands that might be given in the 
initialization string: 

  - Telling the modem to use a higher result code setting 
    (i.e. X4).  When initiating a dial-out connection Mach2 
    automatically recognizes extended result codes (such as 
    "Voice", "Busy", "No Dial Tone", etc.), which can 
    significantly enhance outbound connection attempts by 
    realizing and aborting the dial-attempt as soon as 
    possible in order to start another one after the redial 
    delay expires.
  - Reducing the duration and spacing of touch tones (i.e. 
    S11=50).  Most modems default to an extremely 
    "safe" value, which can almost always be reduced to 
    smaller value that expedites the time it takes to dial a 
    phone number.  If you reduce it to a value that's too 
    small, your phone company won't recognize the 
    number that was dialed.
  - Telling the modem not to answer the phone (i.e. 
    S0=0).  If the serial device is configured to answer 
    one or more incoming protocols, Mach2 will 
    automatically handle answering inbound calls (by 
    issuing an ATA command) when it sees the Ring 
    Indicator signal raised.  If the Ring Indicator signal 
    from your modem (and through the modem cable) 
    doesn't work properly, and if the serial device should 
    answer incoming calls, than you should set S0=1 in 
    the initialization string.  Otherwise, if the Ring 
    Indicator signal works properly, its better to let Mach2 
    tell the modem when to answer a call (because Mach2 
    might be getting ready to place an outbound call).
    For sample purposes, here are a couple modem initialization 
    string examples:

US Robotics:
InitString="ATM0X4S7=55S11=55&B1&H1&K3&R2&Y3S0=0S2=255"

Telebit T3000:
InitString="ATX4M0S0=0S2=255S7=100S11=55S50=254S58=2S61=0S63=3S105=0"


AnswerProtocols=        [SLIP], [PPP]
-------------------------------------
This statement controls whether the serial device will answer 
incoming calls.  And, if so, which protocols are permitted to 
dial-in to the serial device. Either "SLIP" and/or "PPP" can be 
specified (without the quotes).

When this option is active, the DTR line on the modem is kept 
high during periods of inactivity.  If this option is not active (i.e. 
the modem is not expected to receive dial-in calls), the DTR 
line is kept low during periods of inactivity.

When a serial device is configured to answer dial-in 
connections, the modem should not be configured to auto-
answer (ATS0=1) unless Mach2's internal support for answering 
calls does not work.

When a serial device is configured by this statement to answer 
dial-in calls, if the Ring Indicator (RI) line from the modem is 
working properly, Mach2 will automatically handle telling the 
modem to answer the call.  This gives Mach2 the option of 
ignoring the incoming call if it needs to use the modem to make 
a dial-out call.


ACCM=   [nn,] nn
-----------------
This is an advanced statement that only applies when a PPP 
interface uses the serial device.

ACCM means Asynchronous Control Character Map.  The PPP 
protocol has the ability to negotiate certain characters that will 
be escaped (transposed) when they pass across the data channel.  
This can be useful in situations where there's a potential that 
equipment in-between might react inappropriately to certain 
characters in the binary data stream (e.g. a modem inadvertently 
configured to use XON/XOFF flow-control).

Unlike the normal method of expressing the ACCM as an 
encoded 32-bit hexadecimal number that you have to assemble 
by calculating the bit positions of each character desired (if 
you've previously been exposed to PPP), Mach2 uses a simpler 
method of just simply defining the escaped characters desired in 
a comma-separated list.

For instance, to escape characters 17 and 19 (XON and XOFF), 
you simply use "ACCM=17,19" (as opposed to 
"ACCM=0x000A0000").

The default is ACCM=17,19


Restart=        nn
------------------
This is an advanced statement that only applies when a PPP 
interface uses the serial device.

This statement overrides the default PPP Restart timer (in 
seconds), which is the delay that occurs between the automatic 
resending of unacknowledged Configure-Request packets.

Overriding the default value is not normally required and will 
not enhance any aspect of the PPP establishment phase. This 
option is only provided for completeness with the PPP protocol.

The default is 3 seconds.


Max_Terminate=  nn
------------------
This is an advanced statement that only applies when a PPP 
interface uses the serial device.

This statement overrides the default PPP Max-Terminate 
counter, which is the number of Terminate-Request packets sent 
without receiving a Terminate-Ack before assuming that the 
peer is unable to respond.

Overriding the default value is not normally required.

The default is 2.


Max_Configure=  nn
------------------
This is an advanced statement that only applies when a PPP 
interface uses the serial device.  This statement overrides the 
default PPP Max-Configure counter, which is the number of 
Configure-Request packets sent without receiving a valid 
Configure-Ack, Configure-Nak, or Configure-Reject before 
assuming that the peer is unable to respond.

Overriding the default value is not normally required.

The default is 10.


Max_Failure=    nn
------------------
This is an advanced statement that only applies when a PPP 
interface uses the serial device.  This statement overrides the 
default PPP Max-Failure counter, which is the number of 
Configure-Nak packets sent without sending a Configure-Ack 
before assuming that the negotiation is not converging.  Any 
further Configure-Nak packets for peer requested options are 
then converted to Configure-Reject packets.

Overriding the default value is not normally required.

The default is 5.

  

C2SMTP.INI Configuration 
========================

Settings
C2SMTP.INI is an ASCII text file that can be edited with any 
standard text editor.  It describes and controls almost all of 
Connect2SMTP's configuration.  What follows is a  summary of 
how the file may be customized to provide the features and 
functionality that you desire.

File Formatting
The formatting syntax of C2SMTP.INI is not very particular.  
Each option begins with a variable name followed by a value.  
Between the variable name and the value can be any number of 
space or tab characters (at least one must be present), along 
with an optional equals sign.

When a semicolon is encountered, it, and the rest of the line 
(and any preceding white space) is considered a comment.

C2SMTP.INI Configuration Reference
The variables and options are listed by type and in the order in 
which they appear in C2SMTP.INI.  The variable name, 
options, and defaults noted, where applicable, will be 
displayed in the heading as follows:
Setting Name    Options 
(default=)
  
[KERNEL] Section

Load               MHS, SMTP
----------------------------
Loads the specified module.  For Connect2SMTP, Load=MHS 
and Load=SMTP statements must always be present  in the 
C2SMTP.INI file.

If the optional Mach2 Domain Name Server module were 
installed, it would be loaded with a Load=Domain statement 
here.

WatchDog        Seconds
------------------------
Reboot after this many seconds of suspicious inactivity.

This variable controls whether Connect2SMTP will try to watch 
from the hardware timer-tick whether an error has occurred and 
the computer is hung-up.

If no activity has been detected either with Connect2SMTP's 
process time slicer, or the MS-DOS function dispatcher for the 
specified number of seconds, Connect2SMTP will reboot the 
computer.  This feature will only work if hardware interrupts are 
still functioning at the point when the computer needs to be 
rebooted.

A value of zero disables the watchdog.   Otherwise, if the value 
given is less than 10 Connect2SMTP will automatically raise it 
to 10.  If this value is set to 10, the computer will simply reboot 
after 10 seconds of apparent inactivity.  If the value is set higher 
than 10 seconds, the watch dog will start beeping at the 10 
second mark, and once again every two seconds, until the time 
out period expires.


Mute    Yes | No  (Default=No)
------------------------------
Prevents Connect2SMTP from beeping when error messages are 
displayed.


BlackAndWhite   Yes | No (Default=No)
-------------------------------------
This option forces Connect2SMTP to operate in a black and 
white mode.  This is useful if you have a monochrome monitor 
which is not automatically detected.


ScreenLines     25 | 28 | 43 | 50  (Default=25)
-----------------------------------------------
Number of lines on screen.

On an EGA screen, 25 and 43 line displays are possible, 
providing more information on screen.

VGA screens can operate in 25, 28, 43 or 50 line modes.


ScreenSaver     Seconds, zero disables
--------------------------------------
This variable sets the number of minutes after which 
Connect2SMTP will blank the screen if no activity has occurred.  
If enabled, a blanked screen is automatically restored when new 
activity occurs.


TimeZone        PST | PDT | MST | MDT | CST | CDT
		EST | EDT | UTC (i.e. -0800, -0500)
---------------------------------------------------
Local timezone for this Connect2SMTP host.

This variable is used when Connect2SMTP builds the "Date:" 
field in an outbound SMTP message, when the "Date:" field in 
the sender's MHS message did not contain a UTC (Universal 
Time Coordinate).

SMTP messages are expected to have a time zone in their date 
fields, but time zones are not automatically generated by many 
MHS e-mail applications.

When Connect2SMTP converts an MHS message that doesn't 
specify the time zone in its "Date:" field, it needs to know what 
time zone should be used in the outbound SMTP message.

Even if your MHS e-mail application does correctly build its 
"Date:" fields with a UTC, it's still a good idea to make sure this 
variable is set properly for Connect2SMTP.  (If the 
"ConvertTimeToLocal" option is enabled, this variable must 
contain a valid time zone.)

Note:  If a text-based time zone is entered for this variable (i.e. 
       "PST"), it is internally converted to a UTC value, and the UTC 
       value is then used for almost all of the time zone related 
       functions within Connect2SMTP.


AutoDaylightTime        Yes | No  (Default=No)
----------------------------------------------
Automatically adjust the internal universal time code (UTC) for 
daylights savings time?  This option does not automatically 
change the computer time (Connect2SMTP expects that either 
the BIOS will do that, or that its automatic time synchronization 
with the NetWare server will do that).  This option controls 
whether the time offset from Greenwhich (derived from 
TimeZone) is automatically adjusted (i.e. from -0500 to -0600) 
when switching in and out of Daylight Savings Time.


ErrorLog        Path name
-------------------------
Specify a complete path and filename if you want 
Connect2SMTP to write a single-line entry for each error or 
warning message encountered.  If the path points to a server 
volume (i.e. SYS:SMTP\INBOUND.LOG), the user name under 
which Connect2SMTP is logged must have sufficient disk 
privileges.


[MHS] Section
=============


MV      Path name
-----------------
This variable tells Connect2SMTP what directory contains 
MHS.  This path is normally entered using a volume name, not 
a DOS drive letter.  For instance, if MHS is installed in the root 
directory of SYS: (i.e. the path to the MHS Mail directory is 
SYS:MHS\MAIL), you would enter "MV=SYS:" (without the 
quotes).


GatewayName     "Text"
-----------------------
This variable tells Connect2SMTP what its gateway name is 
under MHS.  Connect2SMTP uses this value to determine where 
MHS will put outbound messages, and also uses it to build the 
return address for outgoing SMTP mail.  It should contain the 
same name that you used when you added the gateway name 
under MHS or Connect2.


DefaultMhsHub   "Text"
----------------------
This variable controls what happens to inbound SMTP mail that 
does not specify the destination MHS hub.  If this variable is 
omitted or left blank, Connect2SMTP sends the message to the 
hub name defined as the "workgroup" under MHS.

If a value is given for this variable, the message is sent to the 
host name specified.  This variable is not normally given a value 
since the workgroup name of the local MHS hub is normally 
where an inbound SMTP message should be sent if the MHS 
hub wasn't specified.  But its provided as an option in case a 
different host or workgroup name should be used.


DefaultSmtpHost "Text"
----------------------
Send to this SMTP host if host name is not given.

Using this variable is optional and is useful if a large percentage 
of outbound SMTP mail goes to a certain SMTP host.  If an 
MHS user sends a message through Connect2SMTP without 
specifying a destination SMTP host, the message will be 
addressed to the host specified by this variable.  If this variable 
isn't set and a MHS message is launched without specifying the 
destination SMTP host, it will almost certainly be returned with 
a delivery error.

For example, if this variable is set to "acme1.com" and 
Connect2SMTP's MHS gateway name is "SMTP", an MHS user 
can send a message to "joe@acme1.com" by simply addressing 
it to "joe@smtp".

(If only the SMTP host name is specified by an outbound MHS 
message, then the [M2TCP] domain name is automatically 
appended.)


UserNameSuffix  "Text"
----------------------
This is an optional variable that is NOT normally used.  This 
field may be used to insert additional text in the reply address of 
outgoing SMTP mail, between the user's name and the 
HostName.

Normally Connect2SMTP builds reply addresses of outgoing 
SMTP messages using a syntax of "user%mhshub@HostName".  
If a value is given for this variable, the text is inserted 
between %mhshub and @HostName.

You may consider using this option when you can't get 
Connect2SMTP's TCP/IP host name registered with a name 
server, but there's a UNIX host willing to accept and forward 
mail to Connect2SMTP.  The technique for doing this is 
described in a section called "Hiding Connect2SMTP Behind 
Another UNIX Box" in the "Technical Reference" section of  
this manual.

This only time this variable is used is when building the reply 
address for an outbound SMTP message.


ScanFrequency   Minutes
-----------------------
This variable controls how often Connect2SMTP scans for new 
MHS mail in seconds.  Connect2SMTP is very efficient about 
doing this.  A value between 10 and 20 seconds is negligible in 
the amount of network traffic generated.


ErrorsToAdmin   Yes | No  (Default=Yes)
---------------------------------------  
This option tells Connect2SMTP whether or not to send the 
MHS administrator copies of various errors (such as routing or 
non-delivery) as a message.


AdminName       "Text"
----------------------
This variable overrides Connect2SMTP's automatic 
determination of the MHS administrator.  Normally 
Connect2SMTP will determine who the MHS administrator is 
by reading the MHS NETDIR.TAB file.  It can sometimes be 
convenient to override where Connect2SMTP's error messages 
go if a different person administers Connect2SMTP.

The value entered should be a fully qualified name expressed in 
native MHS syntax (i.e. AdminName=joe@mhs1).


LocalDelivery   Yes | No  (Default=No)
--------------------------------------
Enable local delivery to MHS recipients if there is not an active 
MHS router running on the network.  

When in this mode, C2SMTP scans the MV\MHS\MAIL\SND 
directory instead of its gateway directory, and considers 
anything found to be for an SMTP user.  Anything received by 
SMTP is locally delivered directly to the user's MHS inbox.

If this mode is enabled, your e-mail front end must do its own 
delivery of mail directly between local users.


StaticReplyAddress      Yes | No  (Default=No)
----------------------------------------------
This option controls the format of reply addresses built for 
MHS users from inbound SMTP mail.  With this option off, the 
MHS reply address for inbound SMTP mail is built using a 
combination of the first eight characters of the SMTP user's 
name @ C2SMTP's gateway name (plus the SMTP address in 
the MHS extended address), which is the conventional way to 
address mail through a gateway.

This option builds an alternate form of the reply address, which 
is typically only used with Basic MHS.  For example:

GatewayName@HubName{smtp_address}


Note:  If NativeSmtpSyntax is enabled, this option has no 
       effect.


BasicMhs        Yes | No  (Default=No)
---------------------------------------
Set to Yes if running with NetWare 3.12's Basic MHS.  

When this statement is used, the directory structure that 
C2SMTP scans for outbound SMTP mail is adjusted to that of a 
regular user account (instead of the normal gateway account), 
whose name is defined in the Gateway Name variable.  
C2SMTP subsequently does an automatic lookup of the user's 
preferred application in NETDIR.TAB in order to build the full 
scan path for outbound SMTP mail.

When BasicMhs=Yes, StaticReplyAddress is also forced to 
Yes.  This option must be set to ensure that the reply address is 
built correctly for Basic MHS users.


HubDelimiter    "%", "."
------------------------
This variable controls whether the return address for outbound 
SMTP mail is built using a percent ("%") character as the MHS 
workgroup delimiter, or whether the old-style period is used.

This option controls how the reply address of an outbound 
SMTP message is built.  For inbound messages, Connect2SMTP 
will always respond to the percent sign as an MHS workgroup 
separator, or if a percent sign isn't found, the first period 
encountered is considered the end of the user name and the start 
of the MHS workgroup.  Subsequent periods are then 
considered to be periods.  If "ExcludeHubName" or "Inverse 
Hub Syntax" is enabled, this option has no effect.  


InverseHubSyntax        Yes | No  (Default=No)
----------------------------------------------
When enabled, reverses the syntax of how the MHS hub name 
is expressed in SMTP addresses.  Instead of a SMTP user 
sending mail to an MHS user like:

john%mhs1@myhost.com

the MHS hub name of "%mhs1" is moved to the right of the 
"@" sign and expressed as:

john@mhs1.myhost.com

When using this option, the "HostName" in the C2SMTP.INI 
file is then set to the domain name (in this case "myhost.com").

To use this option, each possible domain variation for all of the 
MHS hubs from which Connect2SMTP receives mail will have 
to be registered with the domain name server as a separate 
name, but all would have the same IP address (Connect2SMTP).  
For example:

134.23.2.1  mhs1.myhost.com
134.23.2.1  mhs2.myhost.com

Or, a wildcard MX record would be registered with the domain 
name server for myhost.com.


NativeSmtpSyntax        Yes | No | Both  (Default=No)
------------------------------------------------------
Enabling this option usually means you are running NetWare 
Global MHS or Connect2 and have Connect2SMTP configured 
as a gateway that supports additional SMTP address formats.

When enabled, NativeSmtpSyntax significantly alters 
Connect2SMTP's addressing behavior.  For a detailed 
explanation refer to the "Addressing" section of this manual.


AlwaysGenRetRcpt        Yes | No  (Default=No)
----------------------------------------------
This option controls whether all received SMTP messages will 
request a return receipt when the MHS user reads the message 
(not normally used).

Other options for requesting return receipts are described in the 
"Technical Reference" section.


UseMhsRetRcpt   Yes | No  (Default=No)
--------------------------------------
Act on MHS return receipts.  This option controls whether 
Connect2SMTP evaluates if an outbound MHS message has a 
return receipt requested.  If this option is enabled and an MHS 
message requests a return receipt, a "Return-Receipt-To:" field 
is inserted in the SMTP header, which will produce a delivery 
notification from the SMTP mailer (versus a time-of-reading 
notification).  If most MHS users on your system default to 
having return receipts enabled, it may not be desirable to have 
this option enabled.


UseTotalFields  Yes | No  (Default=No)
---------------------------------------
When this setting is enabled, Connect2SMTP recognizes the 
"Total-to" and "Total-copies-to" fields when processing 
outbound MHS Mail, and uses their values in place of the 
normal "To" and "Copies-to" fields.  This seems to be most 
useful with DaVinci eMAIL.


UseSenderAsFrom Yes | No  (Default=No)
--------------------------------------
Use MHS "Sender:" field as SMTP "From:" field.

Normally, Connect2SMTP uses the MHS "From" field to 
generate the SMTP "From" field.  However, this can cause 
some confusion with the way some MHS applications, 
especially Notework, generate message replies or forwarded 
messages.  Set this value to "Yes" if SMTP recipients complain 
about "From" addresses not appearing correctly on mail that 
you send.


UseReplytoAsFrom        Yes|No  (Default=No)
---------------------------------------------
When processing an inbound SMTP message, this option tells 
Connect2SMTP to use the SMTP Reply-To: field for the MHS 
message's From: field.  Prior to MHS 1.5, the SMF language did 
not provide for a Reply-To: field, which allows message replies 
to go to a different address than the message sender.

If your MHS e-mail application does not recognize the MHS 
Reply-To: field, turning this option on is one way to fix the 
problem.  This option is not normally enabled if your MHS e-
mail application was written for SMF-70 (MHS 1.5) or greater.


ExcludeHubName  Yes | No  (Default=No)
--------------------------------------
This option controls whether the reply address built for 
outbound SMTP messages will include the name of the sender's 
MHS workgroup.

If there's only one MHS hub for which Connect2SMTP will 
receive mail, or if MHS is configured as a multi-host 
workgroup, you may want to exclude the sender's MHS 
workgroup name from the reply address of outbound SMTP 
messages, since replying to the MHS user at the default 
workgroup will work fine.

For example; if the MHS workgroup name is "mhs1" and 
Connect2SMTP's HostName is "c2gate.acme.com", and this 
option is disabled, the reply address will look like this:

user%mhs1@c2gate.acme.com

If this option is enabled, reply addresses will look like this:

user@c2gate.acme.com

Enabling this option might reduce some confusion if you want 
to tell SMTP users that your MHS users are addressed as 
user@HostName instead of user%mhshub@HostName, since 
they then won't get messages with a reply address that looks 
different.

Important:
This option should not be enabled if Connect2SMTP will handle 
any outbound MHS message that can't be replied to by using the 
sender's name at the default MHS workgroup.  (This might be 
the case if Connect2SMTP handles mail that originates from 
another gateway on your MHS hub.)  If Connect2SMTP will 
route mail to users on multiple MHS hubs and you don't use a 
workgroup-wide router, do not enable this option!


ExcludeHostName Yes | No  (Default=No)
--------------------------------------
This option controls whether the reply address built for 
outbound SMTP messages will include the TCP/IP hostname.  
(Provided InverseHubSyntax is disabled.  If InverseHubSyntax 
is enabled, this option has no effect.)


IncludeAppName  Yes | No  (Default=No)
--------------------------------------
This option controls whether Connect2SMTP includes the MHS 
application name in the reply address when building an 
outbound SMTP message (if it was given in the MHS message).

This option is not normally enabled because MHS "manages" e-
mail applications.  Which means that MHS will automatically 
route inbound messages to the user's primary e-mail application 
when its not explicitly specified.

Regardless of whether this option is enabled, Connect2SMTP 
always reacts to an MHS application name if its embedded in 
the address of an inbound SMTP message (inside square 
brackets).

This option is provided in the event that you have MHS users 
that use more than one e-mail application, and embedding the 
application name in their reply address is the only way to assure 
that replies will come back to the right e-mail application.


InsertSmtpHeader        (See Below)
-----------------------------------
"StartofBody" - The SMTP header is written at the start of the 
		MHS body.

"InMhsHeader" - SMTP header is encapsulated in the MHS 
		header.

"EndOfBody"   - The SMTP header is written at the end of the 
		MHS message body.

(blank)       - The SMTP header is discarded.

This variable controls whether Connect2SMTP includes the 
header of received SMTP messages either at the start of the 
MHS body, or encapsulated in the MHS header.

Using the "InMhsHeader" option is useful only if your MHS e-
mail application provides a function that allows the header of 
inbound mail to be viewed as it was received.

ShowSmtpFields  (See Below)
---------------------------
Options are:

"To:"
"From:"
"Cc:"
"Reply-to:"

This variable allows some of the fields in a received SMTP 
message to be written into the beginning of the body text in a 
MHS message.  Sometimes these fields can provide valuable 
information to the MHS user which might otherwise be hidden 
depending on the particular MHS e-mail software in use.  For 
instance, if a message had multiple recipients (specified by the 
SMTP To: header field), but the MHS e-mail software displays 
the MHS "Send-To:" field instead, the MHS recipient won't see 
the complete list of recipients.


ConvertTimeToLocal      Yes | No  (Default=No)
-----------------------------------------------
This option controls whether Connect2SMTP will convert the 
date/time stamp of inbound SMTP mail to local time.  
Sometimes this is desirable for several reasons:

1. If your MHS e-mail application displays messages received 
   sorted by the date stamp, messages received from SMTP 
   that were sent at an earlier hour won't show at the top of the 
   box where you would expect to see a new message.
 
2. You might want the date and time of all messages in your 
   inbox to be based on local time (since there's usually 
   nothing that indicates that the time of the message is not 
   local).

In order for this feature to work right, the "TimeZone" has to 
be set correctly.


IgnoreLwspAfterFold     Yes | No  (Default=No)
----------------------------------------------
This option controls whether Connect2SMTP considers linear 
white space characters (LWSP) after a folded header field in an 
MHS message as significant.

This option is not normally enabled.  The WordPerfect Office 
MHS gateway is the only known application to need it.

Note: According to the SMF-70 and 71 Programmer's 
      References, folded lines are only permissible where LWSP 
      characters are allowed (i.e. not in the middle of an SMTP 
      address, unless there actually is a space in the SMTP address).  
      Normally, any application that processes an MHS message and 
      encounters a folded line is to assume that LWSP characters 
      starting the continuation line are logically equivalent to a space 
      character if they occur in the middle of an active address.  
      Enabling this option, disables this logic and any LWSP 
      characters beginning a folded line are discarded.

Normally, this option is disabled.  If you occasionally see an 
outbound MHS message produce a space character in the 
middle of the resulting SMTP message's To: or From: fields that 
wasn't entered that way inadvertently by the sender, you may 
need to turn this option on.


XlateIllegalChars       Yes | No  (Default=Yes)
------------------------------------------------
This option controls whether Connect2SMTP will translate 
illegal (by MHS SMF-70 standard) characters in an address to 
the "$" character when going from SMTP to MHS.

This option is useful if you are running Connect2 and have any 
users defined whose names include an illegal character, 
especially the underscore "_" character.


MIME    Yes | No | IfNeeded  (Default=No)
-----------------------------------------
This option controls the outbound portion of whether 
Connect2SMTP will automatically use MIME formatting for 
outbound MHS messages that need encoding.  Encoding is 
needed if an MHS message body contains 8-bit characters, or 
has binary file attachments.  MIME messages received are 
always decoded regardless of this setting.

When set to IfNeeded, MIME headers will only be placed in the 
message if some type of MIME encoding had to be performed. 
(e.g. 8-bit body text in the message or binary file attachments).  

When this option is enabled, it takes precedence over the 
Uuencode setting below for outbound mail.


Uuencode        Yes | No  (Default=Yes)
----------------------------------------
This option controls whether Connect2SMTP will automatically 
uuencode files attached to outbound MHS messages, and 
whether Connect2SMTP will scan each SMTP message received 
for uuencoded attachments.


DecodeTrigger   "Text"
----------------------
This variable will help trigger automatic uudecoding of encoded 
MHS file attachments when they reach a remote SMTP user.  
Many SMTP user agents don't automatically scan for uuencode 
blocks unless they see a header field in the SMTP message 
indicating a block of uuencode text.

When one or more of these variables are defined in 
C2SMTP.INI, Connect2SMTP will automatically insert all of 
them in the header of the SMTP message when it uuencodes a 
MHS file attachment.

To determine if this variable can help, and what text to use, 
examine the header generated by the SMTP user agent in 
question when it sends a uuencoded file attachment.

If the filename of the attached file is needed in the SMTP 
header, embedding a %FN in the variable's definition will 
expand into the real-time name of the file(s) when the message 
is built.

For example:

DecodeTrigger=Next-Attachment: %fn
DecodeTrigger =Content-Type: x-uuencode-apple-single

The first example is designed to trigger automatic decoding on 
NEXT computers, and the second for Apple computers running 
Microsoft Mail.  Some testing may be necessary to determine 
what values may be used to trigger a remote SMTP user agent 
into automatically decoding a uuencoded block.


DiscardAttachName       "Text"
------------------------------
This variable enables certain MHS file attachments to be 
ignored when an MHS message passes through Connect2SMTP   
This is useful with some MHS e-mail applications that add an 
attachment containing formatting information (such as Beyond 
Mail's Windows product) which has no value if sent to an 
SMTP user.  This variable can be defined more than once.  For 
example:

DiscardAttachName=*BEYOND*
AppendAttachIfAscii     Kilobytes
This variable tells Connect2SMTP whether to automatically 
append MHS file attachments onto the end of the outbound 
SMTP message body, when the attachment only contains ASCII 
text characters.

It has the following format:

AppendAttachIfAscii =nn

Where "nn" is the maximum size of an attached file (in K) that 
will be considered for appending.

Note: This option does not apply when MIME encoding is 
      being used.


MoveBodyToAttach        Kilobytes
---------------------------------
This variable is used to protect an MHS e-mail application from 
receiving a SMTP message with body text larger than it can 
handle.

For instance, Beyond Mail for Windows has a body text 
limitation of 32,000 bytes.  If an SMTP user sends a message to 
the Beyond user that has a body larger than 32K, Beyond Mail 
will truncate the message at 32K.

Setting this variable to a non-zero value causes Connect2SMTP 
to check the size of the SMTP body, and move the body to a file 
attachment if it exceeds the value.  (When the body is moved, a 
small notice is written into the body text indicating this 
condition occurred.)

The value given is in K (1000, not 1024).  If set to zero or 
undefined, this feature is not enabled.


PostDirectory   Snd | Gateway  (Default=Gateway) 
------------------------------------------------
This option specifies where Connect2SMTP submits inbound 
messages from SMTP to MHS recipients.

Gateway - Messages are submitted to the 
MV\MHS\Mail\Gates\Gateway Name\In directory

Snd - Messages are submitted to the MV\MHS\MAIL\SND 
directory.  (This may cause problems for sender validation in 
NGMHS or Connect2)


InboundLog      Path name
-------------------------
Full path to inbound log file.  If this variable contains a value, a 
complete path and filename must be used.  Connect2SMTP will 
then write a single-line entry in the file specified for each 
inbound SMTP message received.  If the path points to a server 
volume (i.e. SYS:Connect2SMTP\INBOUND.LOG), make sure 
the user name Connect2SMTP is logged in with has sufficient 
disk privileges.


OutboundLog     Path name
-------------------------
Full path to outbound log file.  Specify a complete path and 
filename if you would like Connect2SMTP to write a single-line 
entry for each outbound SMTP message received.  If the path 
points to a server volume (i.e. SYS: SMTP\INBOUND.LOG), 
the user name under which Connect2SMTP is logged must have 
sufficient disk privileges.


UseCSVLogFiles  Yes | No  (Default=No)
--------------------------------------
Tells Connect2SMTP to write comma-separated log files so 
parsing by an external program is possible.


Scrollback      Kilobytes
-------------------------
This variable controls how much conventional memory is 
allocated by the MHS module for its scroll back buffer.

For more information refer to "Scrollback" parameter in the 
SMTP section.


SpaceInUserName [".","_","+"]
-----------------------------
MHS long names containing spaces can now be translated to 
another character in the resulting SMTP return address, and vice 
versa when receiving SMTP mail that contains that character.

This option is useful if you want to use long names, but don't 
want to take chances with space characters staying intact across 
SMTP transport.  For instance, the Connect2 message router can 
route mail to a user based on the user's full name, so if this 
option were set to a ".", a user with a full name of "Joe Smith" 
could be addressed from SMTP as Joe.Smith@acme.com.  This 
would apply to NGMHS long names as well.

SmfCharSet
SmtpCharSet
CharSetTable
See the Appendix entitled "Character Set Translations" for a 
description of this parameter.

	

[SMTP] Section

RelayFirst      Yes | No (Default=Yes)
--------------------------------------
Send to relay host(s) first.  If both the relay host is defined and 
name servers are given, this variable controls whether 
Connect2SMTP first attempts to connect to the relay host, or 
directly to the destination host using the name servers (when 
processing outbound mail).

Possible settings are:

Yes     Attempt to pass all messages to the relay host 
	first.  If the relay host isn't available and name 
	servers have been defined, Connect2SMTP will 
	then attempt direct delivery to the remote host.
No      Attempt direct delivery first using the list of 
	domain name servers.  If the host name can't be 
	resolved or if Connect2SMTP can't connect to the 
	host, pass the message to the relay host (if 
	defined).


NameServer      <IP Address>
----------------------------
This statement identifies a name server.  The value must be 
given as a numeric IP address.  In order for Connect2SMTP to 
do direct delivery, at least one name server must be specified so 
destination host names can be resolved to numeric IP 
Addresses.

Connect2SMTP can also utilize a file-based host table (called 
HOSTS in Connect2SMTP's home directory), but it's provided 
mainly for serving short-cut names to local hosts (if they are 
configured to query Connect2SMTP as a name server).  The 
purpose of Connect2SMTP's HOSTS file isn't to resolve all of 
the possible host names that outbound SMTP mail might need 
to resolve.  If all hosts were defined in the hosts file, the impact 
on Connect2SMTP's working memory would probably inhibit 
Connect2SMTP from loading.

When Connect2SMTP queries a name server, it also recurses 
through any additional name servers returned by the query if no 
answer was provided, and if no error was indicated.  In most 
situations you should set the first name server to a high-level 
name server, which will quickly reply with the authoritative 
name server for a particular query, which is then sub-queried 
and returns the answer desired.  Specifying at least one 
additional name server in case the first name server fails to 
respond is usually a good idea.

This statement can be given more than once, up to a maximum 
of 10 times.


RelayHost       <IP Address>
----------------------------
This is the numeric IP address of the relay host.  If the relay 
host isn't specified, at least one name server must be given.

Whether the relay host is used first, or direct delivery to the 
recipient's host, is controlled by the "RelayFirst" variable.

This variable can be given more than once, up to a maximum of 
10 times.


AcceptRemoteMail        Yes | No  (Default=No)
----------------------------------------------
This statement controls whether Connect2SMTP will accept 
mail for recipients that are not part of its primary or alternate 
domain names (defined by the Domain and AltDomain 
statements in the [M2TCP] section).

When this option is enabled, Connect2SMTP can be used as a 
relay host for other SMTP mail systems.  In this case, instead of 
responding with a "550 Mail for remote hosts not accepted",  
Connect2SMTP responds with a "250 Ok (will forward)" 
response, flags the message recipient as being destined for a 
remote SMTP host (the message could still possibly have local 
recipients), and the session continues.  When the MHS module 
subsequently scans the SMTP inbound queue during the next 
cycle and begins to process the inbound SMTP message, if the 
remote host flag is set a copy of the message is then moved to 
the SMTP outbound queue using the same routine that handles 
FORWARDed recipients, and delivery to the remote SMTP 
recipient then continues.

All delivery features that are used for MHS mail are also used 
for forwarded mail, including error and adivisory messages (i.e. 
the 4 hour delivery problem report, etc.).

Note:   Names defined in the FORWARD file can be used to redirect a 
	message that was accepted for delivery to a remote host.

Possible settings are:

Yes     Accept (and will forward) mail for recipients that 
	are not under our domain(s).
No      Do not accept mail for recipients that are not in 
	our domain(s).


MaxOutbound     Sessions
------------------------
This variable limits the maximum number of originate 
(transmit) processes that Connect2SMTP will start concurrently.

Even though the SMTP Server is technically capable of 
supporting 100 concurrent SMTP sessions (memory providing), 
this is usually much more than most sites are technically 
capable of supporting for other reasons.  For instance, if your 
link to the Internet is over a V.32 or V.34 connection, than 
bandwidth alone will limit the number of outbound sessions that 
can be sucessfully sustained concurrently, and this value should 
then be set to a value of around five sessions.

If your link with the Internet (or other local subnets that you 
frequently exchange mail with) is a T1 or higher, than the 
number of concurrent outbound sessions possible is 
considerably higher and you might want to raise this value to 
something like 50 or so.

If you raise this value above 40 and you're using a NetWare 
network, then a corresponding change is needed in your 
NET.CFG to increase NetWare's default number of file handles 
to that value plus one.

If you're not running Connect2SMTP in protected mode, it may 
be difficult to successfully sustain more than five concurrent 
connections due to available memory.

Normally a value of 20 is more than adequate for a high 
bandwidth connection.


RescheduleMinutes       Minutes
-------------------------------
This statement overrides the default re-schedule interval for 
outbound SMTP mail delivery.  If a message fails to deliver, the 
delivery will not be attempted again until this interval expires.

The default value is 1 minute.


DomainTimeout   Seconds
-----------------------
After sending a query to a name server to resolve a host name, 
this is the number of seconds that Connect2SMTP waits for a 
response before advancing to the next name server, or timing 
out if no more name servers are left to query.  When multiple 
name servers are given, a late response from a query to a 
previous name server is still recognized.


ConnectTimeout  Seconds
-----------------------
This is the time Connect2SMTP will wait in seconds after 
initiating a connection, before considering the connection 
attempt failed for lack of response.


Inactivity Timeout      Minutes
-------------------------------
When a connection is inactive for this many minutes (default is 
5) the connection will automatically be closed.


UndeliverableTimeout    Hours
-----------------------------
This variable tells Connect2SMTP how long to continue trying 
to send a message that it can't deliver before returning it to the 
sender as undeliverable.

If this variable is set higher than 24 hours (recommended 
because some systems go down over weekends), Connect2SMTP 
will send an error status message back to the sender after the 
first 4 hours, and subsequently after each 24 hour period that a 
message is undeliverable.

If a relay host is defined, this time out will never be encountered 
since Connect2SMTP will subsequently pass a message that 
fails direct delivery to the relay host.


ResolveTimeout  Hours
---------------------
This variable tells Connect2SMTP how long to continue trying 
to deliver a message when its host name can't be resolved using 
the name servers defined.

Set this value to at least twice the value of "RescheduleMinutes" 
so that your name servers will have at least two attempts to 
resolve the destination host.  Sometimes a caching name server 
won't know a host name when queried the first time, but will 
subsequently issue a recursive query back up its chain, and in 
the meantime Connect2SMTP has advanced to the next name 
server in the list, all of which may time out the first time.  On a 
second attempt, one of the caching name servers might have 
gotten a response back and be able to resolve the name.

When this time out expires, the message is returned to the 
sender with an error that the host is unknown.

If a relay host is defined, chances are this time out will never be 
encountered since Connect2SMTP will subsequently pass a 
message that fails direct delivery to the relay host.


1stOpeningRemark        "Text"
------------------------------
The opening text which Connect2SMTP uses when it 
handshakes with other mailers may be modified by setting this 
variable.


2ndOpeningRemark        "Text"
------------------------------
The second remark which Connect2SMTP uses when it 
handshakes with other mailers may be modified by setting this 
variable.


SendMailRemark  "Text"
----------------------
Set this variable to modify the remark sent when a session has 
been established and Connect2SMTP is ready to receive data.


ClosingRemark   "Text"
----------------------
Set this variable to change the remark sent when a connection is 
about to be closed.


Scrollback      Bytes
---------------------
This variable controls how much conventional memory can be 
allocated for the SMTP Monitor scroll back buffer.


[M2TCP] Section
===============

HostName        "Text"
----------------------
This variable should be set to just the machine name (without 
the domain name) that has been assigned to Connect2SMTP.

Connect2SMTP may use this value, plus the domain name, to 
build the reply address for outgoing SMTP mail.  The SMTP 
server always uses this value (plus the Domain name) during its 
mail dialog when exchanging mail with other SMTP hosts.

Whether Connect2SMTP uses the hostname in reply addresses 
(or just the domain name) is controlled by the values of  
InverseHubSyntax and ExcludeHostName in the [MHS] 
section.  Refer to those options for more information.

This value can be left empty if so desired.


Domain  "Text"
--------------
This variable should be set to your TCP/IP domain name 
(without the machine name).  This value, plus the value of 
Hostname (above), determines what Connect2SMTP uses for 
the SMTP return address, and also what it uses for its full host 
name when exchanging mail during SMTP connections.

This value also determines what Connect2SMTP assumes is the 
domain name when handling mail that does not qualify the 
domain.


AltDomain       "Text"
----------------------
This statement declares an additional TCP/IP domain name that 
Connect2SMTP will accept mail for.

More than one alternate domain can be given by repeating this 
statement (but is limited to a maximum combined total of 256 
bytes for all alternate domains).

This statement allows you to change your mail domain and still 
receive mail for either one.  Mail received for either the primary 
Domain, or an AltDomain, is considered destined for an MHS 
user.


Ping    <IP Address> [#]
-------------------------
This allows a host to be Pinged on a recurring basis.  This is 
useful if your Internet access is via a dial-up link that 
disconnects after a period of inactivity, and you want something 
to generate recurring traffic through the link so that the 
inactivity timeout won't occur.

The format of the ping command is:

ping <ipaddress> [minutes]

The <ipaddress> is the host you want to ping (which should be 
on the other side of the router you want to keep awake).

Minutes is an optional number of minutes in between pings 
generated.  If it isn't given, a value of 1 is assumed.  Ping 
activity generated by this option won't show in the SMTP 
Monitor unless Connect2SMTP is started with the -I (verbose 
ICMP) command line switch.  Only one PING command can be 
active in C2SMTP.INI.


Bind    <IP Address>, <Net Mask> [,intf[,bcast]]
------------------------------------------------
This variable tells Connect2SMTP what its own IP address is.  
Although this is not common, Connect2SMTP can support more 
than one interface (network card) by using multiple bind 
commands.

IP addresses are bound logically inside Connect2SMTP 
(actually in the Mach2 TCP/IP protocol stack) to an ODI driver.  
As mentioned, more than one bind statement can be used to 
support multiple IP addresses and/or interfaces, but such usage 
is rare.  At least one bind statement must be present in 
C2SMTP.INI.

<ipaddress> - the local IP address being bound to a particular 
interface board (which will be Connect2SMTP's local IP 
address).

<netmask> - the portion of the IP address that represents the 
network part (which is what Connect2SMTP uses to determine 
when a packet is destined to a remote network and has to be 
routed).  For instance, the netmask of a class C subnet would be 
255.255.255.0.  Both the <ipaddress> and <netmask> 
parameters are expressed as fully qualified IP addresses in 
dotted notation.

<interface> - an optional parameter that explicitly tells 
Connect2SMTP which network interface (card) to bind the IP 
address to.  In most cases this can be left out or set to zero and 
Connect2SMTP will automatically bind correctly to the next 
available interface driver that supports a TCP/IP frame type.  
Specifying which interface is needed if more than one network 
card is present, or more than one frame type is present that 
supports TCP/IP.

When specifying an explicit interface, the number can be 
expressed in either decimal or hex (hex values are given in C 
format by prefixing the number with a "0x").

If the interface number is a value between 1 and 16 (decimal), it 
is considered to be a reference to a logical MLID "board ID" 
number that was bound to a suitable frame type in NET.CFG 
(usually ETHERNET_II).  An MLID is a card-specific ODI 
driver.

<bcast> - an optional parameter that overrides the normal use 
of 1's for broadcast bits in the host portion of an IP Address.  If 
<bcast> is given, it can only be a value of 0 or 1.

The text string "NOETHER" flag may be appended to a Bind= 
statement to tell Mach2 that the interface is really not Ethernet.

This may be necessary for some packet drivers that present a 
Class 1 interface but are not using an Ethernet media (e.g. 
ISDN).  When this flag is given, the principal effect is that 
Mach2 will not try to ARP on the interface, instead it will 
simply launch the IP packet.

Note:  You can verify this flag is active by viewing the Tables 
       screen under the M2TCP console.  The "Address" field under 
       the Interface table will indicate "NONE".


Route   <Network>, <Next hop>[,Metric]
--------------------------------------
Route commands are used to initially seed the routing table with 
static routes.

The format of a route statement is:

route <network>, <NextHop> [,metric]

The first form adds a static route.  Up to 10 static routes can be 
given by using multiple route statements.

A <network> given as all zeros is the equivalent of a default 
route (i.e. everything not destined for the local network 
qualifies, and those packets are then send to the <NextHop>).

When more than one IP address is bound, Connect2SMTP will 
automatically make the correct association of which interface 
they route through.

If the <metric> isn't specified, it is assumed to be 1.  The metric 
is used as a means to prioritize routes when more than one 
qualifies.  A default route is always assigned an internal metric 
of 17 (which is higher than the normal metrics of 1...15) 
because default routes are only supposed to be used if no other 
route qualifies.

Both the <network> and <NextHop> parameters are expressed 
as fully qualified IP addresses in dotted notation.  Normally, all 
that is needed is a single route command that specifies a default 
route to the default gateway.

For example:

route 0.0.0.0, 130.23.4.1


EnableRIP       Yes | No  (Default=No)
--------------------------------------
When RIP is enabled, a broadcast query for RIP information is 
sent on all interfaces immediately upon startup.

Normally the use of RIP is overkill (unless Connect2SMTP has 
more than one network interface), because all non-local packets 
will probably end up just needing to go to a default router 
(gateway), and using one simple static route to the default router 
will work just fine.  If you enable RIP, and do not also specify a 
static route to the default gateway,  Connect2SMTP may not be 
able to talk to all networks if the default gateway doesn't 
advertise itself through RIP as the default route for your 
network.  The routing table can be examined from under the 
SMTP Monitor's "<D>river, <T>ables" command.


IPForward       Yes | No  (Default=No)
--------------------------------------
The Mach2 TCP/IP protocol stack built into Connect2SMTP has 
the ability to forward (route) packets between multiple 
interfaces.  If you have more than one interface card installed, or 
you are using Mach2 to acess an Internet Service Provider 
through a SLIP or PPP interface, and you want Mach2 to route 
packets between these interfaces, enable this option.


BufferSize      Bytes
---------------------
This value overrides the total buffer size that Mach2 allocates 
for sending and receiving IP packets.

The default is 10,240 bytes.

The total buffer space is allocated internally in units of 128 
bytes.  So any value given for BufferSize is always rounded up 
to the nearest multiple of 128.  For example, the default size of 
10,240 bytes produces 80 buffers (80 x 128 = 10240).

This value indirectly controls the number of ECB's that Mach2 
allocates, which is calculated by dividing the number of  128 
byte buffers in half.  (So a BufferSize of 20480 bytes results in 
160 Buffers and 80 ECB's [20480/128=160]).

If you are using Mach2 as a router, you should raise the 
BufferSize to a value of 20480 or higher.

(SLIP or PPP interfaces also use this buffer for asynchronous 
serial I/O.)


WindowSize      Bytes
----------------------
This value, minus any unread application data (which is 
normally zero because SMTP reads data asynchronously when 
received), is the Window size stamped in the TCP header of 
outgoing packets.

This value basically tells the peer TCP connection how much 
data it can send that has not been acknowledged (i.e. the 
"window" portion of the sliding window protocol).

The default value is 4096 bytes.

If the majority of your connections are with local hosts over a 
fast local network (i.e. Ethernet), raising this number will 
enhance performance somewhat (e.g. 10240, 20480, ...).

If the majority of your connections are with remote hosts that 
traverse a slower link (i.e. SLIP or PPP), and you frequently 
experience situations where there are more than 3 or 4 of these 
connections simultaneously, its better to keep this value small 
(e.g. at the default or lower).


MaxWindow=      Bytes
---------------------
This value sets the ceiling for Window sizes advertised by a 
peer TCP connection.

As explained previously under WindowSize, a TCP Window is 
the amount of unacknowledged data that the peer says we can 
send.  Unacknowledged sent data ties up buffer space because it 
has to be resent if the peer does not ACK the data before the 
roundtrip timeout expires.  So if we connect to a host that gives 
a Window of 20,000 bytes, and we only have a 20,000 byte 
buffer, we don't want to use the full window advertised or one 
connection's sent data will consume the entire buffer, leaving 
no space for sending unacknowledged data on other concurrent 
connections, or to received data with.

If this statement isn't given, Mach2 uses half the BufferSize for 
the maximum window.

In general, if you change MaxWindow, it should be to a value 
that is lower than half the BufferSize.  And, you would 
normally do so only if you frequently have situations where 
you're sending to three or more hosts simultaneously.  For 
instance, if you frequently have five or more concurrent 
outbound connections with remote hosts over a slower link, 
you'd probably want to limit the maximum send Window to a 
value of 2048 bytes, so that no single host that happens to 
advertise a large Window could cause Mach2 to use a good 
portion (if not all) of our buffer space available, just on one 
host.

This statement overrides the MaxWindow for all Ethernet 
interfaces.  SLIP or PPP interfaces can set their own unique 
MaxWindow using the same statement under their interface 
definition.  If not specified, a SLIP or PPP interface then uses 
the value determined by this setting.


TimeToLive      Hops
--------------------
TTL (hops) stamped in outbound IP headers.


Slip    "Section_name"
----------------------
Defines a SLIP interface.  The value entered must refer to a 
valid [section] that then defines the interface.

For more information refer to the "Asynchronous SLIP and PPP 
Driver Support" section of this manual.


PPP     "Section_name"
----------------------
Defines a PPP interface.  The value entered must refer to a valid 
[section] that then defines the interface.

For more information refer to the "Asynchronous SLIP and PPP 
Driver Support" section of this manual.


SerialDevice    "Section_name"
------------------------------
Allocates a serial device, such as COM1 or REMOTE.

The value entered must refer to a valid [section] that then 
defines the serial device.  For more information refer to the 
"Asynchronous SLIP and PPP Driver Support" section of this 
manual.

  

Technical Reference
===================
The goal of this Technical Reference is to cover the complex 
features of Connect2SMTP and provide a more detailed 
explanation of many concepts, components and functions.

Memory Utilization
The performance of Connect2SMTP may be enhanced by using 
extended or expanded (LIM/EMS 4.0 recommended) memory.  
Loading as many network drivers as possible into upper 
memory is recommended.  Connect2SMTP will automatically 
recognize and use UMB memory (upper memory blocks 
between the 640K and 1 Meg boundary) either through MS-
DOS API calls, or through an XMS driver (like HIMEM.SYS 
when used with EMM386.EXE, or QEMM from Quarterdeck).

Connect2SMTP also automatically recognizes and uses EMS 
(expanded) memory when present (if version 4.0 or higher) for 
some of its event-based buffering requirements, and also for 
scroll back buffers.  Allocating approximately 256K of 
extended memory as expanded memory should be sufficient.

Protected Mode Support
Connect2SMTP performance can be further improved by 
running in protected mode, where C2SMTP has direct access to 
all extended memory, without the DOS 640KB limitation.

Support for protected mode operation under DPMI has been 
discontinued in favor of VCPI.  DPMI would not work reliably 
in interrupt-intensive environments (i.e. when we're driving one 
or more high-speed modems through a SLIP or PPP interface), 
and often wouldn't work correctly in high-load situations with 
Ethernet.

Connect2SMTP does not use the VCPI API to mode switch to 
real-mode in order to call DOS functions (or to call the ODI 
LSL, or a Clarkson Packet Driver, or the VLM) which is 
necessary in order to use these drivers since they can only be 
accessed from the real-mode environment.  Instead, 
Connect2SMTP performs the necessary mode switching itself.  
This gives Connect2SMTP a performance advantage by 
retaining control of the interrupt system from protected mode 
even when real-mode is active, letting it service comm 
interrupts, and the timer tick interrupt (where Connect2SMTP 
does a lot of background processing) directly from protected 
mode 100% of the time.  We can't do this however without 
paying a price in compatibililty.  Some of the not-so-robust 
VCPI implementations won't work with Connect2SMTP (mainly 
the EMM386 variants) - but QEMM v7.0 and v7.5 from 
Quarterdeck will support Connect2SMTP protected mode 
operation in most environments.

To have Connect2SMTP run in protected mode a -P switch must 
be given on the command line.

To run properly in protected mode, please note the following 
known restrictions:

  - Smartdrive should not be loaded on the PC running 
  Connect2SMTP.
  - If using VLM's, VLM.EXE must be loaded in 
    conventional memory by using its /Mc switch.
    QEMM must not be run in stealth mode (ST:M or 
    ST:F parameters should not be used).
  - May not be compatible with a number of remote access 
    programs (i.e LanSight, LanAssist).  Note: LAN Assist 
    will work when it is configured to pass keystrokes 
    through the BIOS interface (LA /B).  It will not work 
    when configured to send scan codes directly.
  - In most cases you cannot use DOS=HIGH.  (In fact, 
    since conventional memory is not as precious when 
    running in protected mode, we recommend not using 
    either DOS=HIGH or DOS=UMB in CONFIG.SYS.  
  - Keep the configuration simple, and don't try loading 
    any programs "high" unless absolutely necessary.)

When running successfully in protected mode, Connect2SMTP 
is between 20 to 30 percent faster, and typically runs completely 
within extended memory, usually leaving over 400K of free 
conventional memory.

Limitations
Connect2SMTP's messaging limitations are related to the 
inherent limitations in MHS.

Message Size
MHS 1.5 (SMF 70) has a limit of 64K and, as well, many MHS 
e-mail applications have a smaller limit, sometimes 32K or less 
for body text.  Connect2SMTP provides an option to convert 
body text to a file attachment in these cases.

Attachments
Connect2SMTP can handle an unlimited number of outgoing 
MHS file attachments and automatically encode them into the 
outgoing SMTP message using either MIME or uuencoding.  It 
can also do the inverse with inbound SMTP messages and 
automatically decode multiple file attachments back into 
separate MHS file attachments.

MHS 1.1 (SMF 64) however, can only handle one file 
attachment per message.  In this case, Connect2SMTP only 
decodes the first file and leaves the rest encoded in the message. 

MHS 1.5 (SMF 70) can handle 64 file attachments, and 
Connect2SMTP will automatically decode and create 
attachments for as many encoded blocks that exist in the 
message body text.

Complex Addressing
User to user addressing is the most common form of addressing.  
However, MHS supports several other types of addressing that 
provide more control and flexibility.

SMTP to MHS Application Addressing
If a user has more than one application name under MHS, the 
MHS application name may be specified by enclosing the 
application name in square brackets (normally this is not 
necessary since MHS will deliver e-mail to the user's default 
application).  For example:

joe[pmail]@c2gate.acme.com

If both the application name and the MHS hub name are given, 
the application name should precede the hub name.  For 
example:

joe[pmail]%mhs1@c2gate.acme.com

SMTP to MHS Gateway Addressing
To allow an SMTP user to send mail to another gateway, such 
as a FAX gateway, on your MHS system, extended addressing 
is used.

The parameters required to deliver the message to the 
appropriate gateway are specified by enclosing them in curly 
braces.  For example:

fax{/FAX:801-555-9600}@c2gate.acme.com

The Default SMTP Host
In Connect2SMTP's configuration file you can define a default 
SMTP host where messages will be sent when Connect2SMTP 
processes a message that doesn't specify the destination SMTP 
host.

For example, if the default SMTP host is set to "kirk.com", and 
an MHS user wanted to send a message to "joe@kirk.com", 
they could simply address the message as:

email @ smtp {joe}

Furthermore, if the extended address is not present at all, 
Connect2SMTP will send the message to the MHS user name at 
the default SMTP host.  Since MHS user names can't exceed 
eight characters (except SMF-71), sending a message to a user at 
the default SMTP host can be reduced down to just a "user @ 
c2gate" syntax if the recipient's name is eight characters or less.  
For example:

joe @ smtp

Domain Name Services
The simple act of selecting a TCP/IP host name for 
Connect2SMTP won't in itself do much until you have the host 
name registered in some type of name server.  A name server  
answers DNS queries in a hierarchical fashion, which allows 
remote hosts to resolve where they should send messages that 
are addressed to MHS users at Connect2SMTP's TCP/IP host 
name.

If all you'll be doing is exchanging mail locally, a simple entry 
in a local name server should suffice to get SMTP mail working 
with Connect2SMTP.  If you'll be receiving mail from various 
locations all over the Internet, you'll need to get 
Connect2SMTP's TCP/IP host name registered with the 
authoritative name server for your domain.

For example, if Connect2SMTP's TCP/IP host name was 
"c2gate.acme.com", and Connect2SMTP's IP address was 
125.26.10.1, the entry you would want in your authoritative 
name server's hosts database would look similar to this:

Name
 Class
 Type
 Address

c2gate.acme.com
 IN
 A
 125.26.10.1


Defining Mail Exchange (MX) Records
MX records (which means Mail Exchange) are entries that can 
also be defined in your authoritative name server that are used 
by remote SMTP hosts to determine if there's an alternate host 
that will accept mail for Connect2SMTP (and then forward it).

If the physical link to Connect2SMTP from the outside world is  
unstable or non-existent, but a nearby "UNIX box" has a good 
connection to the outside world, you can define the "UNIX 
Box" as an MX record for Connect2SMTP with your 
authoritative name server.

More than one MX record can be used (and often is), to 
improve the likelihood that in one way or another a remote 
SMTP host will be able to forward mail destined for 
Connect2SMTP to another host.

For example, if the host name of the nearby "UNIX box" was 
called "bigbro.acme.com", the entries needed in your domain 
name server's hosts database would look similar to this:

Name                    Class  Type  Pri  Address
----                    -----  ----  ---  -------
c2gate.acme.com         IN     A          125.26.10.1

			IN     MX    0    c2gate.acme.com

			IN     MX    10   bigbro.acme.com


MX entries are used in order of priority, from lowest to highest.  
So when remote SMTP hosts have mail for Connect2SMTP and 
then query for MX records, the following sequence will be 
followed:

*       the direct address to Connect2SMTP will be used.  If this 
	fails to connect;
*       the mail will be passed to the next highest priority which is 
	the "bigbro.acme.com".


Hiding Connect2SMTP Behind a UNIX Host
The most desirable way to use Connect2SMTP is by using the 
DNS to resolve Connect2SMTP's TCP/IP host name when 
remote SMTP hosts have mail to send to it.

If this isn't possible because you can't get Connect2SMTP's 
TCP/IP host name registered with an authoritative name server, 
there is still a way to work around the problem if a nearby 
"UNIX box" can be configured to forward mail to 
Connect2SMTP when the address contains a certain flag after 
the user's name.

Normally, Connect2SMTP has its own unique TCP/IP host 
name, and mail addressed to "Joe@c2gate.acme.com" is clearly 
intended for an MHS user called Joe at the default MHS 
workgroup.  But when Connect2SMTP shares the same TCP/IP 
host name with another "UNIX box", something more than just 
"Joe" has to be given for the user name so that the "UNIX box" 
will know the message gets forwarded to Connect2SMTP.

For example, if the flag text was ".mhs", Joe would be 
addressed as:

joe.mhs@bigbro.acme.com"

So the "UNIX box" would strip off the ".mhs" and forward the 
message to "Joe@c2gate.acme.com".

In this situation, the only host that knows the name 
"c2gate.acme.com" is the "UNIX box"; you configure 
Connect2SMTP to use the same TCP/IP host name as the 
"UNIX box" (which is controlled by the HostName variable in 
C2SMTP.INI).

If it's hard to get a host name mapped to an IP address for 
Connect2SMTP in the "UNIX box", forwarding the message to 
Connect2SMTP's IP address should work fine.

To get Connect2SMTP to build reply addresses with a ".mhs" 
after the user's name, use the following definition in the [MHS] 
section of C2SMTP.INI:

UserNameSuffix = .mhs


Attachment Encoding and Decoding
Connect2SMTP provides support for handling both 
UUENCODED and MIME encoded attachments.

Inbound message conversion is automatic since Connect2SMTP 
can automatically detect encoding information in the message.

The default for outbound attachment convertion is 
UUENCODE, unless MIME is enabled by the use of the 
MIME=Yes parameter in the C2SMTP.INI.

Individuals may force an outbound attachments to be encoded 
in a specific fashion by putting specific override information, 
namely "MIME:" or "UUENCODE:", at the beginning of the 
address.  The override codes will be used to determine the 
outbound encoding, then stripped from the address before 
delivery.

To force an outbound attachment to be UUENCODED, the 
address would be similar to:

UUENCODE:support@infinite.ihub.com

To force an outbound attachment to be MIME encoded, the 
address would be similar to:

MIME: support@infinite.ihub.com

For more information on overriding attachment encoding, see 
the section entitled "Overriding Outbound Encoding".

MIME
Extensive support for MIME (Multipurpose Internet Mail 
Extensions) has been implemented.  MIME is an extension of 
the message format for RFC-822 based mail systems that 
(among many things) allows messages to be partitioned with 
multiple file attachments of varying declared types (i.e. 
Richtext, audio, video, etc...), or a generic type of 
"application/octet-stream", all of which can be encoded in 
BASE64 which keeps binary data intact (similar to 
uuencoding).  MIME also allows message body text to be 
encoded in a manner that prevents loss of non-ASCII (i.e. 8-bit) 
characters during transport.

Note: For more information on MIME (text documents which 
      includes FAQ's, a general overview, comments by one of 
      MIME's authors, the RFC, etc), you may request it by sending a 
      message to:

To:             library@infinite.ihub.com
Subject:        MIME


Inbound MIME
Inbound messages formatted with MIME are always recognized 
and fully decoded regardless of any configuration options.

Body parts with a content-type: of text/??????? are considered 
to be message text and are assembled (decoded) into the overall 
MHS message body.

All other content-type:'s (i.e. "application/octet-stream") are 
decoded to individual attachments and the MHS attachment-
type: header field is set to the MIME content-type: value.

All encoding methods; 7BIT, 8BIT, Binary, Quoted-Printable, 
and BASE64 (only the latter 2 require logical decoding) are 
supported.  If a file- name was given using the "name=" 
parameter, it is passed through to the MHS header, otherwise, 
the MHS filename is set to "UNKNOWN".


Outbound MIME
The preferred (default) method of how outbound SMTP 
messages are encoded is controlled by this sequence of 
statements in the [MHS] section of the C2SMTP.INI file:

[MHS]
MIME=Yes|No             ;Prefer MIME for outbound
			 (default=No)
Uuencode=Yes|No         ;Use Uuencode for outbound
			 (default=Yes)

If MIME=Yes, then MIME is the preferred method of outbound 
encoding and the value of UUENCODE is insignificant for 
outbound SMTP mail.

If MIME=No, then outbound file attachment encoding is 
controlled by the Uuencode= statement.  If UUENCODE=Yes, 
then outbound SMTP file attachments are uuencoded (as 
before).  If UUENCODE=No, then file attachments are not 
encoded (in this case, if they are still eligible for AsciiAttach 
they may still be sent, but if they are binary the the message is 
returned to the sender).

Note: If you set MIME as the preferred outbound encoding, the 
      value of UUENCODE= still controls whether inbound SMTP 
      mail is automatically scanned for UUENCODED attachments.

If MIME is set as the preferred outbound encoding, outbound 
SMTP messages are only formatted with MIME when required.

Connect2SMTP determines whether an outbound message needs 
to be in MIME format by analyzing the message body, and/or 
whether the message has attachments.  If the message has file 
attachments, MIME will be used. Or, if any part of the message 
body is not strictly 7-bit, MIME will be used.  If MIME is used 
and the message body does not conform to 7-bit, the body is 
encoded in "quoted-printable", otherwise, the body is simply 
inserted as a 7BIT partition (because in this case we must be 
using MIME due to file attachments).

Each file attachment is also scanned to see if it can be sent as a 
7BIT partition.  If it passes the 7-bit test, the file attachment is 
simply inserted as a 7BIT partition, otherwise it is encoded 
using BASE64.

The strict 7-bit test considers encoding necessary if any part of 
the message body or file attachment contains anything other 
than CR, LF, (in proper sequence), HT (tab), and the characters 
of SPACE through ASCII 126.  The 7-bit test will also fail if a 
line length exceeds 512 characters.

If Connect2SMTP uses MIME, the overall intent is that we want 
as much of the message to be as humanly readable as possible 
without comprimising data integrity or intended results.  In the 
event a message is sent in MIME format to a recipient who 
doesn't use a MIME-capable mail reader, we want the recipient 
to be able to use as much of the message as possible without 
having to use an external decoding utility, if the data being 
transported is primarily text.  An example is that instead of 
scanning each file attachment to see if it conforms to 7BIT, we 
could have just encoded it in BASE64 arbitrarily - but a text file 
sent like that is not readable by the recipient until decoded.


Uuencoding
If the Uuencode option in C2SMTP.INI is enabled (or not 
specified - the default is enabled), Connect2SMTP automatically 
uuencodes and decodes MHS file attachments.

When enabled, each message received from SMTP is scanned 
for encoded blocks which are automatically decoded into 
attachments, and outbound MHS messages that contain file 
attachments are automatically uuencoded into the SMTP 
message body.

The scanning algorithm of inbound SMTP messages is very 
selective when detecting uuencoded blocks.  If any part of the 
uuencoded block doesn't conform to the specification, scanning 
is abandoned and the message body is passed through 
untouched.

When a block of uuencoded text is decoded from an inbound 
SMTP message, the uuencoded block is removed from the 
message text, but the lines preceding and following the block 
remain intact.  Connect2SMTP has no internal limitations on the 
size of uuencoded files.

Note: Encode and decode are standard utilities in the UNIX 
      operating system.  But, it is not standard to automatically scan 
      and decode a message containing a uuencoded file when 
      received by a remote SMTP mailer, or other types of SMTP 
      gateways.  In some instances, the remote SMTP user may have 
      to save the received message to a file and then run a decode 
      program against it in order to extract the attached file.  Public 
      domain PC-based decode programs are available that run under 
      both DOS and Windows, and can be found on Compuserve or in 
      our Library.  (Send a message to Library@Infinite.ihub.com 
      with a subject of INDEX for a list of available files.)


Appending ASCII Attachments
When an outbound MHS message has a file attachment that 
only contains ASCII text characters, it may be desirable to 
simply append the file attachment onto the body of the SMTP 
message rather than uuencode it (which saves the recipient from 
having to decode it if their SMTP mailer or gateway doesn't 
perform the service automatically).

This feature is enabled with the following variable in 
C2SMTP.INI under the [MHS] section:

AppendAttachIfAscii = nn

"nn" is the maximum size of an attached file (in K) that will be 
considered for appending.  A value of zero disables this feature.  
Any file that contains characters other than the ASCII characters 
9, 10, 12, 13, 32-127 (26 allowed at the end of file) is 
automatically disqualified and will be uuencoded instead (if 
enabled).

Note: This feature only applies when uuencoding is being used 
      for attachments.  It does not apply when MIME encoding is 
      used.


Large Message Conversion
When an inbound SMTP message contains body text larger than 
what your MHS e-mail application can handle, Connect2SMTP 
provides a configurable option that can convert to a MHS file 
attachment.  (For instance, if a mail client has a body text limit 
of 32K, an inbound SMTP message containing body text larger 
than 32K might get truncated at the 32K boundary, unless it is 
converted into an attachment.)

This feature is enabled with the following variable in 
C2SMTP.INI:

MoveBodyToAttach = nn

"nn" is the maximum body text size (in K) of an inbound SMTP 
message that will pass through without being converted.  A 
value of zero disables this feature.  When an inbound SMTP 
message body is moved to a file attachment, a small note is 
written in the message body indicating this occurred.


Return Receipts
Return Receipts may be requested in one of two ways; globally 
for all message sent throught the gateway, and individually as 
each message is addressed.


Global Configuration
Connect2SMTP can be configured to always request a return 
receipt when incoming SMTP mail is read by the MHS user, by 
including the following statement in C2SMTP.INI:

AlwaysGenRetRcpt = Y


Asking for Return Receipt in the Address
If the global option is disabled (which is normal), two other 
methods of getting a return receipt are still available:

1.      SMTP users can ask for a return receipt by embedding a 
	flag in the address of the message, which produces the 
	same affect on a case-by-case basis.  Normally, a SMTP 
	user addresses a MHS user as follows:

	user%mhshub@HostName

	However, if a "/r" is embedded after the MHS hub name 
	(or after the user name if hub names aren't being used) 
	Connect2SMTP will build the MHS message with a return 
	receipt requested.  For example:

	user%mhshub/r@HostName

2.      Connect2SMTP will always request an MHS return receipt 
	if the inbound SMTP message has a "Return-Receipt-To:" 
	header field.  

For mail going from MHS to SMTP, return receipts are a little 
more convoluted.

C2SMTP.INI has an option called UseMhsRetRcpt that 
controls whether Connect2SMTP recognizes an MHS message 
that requests a return receipt.  SMTP was never designed with 
return receipts in mind.  Some SMTP mailers recognize a 
"Return-Receipt-To:" header field and some don't.  If a mailer 
does recognize this field, it usually generates a delivery 
notification, not a time-of-reading return receipt.  If the 
UseMhsRetRcpt option is enabled, Connect2SMTP will build 
the "Return-Receipt-To:" field in outgoing SMTP messages 
when a MHS message requests a return receipt.  This option is 
disabled by default since the delivery notifications could be 
misleading to MHS users who would usually think it means the 
message had been read.

MHS users still have another means of requesting a return 
receipt even if the UseMhsRetRcpt field is disabled in 
C2SMTP.INI.  A flag can be embedded in the SMTP address 
that also causes Connect2SMTP to build the same "Return-
Receipt-To:" field in the SMTP header.  Normally, an MHS 
user addresses an SMTP user as follows:

	user @ gateway {username@smtphost}

If an additional "/r" is embedded after the "username" in the 
SMTP address, Connect2SMTP will generate the "Return-
Receipt-To" field in the outgoing SMTP message (and remove 
the /r).  For example:

	user @ gateway {username/r@smtphost}


Postmaster
Connect2SMTP automatically forwards received SMTP mail 
addressed for "Postmaster" to the MHS administrator.

When Connect2SMTP returns a -Maiser- delivery error to an 
SMTP user that was generated by MHS, the sender of the 
message is automatically remapped from "-Maiser-" to 
"Postmaster".


Delivery Modes
For outbound SMTP mail, Connect2SMTP can operate in a 
relay mode, a direct delivery mode, or a mixture of both.

Relay Only Mode
In relay only mode, Connect2SMTP passes all outbound mail to 
another nearby SMTP host.

Direct Delivery Mode
In direct delivery mode, Connect2SMTP resolves the recipient's 
host name either to a direct IP address or an MX record, and 
then initiates a connection to deliver the message.

To do direct delivery, Connect2SMTP must be configured to 
know at least one name server's IP address, but may be 
configured to use as many as ten different name servers.  If no 
name servers are given in C2SMTP.INI, Connect2SMTP will 
work in relay mode only.  In addition, if the IP address for the 
relay host isn't given, Connect2SMTP will only work in direct 
delivery mode using the name servers specified.  If the IP 
addresses of both the relay host and name servers are given, the 
order in which they are attempted is controlled by the 
"RelayFirst" variable in C2SMTP.INI.

Note: In direct delivery mode, Connect2SMTP will 
      notify the MHS user of  a delivery problem after 4 hours 
      of not being able to deliver a message, and for each 
      additional 24 hour period until the undeliverable point is 
      reached and the message is canceled and the user is 
      notified.  The best way to first configure Connect2SMTP 
      is setting "RelayFirst=No" so that it tries direct delivery 
      first using name servers (provided you have direct 
      Internet access), but also have a relay host defined in the 
      event direct delivery doesn't work for a valid destination.

SMTP Mail Forwarding
Messages received by SMTP may be forwarded to another 
SMTP address by creating a file named FORWARD (no 
extension)in Connect2SMTP's home directory.  Each line in the 
file represents a single name that is to be forwarded.  The first 
field is the recipient's fully qualified name, and the second field 
is the SMTP address to forward the message to.  The two fields 
must be separated with a colon.  For example:

joe@acme.com:     78923.123@compuserve.com
sales@acme.com:   pete@acme.com

 In this example, any mail received from SMTP for 
"joe@acme.com" is forwarded to 
78923.123@compuserve.com", and likewise, any SMTP mail 
received for "sales@acme.com" is forwarded to 
"pete@acme.com".

This option is mainly intended to facilitate the use of fictious 
SMTP mailbox names, which is what the 2nd example is doing.  
This lets you easily change who receives messages addressed to 
"sales@acme.com".

Note:  The FORWARD file is cached in memory.  When 
       changed, C2SMTP must be stopped and reloaded before 
       changes are recognized.

The FORWARD file may also be used as a rudimentary list 
server for mail received from SMTP, simply by adding more 
than one name to the recipient field.  The recipient list can be 
wrapped across multiple lines.

list1@acme.com:  joe@acme.com
		 pete@acme.com
list2@acme.com:  frank@acme.com, joe@acme.com
		 pete@acme.com

Lists containing multiple recipients that wrap across several 
lines do not need to end with a comma.  However, commas are 
necessary if more than one recipient is given on a single line.  
When a following line starts with one or more space or tab 
characters, its now considered a folded line and the current list 
is continued.

Also, a null list for a forward name is acceptable, which simply 
causes any mail sent to that name to be discarded (useful on 
occassion for test purposes).

Any delivery errors for names in the list will come back to the 
MHS administrator, "<postmaster@hostname>".

To help in checking how the FORWARD file is being parsed, a 
command is available on the MHS Monitor that displays the 
active forward lists.  (This screen is dimensioned for 500 lines.  
If the contents of the FORWARD file exceed that, only the last 
500 will show.)
  
Console Scroll Back & Memory Usage
The size of the scroll back buffers depends on whether 
Expanded Memory (LIM/EMS 4.0) was present when 
Connect2SMTP started, or whether Connect2SMTP is running in 
protected mode.  If either is true, Connect2SMTP will allocate 
64K from expanded or extended memory for each scroll back 
buffer.  Otherwise, the scroll back buffers are allocated with x-
number of lines from conventional memory as determined by 
the " Scrollback" parameters in both the MHS and SMTP 
sections of the C2SMTP.INI.

Connect2SMTP as a Name Server
Connect2SMTP may be configured to expedite name server 
lookups for client nodes on your network.  What follows is a 
summary of how this feature is set up.

Overview
If you have one or more name servers defined in C2SMTP.INI, 
you can configure local nodes to Connect2SMTP as a name 
server.  Connect2SMTP uses the following sequence to resolve 
names:

*       it scans the cached image of the HOSTS file (described 
	next) and sends a reply if the name is found
*       if the name isn't resolved by the HOSTS file, 
	Connect2SMTP immediately rebroadcasts the query to all 
	name servers defined in C2SMTP.INI and logs the request 
	in a working table
*       as soon as one of the name servers provides a positive reply, 
	Connect2SMTP relays the response back to the requesting 
	station and closes out the active request
*       if a late reply comes in from one of the other name servers, 
	it is discarded
*       Connect2SMTP will time out active requests if a positive 
	response isn't received within 20 seconds.

Connect2SMTP provides this service asynchronously as a 
background task.  It is a high performance solution to 
simplifying and expediting name server lookups for client 
nodes.  Workstation configurations can send one query to 
Connect2SMTP and still be able to resolve names in a parallel 
fashion using all the name servers Connect2SMTP knows about 
rather than resolving them one by one.


The HOSTS File
Even though the HOSTS file will resolve names for outbound 
SMTP mail (and will do it before name servers are used), it is 
intended primarily as a mechanism to use nicknames or 
shorthand names for commonly accessed hosts when 
Connect2SMTP is queried as a name server.

The format of the HOSTS file uses one line for each host 
beginning with its IP address.  Multiple host names can be 
given for the same IP address by appending them on the same 
line, separated with either spaces or tabs.  For example:

129.194.30.5    ns-nic
129.9.0.107     isi     a.isi.edu

The HOSTS file must reside in Connect2SMTP's home 
directory.  Its contents are read at startup and held in memory, 
so be careful how many names you add.  Changes to the 
HOSTS file don't take effect until the next time Connect2SMTP 
is restarted.


Appendix A: Character Set 
=========================

Translations
Connect2SMTP includes an option that allows you to build and 
use 8-bit character set translation files which can be used 
automatically to translate between any type of 7-bit or 8-bit 
character set, for both inbound and outbound SMTP mail, as 
long as MIME is enabled.  MIME is required because there is 
no standard means to indicate the character set of an SMTP 
message without it.

This is mainly needed in non-US installations where SMTP 
messages might be received in ISO-8859-1 (or any other ISO 
character set other than "US-ASCII"), which should be 
converted to IBM-437 (the equivalent of a national 7-bit 
character set), before handing the message to MHS for routing.  
This is needed because most present day Windows-based MHS 
mail applications arbitrarily expect an SMF message to be in the 
IBM-437 character set, even if the SMF header has the 
Message-encoding: header field set to the actual character set 
received.

Since the default internal Windows character set is ISO-8859-1, 
most Windows-based MHS applications arbitrarily call a 
Windows API function to convert the character set to ISO-
8859-1, even if it was already in ISO-8859-1 (which can then 
produce undesirable results).

So, if you're using a Windows-based MHS E-Mail application 
that doesn't recognize the Message-encoding: field, you can use 
this new capability to automatically convert inbound MIME 
messages which are in ISO-8859-1 to the IBM-437 character set 
(as you define it), or for any other type of character set  
conversion purposes needed, before C2SMTP gives the
message to your MHS router.

The same is also true for outbound MIME messages.  If you 
would prefer that all outbound MIME messages were in one 
particular character set, you can now set the default SMTP 
character set and then build as many character set conversion 
files as you need.

This feature is controlled with three C2SMTP.INI parameters 
for the [MHS] section of that file:

   SmfCharSet=
   SmtpCharSet=
   CharSetTable=

SmfCharSet=
This variable sets the target character set when converting 
inbound MIME messages to SMF.  The SMF default is IBM-
437, which is what this value should normally be set to.  If you 
don't want C2SMTP to convert the character sets of inbound 
MIME messages, do not set this variable.

SmtpCharSet=
This variable sets the target character set when converting 
outbound SMF messages to MIME.  If you don't want C2SMTP 
to automatically convert outbound SMTP messages to one 
character set, do not set this variable.

The MIME default is "US-ASCII", which is a 7-Bit character 
set roughly equivalent to IBM-437.  If you want all of your 
outbound MIME messages to be converted to ISO-8859-1, than 
set this variable to ISO-8859-1.

CharSetTable=
This statement loads a character set translation file.  Only 
specify the filename, C2SMTP will automatically use a path 
that points to the directory it was run from.  This statement may 
be repeated to load as many character set translation files as 
needed.

All unique combinations of character set translations that might 
be encountered must be defined by a character set translation 
file, or no trnaslation will take place (and the existing character 
set will pass through).  Converting from IBM-437 to ISO-8859-
1 (for example) is not the same as converting from ISO-8859-1 
to IBM-437.  If you want to do bi-directional translations, two 
separate character set translation files are needed.

The format of a character set translation file is as follows:

   INPUT=<charsetname>
   OUTPUT=<charsetname>
   MAPCHAR x=y[,x=y[,x=y]...]
   [MAPCHAR x=y[,x=y[,x=y]...]]

All conversions are based on finding a loaded character set 
translation file that has INPUT= and OUTPUT= character sets 
that match the needed conversion.  If a character set translation 
file can't be found with matching INPUT= and OUTPUT= 
character set names, no translation will take place.

For example, if you set the SmfCharSet=IBM-437, and a MIME 
message is received in ISO-8859-1, in order for the message to 
be converted a character set translation file must be loaded 
similar to this:

   INPUT=ISO-8859-1
   OUTPUT=IBM-437
   MAPCHAR 254=127 [,...]

The values used for MAPCHAR in this example are for 
illustration purposes only.

The first value in a MAPCHAR statement (x) is the character in 
the INPUT character set that will be remapped to the value after 
the equals sign (y), in order to produce the OUTPUT character 
set.

The values used for MAPCHAR are considered decimal by 
default.  Hex values can be used, if desired, by prefixing their 
value with "0x".

Multiple mappings can be expressed on one MAPCHAR 
statement, by separating them with a comma.  Or, you can use 
as many different MAPCHAR commands on separate lines as 
needed.

A comment is started with either a semi-colon or a pound sign
(";" or "#").

When a character set translation file is loaded, the entire table
of 256 characters are reset to their default values (i.e. 0=0, 1=1,
.., and 255=255).  You only need to use MAPCHAR statements 
for the characters that need to be changed to a different value.

Character set translations are only performed on the message 
body. File attachments are never translated.


Appendix B: Product Support
===========================
Support for Connect2SMTP is available directly from Infinite 
Technologies.  You may send mail to us at the following 
addresses:

MHS:            SUPPORT@INFINITE
CompuServe:     >MHS:SUPPORT@INFINITE
Internet:       SUPPORT@INFINITE.IHUB.COM
Phone:          (800) 678-1097

- or -

Infinite Technologies
11433 Cronridge Drive
Owings Mills, Maryland  21117


Connect2SMTP Discussion List

To subscribe to a discussion list that discusses Connect2SMTP 
technical issues and updates, send a message to 
C2SMTP@Infinite.ihub.com with a subject line of 
SUBSCRIBE




