Table Of Contents

For help with other topics, please consult the index or use the search engine.

Copyright, 1994-1995, Jack De Winter, Wildbear Consulting

This program is available in both shareware and commercial versions.  For more information regarding the differences between the shareware and commercial versions, please consult the Product Description link below.  For more information about Wildbear Consulting, please consult the Company Information link below.

If you have any bugs to report, questions to ask about our product, or requests to make, please send electronic mail with your information or questions to: winsmtp@wildside.kwnet.on.ca.  Please note that requests from unregistered shareware users may be processed after requests from registered shareware users and commercial users have been fulfilled.

Product Disclaimer

Company Information

Product Description

Registering The Product

Introduction

The SMTP and POP3 Protocols

Product Features

Getting started

Dialog Boxes

Troubleshooting System Configuration

WRmail - Injecting Messages Into The Product


Dialog Boxes

Here is a list of the dialogs used within the system:

File submenu

Retries Dialog

Mailing List Maintenance Dialog

Configuration submenu

System Mode Dialog

System Configuration

Routing Dialog

System Timings Dialog

System Users Dialog

Help submenu

Registration Dialog


WRMail

The WRMail program (located in the same directory as the WinSmtp file itself) can be used to inject mail into the WinSmtp daemon.  This program operates under Windows and allows an application to specify a file, the sender, the recipients, and options used to send the file.  In this manner, an end-user may use a programming language of their own choice to construct a mail message, and then use this program to send it to a friend or a client.

The syntax of the command line for the Wrmail program is as follows:

wrmail [-r] [-tsubject] [-t"subject text"] [-s {sender}] -f {file} {recipient1}... {recipient n}

or

wrmail [-r] [-tsubject] [-t"subject text"] [-s {sender}] {recipient1}... {recipient n} < {file}

Objects in braces ( '{' and '}' ) are used to denote objects that are representations.  For example, {file} would be the name of the file that you want to send.  Objects in square brackets ( '[' and ']' ) denote objects that are optional.

For the optional sender object, if one is not specified, then the program will expect the first line to be in the form:

From {name} {date}

From this information, the program will be able to extract the name of the sender.

The '-r' options forces the RFC 822 compatibility mode off.  This effectively treats the input file as encapsulated data, and it will add its own header information.  For this option, the sender of the file must be specified separately.  The '-t' option specifies the topic or subject of the message.  This can only be used in the non-RFC mode.  This enables you to send a file to someone and specify the subject in the message.  Please note that the -t option must either be immediately followed by a one word subject or by a set of quotes that delimit a multi-word subject.


Getting started

Once you install the WinSmtp package, there are defaults for every setting.  While these settings may not work for you, it will help you get to the point where your system can communicate with another SMTP daemon.  At the very least, with the installation settings, you should be able to set up a couple of local users and exchange mail between them.

Before proceeding any further, it is necessary to point out the behaviour that should be used when connecting up to another computer.  While some people may not agree with this view, it is necessary for it to be pointed out so that some basic ground rules are set.

For this product to work effectively with the Internet, you will need the cooperation of at least one more computer on the Internet.  This computer should be topologically close to your node, to reduce the waits inherent in some of the requests that are made by this product.  As you need the cooperation of the people that run that computer, it is your responsibility to make sure that any bureaucracy and civility necessary to obtain and maintain that cooperation is performed.  If you do not do this, then you will find out that your mail feed may dry up very quickly if someone decides to delete your access.

Good candidates for these types of computers may be other computers within your scholastic or corporate structure, a service provider, or even a simple arrangement between your computer and a computer in a neighbouring company.  From time to time, you may need to contact the system administrator on another system, so make sure you get contact information for at least one of the technical people.  If possible, get an electronic mail address as well as a phone number, even if it goes to a voice mailbox.

Once you have obtained the consent to go ahead, you will require a couple of tasks to be performed.  The first is that you will need to set up the smart host and the name server for your node.  These settings can be found in the System Configuration Dialog and are used to send information to nodes other than your own.  Once those entries have been entered, you should test the system by sending a small message to a user at a remote site.  If this does not work, you will need to look at troubleshooting system node configuration.

Once you have that setup, you might need to get one of the administrators at the site specified as your smart host to set up a connection between their computer and yours.  If your node is not accessible from the Internet at large, you will have to get a MX record and possibly a CNAME record created such that other nodes will know to send mail to the other site, where it will be forwarded to you.  In any case, it is usually a good idea to have a MX record in place so that if you need to take your system down, it will go to a computer that is topologically closer to your node.  Once again, make sure that it is okay to list a node in a MX record before that node is placed in a MX record.

At this point, you have set up your system to communicate with the outside world and the outside world set up so that they know about your node.  There may be some problems with respect to your mail daemon that you might need to troubleshoot.  Most of these problems are pretty standard when setting up a node for the first time.  If you are still having problems setting up your mail daemon, please send electronic mail to our support department at winsmtp@wildside.kwnet.on.ca.  Please do this after reading the section on troubleshooting to help us to serve the other users better.


Registering The Product

If you are using the unregistered version of this product, please register the product if you intend on using it in any way, shape, or form after the 30 day trial period.  Registering the product will allow you to use all of the features of this product, instead of the very basic ones.  In addition, registration will allow you access to better support, as well as input into future versions of the product.  Any requests made by registered users will be given full consideration, and these requests will be fulfilled before those of unregistered users.  If you are using this product full time, $50 USD ($50 CAD for those inside of Canada) is a small price to pay for reliable mail transport with the Internet.

If you want more information on the registration dialog, click here.  You will need to navigate the dialog to print out the registration form and to get the information needed to fill in the registration form.

In addition, there is also a commercial version of this product.  The commercial version of this product is similar to the registered version, except that the limits on the number of users have been lifted.  Also, enhanced support will be provided to commercial users, and requests from a commercial user will be fulfilled before those from registered and unregistered versions.  The pricing for the commercial version of the product is $100 USD for people outside of Canada and $100 CAD for people inside of Canada.

Below is a table indicating the number of users of each given type that are allowed at each level of the product.  Please note that the limits for Aliases and Forwards at every level is unlimited.

Registration Level	Number Of Users	Number of Mailing Lists	Number Of Auto-Responders
Unregistered	5	1	1
Registered	75	5	5
Commercial	unlimited	unlimited	unlimited


Retries Dialog

This dialog may be accessed through the Retries menu item of the System submenu.  The purpose of this dialog is to provide information about any retries  that are currently happening.  In addition, registered users can use this dialog to bounce the message back to the sender, or to force a retry to occur.  Please note that if there are no retries happening within the system, a message box will appear in place of this dialog, informing the user that there are no retries that are currently happening.

The main focus of this dialog is the listbox that dominates the dialog itself.  Within this dialog, there is a list of all of the retries that are currently occurring.  Each of the items lists the name of the node for the retry, how many messages are queued up for that node, and how often the retries are currently occurring.  In this manner, the user can very easily figure out if there are problems with any particular classes of nodes and how best to resolve them.

For registered users, there are two special buttons in this dialog.  The first button is labeled Force Retry.  Pressing the button will attempt to start up an outgoing connection at that moment.  This function is very useful if the retry time-out has expanded to a large value and the user wishes to try the retry at that moment, to verify a solution for the problem that is preventing the transmission.  The other button is labeled Bounce Message, and will bounce or send the message back to the user that sent the message.


Mailing List Maintenance - Subscriptions

This dialog is responsible for handling the remote requests to join a moderated list.  On the left side of the dialog is a listbox containing the addresses of the remote users who wish to gain membership to the specified list.  On the right side are two edit fields labeled Address and Name.  These edit fields are set when a selection is made from the listbox.

At the bottom of the dialog are two pushbuttons marked Approve and Reject.  Pressing the Approve pushbutton will move the remote user into the membership list for the current mailing list.  The Reject pushbutton will send a rejection notice back to the remote user.


Mailing List Maintenance - Submissions

This dialog is responsible for the approval, rejection, or deletion of a given message directed at a moderated mailing list.  The layout is pretty simple.  The left hand side contains a listbox labeled Incoming Messages that displays a list of the files waiting for consideration.  When one of these items is selected, the first 16 K of the file is displayed in the read-only edit field labeled Preview.

After examining the preview, the moderator has three options.  If the article is acceptable, then the moderator can press the Accept pushbutton, which will make sure the message gets out to members of the mailing list.  If the article does not meet with approval, then the moderator can press the Reject pushbutton, sending a rejection notice back to the originator if the message.  Finally, the Delete pushbutton is used to remove the message from the system without generating a rejection notice.


Mailing List Maintenance - Members

This dialog is used to maintain the list of members for a given mailing list.  This includes the provision to add and delete members, as well as to set individual settings for each member.

On the left hand side of this dialog is a listbox labeled Members, containing a list of all the current members.  When one of these items is selected, the appropriate information is reflected on the right side of the dialog.  The first two parts of this section are the Address edit field and the Name edit field.  The Address field contains the Internet address of the member, and the Name field contains the readable text name of the user (for maintenance purposes only).  Below this are four options:

Reproduce - Send the user a copy of the article that they submitted.

Acknowledge - Send a short acknowledgment that a submitted article was received.  Only valid if Reproduce is not enabled.

Conceal - Conceal the users presence on an external query for the list.

No Mail - Do not send the user any mail submitted by other members, but maintain their presence on the list.

At the bottom of this section are three pushbuttons labeled Add, Modify, and Delete.  When the Address edit field contains a new name, the Add pushbutton is enabled and the other two are disabled.  If the Address edit field contains an existing name, then the information is reflected in the other controls (unless it has been changed) and the Add pushbutton is disabled and the Modify and Delete pushbuttons are enabled.  Pushing the Modify pushbutton will update the information for the current member, while the Delete pushbutton will delete the member from the given list.


Mailing List Maintenance Dialog

This dialog is the central point from which the mailing lists are maintained.  On the left hand side of this dialog is a listbox entitled Mailing Lists.  This listbox displays a list of all of the mailing lists maintained by the local daemon.  To the right of this are three sets of controls.  As different mailing lists are selected in the Mailing Lists listbox, these three controls are changed so that they display the information about the selected mailing list.

The first set of controls shows the number of pending subscriptions and has a pushbutton labeled Process Pending Subscriptions.  Pressing this pushbutton creates the Mailing List Subscriptions Dialog, used to accept or reject requests for membership in a given list.  Beneath that is the set of controls that shows the number of pending messages, and has a pushbutton labeled Process Pending Messages.  Pressing this pushbutton creates the Mailing List Submissions Dialog, used to accept, reject, or delete messages sent to a given moderated list.  Finally, there is the set of controls used to maintain the membership of the list and that set has a pushbutton labeled Edit Members.  Pressing this pushbutton creates the Mailing List Members Dialog, used to add, delete, or modify the users that subscribe to a given mailing list.


System Mode Dialog

This dialog is responsible for defining the interface that will exist with the outside world.  The two options are shown as radiobuttons: Network Always Present and Dialup To Network.  If the network is always present, then it is assumed that no forcing of a connection is to be made.  However, if the Dialup To Network radiobutton is active, then there is the assumption that the underlying connection to other computers is on a by demand basis.  Many protocol stacks will have the ability to dialup on demand and to hang-up the connection if no activity is detected for a specified length of time.

Below the radiobuttons is a group of controls labeled Mode Options.  The first control is a checkbox labeled Force Connect To Smarthost On Startup.  If this control is checked, then the daemon will force a connection with the smarthost when the daemon is started up.  If the ESMTP System option is enabled and the remote system will support the Extended TURN command, then that command is sent to the smarthost.

If the Dialup To Network mode is enabled, then the combobox labeled Force Connection will be enabled as well.  This will force a connection to be made to the smarthost and will also send the Extended TURN command if enabled.  In this manner, the protocol stacks dialup mode should be enabled and should dial out to the service provider to make the connection.

Please note that the options set in this dialog are loaded up when the system starts, and as such require a restart of the daemon to reset these options.


System Configuration Dialog - Aliases

The aliases provided by the daemon allow the daemon to appear to be another machine or to process mail for a group of machines.  It is very common in a multiple computer environment, that one of a group of computers will receive the mail specified for that institution.  In this case, it is very rare that the mail node name will be the same as the node name for the institution.  In addition, there are times where institutions may want to redirect mail from multiple domain names to one mail daemon.  This is where the aliases come in.

There are basically two types of aliases: outgoing and incoming.  The outgoing alias allows you to replace the local node name with the name of another node.  This replacement is done on any outgoing mail, and a transition is also automatically performed to change any occurrence of that name to the name of the local node.  Since this will be the externally visible name of the mail node, there can only be one node name in the Outgoing Alias edit field.

The other type of alias is the incoming alias.  This type of alias is used to convert external names for the mail node to the singular internal node name.  The Incoming Alias edit field accepts the names of multiple incoming aliases, aliases being separated from each other using the semi-colon character.  Once this transition is performed, there is no way of knowing what the original node name was before the transition.  Also note that if you specify a node name in the Outgoing Alias edit field, it is automatically included in the incoming aliases, and as such does not need to be specified manually.


System Configuration Dialog - Local System Information

There is some information about the local system that is needed to get the daemon up and functioning properly.  This is information regarding its own identity, the identity of the smart host, and the identity of the name server.  These pieces of information are needed in order to properly communicate with the outside world.

The first two pieces of information are the Local Node edit field and the Local IP edit field.  These entries are usually filled in by the daemon upon startup.  This checking can be disabled by unchecking the Verify Node At Startup checkbox in the System Configuration dialog Options section.  Note that if the check is disabled, no verification of the IP address or host name is performed, so any corrections cannot be made.

The next two pieces of information are the Smart Host and Name Server edit fields.  These fields allow the daemon to try and resolve mail locally and to send any mail that it cannot resolve to a more authoritative host.  The Name Server edit field should be filled with the node name of a system that will provide the necessary Domain Name Services required to resolve addresses.  The Smart Host edit field should be filled with the node name of a system that will try and resolve addresses that your system cannot resolve.

You should make sure that you have the permission of the system administrators from those systems before you place their computer node name in those fields.  In addition to using the external Domain Name Services, the WinSmtp daemon will also cache the information locally to avoid long delays where ever possible.


System Configuration Dialog - Directories

There are three edit fields that specify directories: System, Incoming, and Outgoing.  Each of these fields specify a directory that will contain a certain type of information.  While it is often desired to keep these directories separate, this is by no means necessary.

The System directory is used as a starting point for all of the user mailboxes and for the configuration files for the auto-responders and for the Mailing Lists.  In this manner, all of the information regarding user accounts can be stored in this directory.  In a similar manner, the Incoming directory contains all of the files that need to be processed by the daemon, and the Outgoing directory contains all of the files that need to be sent to remote sites.


System Configuration Dialog - Options

There are a number of options that change the way in which the WinSmtp system will perform its duties, listed below.  Please note that certain options may be disabled in the unregistered shareware version.  The only way to enable those items is to register  the product.

Verify Incoming Hosts - If enabled, this option will check to make sure that verification is performed on a remote host requesting a connection.  Part of the connection process is to identify itself, and this identity is checked against the known node name and IP address for that node.  If the two values dont match, then a note is made in the log file so that the reception of an illegal message can hopefully be traced back to the originator of the message.

Do EXPD and VRFY -This option allows or disallows remote sites to use the SMTP EXPD and VRFY commands to determine the recipients on a given mailing list or to see if a specified user exists.

Check For Mail Subnets - This option affects the way in which the address resolution part of the daemon will search for addresses.  If the daemon is unable to find a MX record or an actual address for a given address, it is possible that the computer exists on a subnet that is only accessible through a gateway.  If this occurs, the daemon will try and check for subsets of the node name, removing the leftmost part of the node name and working right until there is no more node name left.

Use Proper Forward Reply - According to the SMTP specifications, a SMTP server may accept mail destined for addresses other than its own.  As a lot of other products wrongly return a response indicating that the specified user is local, a lot of client applications cannot handle a response indicating that the message will be forwarded to the specified recipient.  In most cases, the client application will report that the server has not accepted the recipient, where the server has really stated that the message will be forwarded.

Show Activity - This option enables the user to see information about the different states of the daemon and of the WRMail program.  If enabled, the daemon will report the number of incoming and outgoing connections and the wrmail program will place a visible icon on the screen for a couple of seconds, verifying that it executed okay.

Use ESMTP Protocol -  This option enables the use of the ESMTP protocol.  Standing for Extended SMTP, the ESMTP protocol adds some features to the SMTP protocol set.  The enabling of this feature is required in order to make some of the other options and settings work properly.

Verify Node At Startup -This options allows the daemon to verify the local node name and the local IP address.  If disabled, no verification will be performed on the values entered into the Local Node edit field and the Local IP edit field.  This is useful in cases where the node name and the subnetwork names are kept as two distinct entities, such as in NT.

Use ESMTP Size Option -This option allows the daemon to use the ESMTP SIZE option.  This option will limit the size of inbound and outbound messages to an agreed on limit.  The limit for the local daemon is specified in the Size edit field that is to the right of the Use ESMTP Size Option checkbox.

Broadcast ESMTP Size - This option will broadcast the maximum size allowed by the local daemon to the remotely connected system.  If this is done, the other daemon can make a quick decision as to whether or not the message is too big and will be rejected after it has been transmitted.

Force ESMTP Connect -This option forces an outgoing connection to try the ESMTP mode on a connection, downgrading to SMTP if the remote side will not accept the connection.  Otherwise, the daemon will try and recognize whether the server it is connecting to is in a SMTP mode or a ESMTP mode.


System Configuration Dialog

The following sections are part of the System Configuration dialog.  This dialog is available by selecting the System menu item, located in the Configuration submenu.

Local System Information  This section deals with information regarding the name of the current system and what systems it will connect up to in order to resolve names and messages.

Local System Directories  This section deals with the directories that will be used to define the system.

Local System Options  This section deals with various boolean options that affect how the system will perform.

System Aliases  This section deals with other names that can be used to reference this system.

Please note that the options set in this dialog are loaded up when the system starts, and as such require a restart of the daemon to reset these options.


Routing Options Dialog

The purpose of this dialog is to define the manner in which a given class of connections will be established.  This dialog is invoked from the Routing Dialog for either the General Setting for connections or for a specific exception to that setting.  Currently, this dialog has two sections: Routing and Retry Time-outs.

The Routing section is used to determine how to connect up to a given host or class of hosts.  The top three radiobuttons specify the manner in which the daemon will try and send the message.  The Send To Smarthost radiobutton specifies that the message should be sent to the smarthost without any checking done on the address of the message.  The Check First Record radiobutton and the Check All Records radiobutton will both check for the MX records belonging to the specified node name, but the Check First Record radiobutton will only try to connect to the first node name listed in the MX record.  The Send To Smarthost If Fails checkbox instructs the daemon to send the message to the smart host if sending to the node names specified within the MX records does not succeed.  Finally, the Use Default checkbox tells the daemon to use the General Setting for routing this exception.

The Retry Time-outs section allows you to set the starting level at which ant retries will commence.  By default, the Use Default radiobutton will be selected, deferring to the General Setting for Retry Time-outs.  Otherwise, one of the other values will be used.

Level	Retry Time-out	Number Of Retries
1	3 minutes	5
2	15 minutes	16
3	1 hour	48
4	2 hours	5 days


Routing Dialog

This dialog can be accessed through the Routing menu item, available under the Configuration submenu.  The purpose of this dialog is to define the manner in which connections with remote sites will be made, and what to do if that connection cannot be established.

This dialog is separated into two sections: General Settings and Exceptions.  The General Settings sections shows the current settings for connecting up with the Internet, and a button labeled Options that allows you to specify what the options will be.  Pressing this button will bring up the Routing Options Dialog, with some of the fields deactivated.  Please consult the above link to the Routing Options Dialog for information on the options and their effects on the system.

The second section is used for defining exceptions to the above rule and is only available to registered users.  These exception will modify the way in which connections are established to different systems.  This feature allows the user to specify one way of accessing nodes generically, and then other ways of accessing specific types or specific classes of addresses.  This is very useful in a firewall situation where most computers are not accessible, but some may be.

The exceptions are based on a decaying level of exactness.  This means that if the system is trying to determine what to do for a node of a.b.c.d, it will first look for a.b.c.d, then b.c.d, then c.d, then d, and finally it will use the default.  This structure allows you to specify a general exception for a given subnet, but to override that exception for a more specific example within that subnet.  Once again, this is useful in firewalls, as a general exception may be implied for computers behind the firewall, with a more specific exception for handling mail going to the firewall computer itself.

To the left of this section is a listbox containing all of the domain names that have exceptions defined.  To the right is a listbox for the domain name, with the buttons Add, Options, and Delete underneath it.  If the name of an existing exception is in the edit field, the Options and Delete buttons will be enabled, otherwise only the Add button will be enabled.  The Add button will add an exception into the system with a default set of attributes.  The Delete button will mark the current node as deleted, and will actually be deleted when the Routing Dialog is exited.  Finally, the Options button will bring up the Routing Options Dialog to change the routing options for the specified exception.


System Timing Dialog

This dialog can be accessed through the Timing menu item of the Configuration submenu.  The purpose of this dialog is to provide some control over the time-outs that are used within the system.  These settings will affect the way in which the daemon will interact with other SMTP systems on the Internet.

There are three values that may be changed through the use of scrollbars: Incoming Queue, Outgoing Queue, and Connections.  In addition, there is a button labeled Default that will enable you to set these values back to their default settings.

The first two time-outs effect how often the respective queues are scanned for new messages to process.  The Incoming Queue time-out determines how often the queue for messages coming into the system will be processed, while the Outgoing Queue time-out determines how often the queue for messages to be sent to other sites is processed.  Finally, the Connections time-out determines how long the system will try to establish a given connection before disconnecting.  Please note that this value is stored within the connection once an outgoing connection is started, so any changes to this value will only take effect with new outgoing connections.


User Accounts

The User accounts form the basis of most mailing systems.  It is with these accounts that users can get mail sent to them and have it stored in a mailbox.  When the system is started up, it makes sure that there is a user account named root, for all of the system messages.  The user account type configurable section contains four edit fields: User Name, Password, Mailbox, and CC To.

The User Name field gives the daemon a plain text name to tag onto the local address in outgoing messages.  This will overwrite any user names that are associated with the local addresses placed there using client packages.  The edit field associated with the Password label contains the password that it used to access the mailbox through the POP3 services.  As the password is protected, looking at this field will only allow a user to know how many characters are in a password, not what they are.  The password itself must be between 4 and 16 characters in length.

The Mailbox edit field is used to specify a file that will be the mailbox for the current user.  Simple checks are performed to make sure that it can create the mailbox and that the mailbox does not currently exist.  By default, this edit field will be filled in with the system directory and the first eight characters of the User Id, followed by a .mbx extension.  This filename can be generated again by clicking on the User radiobutton in the User Type radiobutton group.

Finally, there is a CC To edit field for the user accounts.  It is often necessary to permanently or temporarily forward mail received by a given account on to another system, while keeping a copy for local consumption.  This edit field allows for the insertion of a single user account into itself.  If you need to forward a copy of the mail to multiple users, it is suggested that you set up a mailing list account and forward the messages to the mailing list.


Alias Accounts

The Alias accounts provide a manner in which to redirect mail to another user.  In the user account type configurable section, there is a single edit field labeled Aliased To.  The text entered in this field must be a legal user on the local system.  To alias a user that is on a remote system, please use the Forward user account type.  Checking is performed on the alias user accounts upon startup to verify that all Alias user accounts resolve to a User account.  Care must be taken to avoid creating cyclic alias references, as this type of cyclic occurrences are not currently searched for.

When the system starts up, a check is made so that there is an alias set up from the user id listserv to the listserver responder for the mailing lists.  Also, there are varied aliases set up from certain user ids to the root account.


Forward Accounts

The Forward accounts provide a function very much similar to the alias user accounts.  However, the Forward accounts are used to alias accounts that reside on other systems.  No checking is performed for the legality of the address or the existence of the account on the remote machine, as it is assumed that this task is the responsibility of the users on those systems involved.  In the user account configurable section, there is a single edit field labeled Forwarded To.  The text entered in this field is used as an address to send the mail to.


Specifying Files To Retrieve From Auto-Responders

If an auto-responder is set up so that if the remote user needs to request files, then the remote user must form these requests in the body of the message sent to the auto-responder.  These requests have lines of the form:

send [mode=<mode>] <file identifier>

The optional mode portion of the request is used to determine what kind of encoding to be specified with the file to be sent.  The modes are plain, base64, and uuencode with the default being plain for text files and base64 for binary files.  The file identifier portion of the request is to determine which file to retrieve by using the identifier assigned to it.

Valid examples are:

send index

send mode=base64 my_picture

Please note that the requests made to an auto-responder are not case sensitive.


Edit Auto-Responder Items Dialog

This dialog is used to specify the various files that may be returned by an auto-responder.  At the top of the dialog is a File List listbox that displays a list of the current identifiers for files.  By selecting one of these identifiers, the appropriate information is reflected in the File Identifier edit field and the File Name edit field.

If the text in the File Identifier edit field does not specify an existing identifier, then only the Add pushbutton will be active.  The activation also depends on there being text in the File Name edit field.  If the specified identifier already exists, the Modify pushbutton and the Delete pushbutton will be active.  If a change is made to the File Name edit field, the Modify pushbutton needs to be pressed to make the change permanent.  If a given identifier is to be deleted, then the Delete pushbutton should be used.

Finally, the Browse pushbutton is used to access a common open file dialog.  The results of this dialog are placed into the File Name edit field.


Auto-Responder Configuration Dialog

This dialog is used to specify the configuration of a specific auto-responder.  To avoid clutter, this dialog will in turn call another dialog, to set the files that will be transmitted from that auto-responder.

The first two checkboxes in this dialog are labeled Send Files Only On Users Request and Send Files As Attachments.  If the Send Files Only On Users Request checkbox is checked, then the remote user needs to specify what files to send from the auto-responder.  Otherwise, the files that are specified for the auto-responder (in this case limited to text only) are sent in a concatenated form to the remote user.

Please note that in this case, a file with an identifier of first is sent before any others and a file with an identifier of last is sent after all others.  If the checkbox is checked, then the Send Files As Attachments checkbox is used to determine if the items will be sent as MIME attachments or as text with no encapsulation.

The next checkbox, Copy User With Messages is used to send a copy of the incoming messages to another user.  This is often used to make sure that there is no other text is present in the messages, or to simply log all of the incoming messages.  The Log Responses To File checkbox is used to log all incoming responses to a given file.  The format of this file is as follows:

<responder name>,<from address>,<time>,<response>

The file that this is saved to can be set using the Browse Response File pushbutton.  This will invoke the standard file open dialog to obtain the name of the file.  Below that is the Edit Responder Items pushbutton which will bring up the Edit Auto-Responder Items Dialog.  This dialog will allow the user to specify which items are accessible by the auto-responder, and this the user.


Auto-responder Accounts

The Auto-responder accounts require some specialized setup.  As the auto-responder account will be used to automatically respond (hence the name) to a users request for information, how this information will be sent needs to be configured.

There are two edit fields in the user account type configurable section: Responder Name and Configuration, and Owner.  The List Name edit field allows a human readable name to be associated with the mailing list.  This name should reflect the purpose of the mailing list in as few characters as possible while being readable.  This List Name will be placed in all of the messages that go out through the mailing list component of the system.

The Configuration edit field specifies a file that holds the configuration for the mailing list.  By default, this filename is constructed using the system directory, the first eight characters of the user id, and the .cfl extension.  A check is performed to make sure that the configuration file does not exist before it is accepted.  Access to this configuration file can be performed through the Show Configuration button that appears below the Configuration edit field.  This action will bring the user to the Mailing List Configuration Dialog.


Mailing List Configuration Dialog

This dialog is used to specify the configuration options for the mailing list.  It is broken down into two sections: List Options and Added Members Initial Options.  The List Options section contains options that will effect the list on a whole, where as the Initial Options section is used as a template for new users that are added to the list.

The first checkbox in the List Options group is labeled Closed Group.  If checked, this option will close the list so that only members of the list can post to the list.  The Moderated Group checkbox allows the list owner to have the power of moderation over the articles that are posted to the mailing list.  The Moderated Join checkbox is a similar concept, but makes the membership of the list closed so that a remote user wishing to join the list must get placed on a list of remote users wanting to be on the real list.  The list owner must then make a decision of whether or not that person should be on the list.

The Send Welcome checkbox controls whether or not a welcome file will be sent to the newly added members of the list, the welcome file itself being specified in the edit field below the checkbox.  The Send Footer checkbox works in much the same way, but it specifies a file that will be appended to the end of every mailing list message that goes out of the daemon.  Finally, the Send Copy Of Messages To List owner checkbox controls whether or not a copy of the message will be sent to the user who is defined as the list owner in the Mailing List accounts section of the Users Dialog.

The other section is the Initial Options section and it has checkboxes for Reproduction, Acknowledgment, and Concealing.  These items correspond to the similar items in the Mailing List Member Maintenance Dialog.  When a new member is added to a mailing list, they are added with these options.


Mailing List Accounts

The Mailing List accounts provide the ability to send a given message to a single destination identical copies will be sent to multiple addresses.  This is very useful in maintaining a list of the users of a particular product, a list of people with similar interests, or even to let everyone know where and when lunch will be on Fridays.

Adding a user to the mailing list may be accomplished in two different ways.  The first way is to use the Mailing List Member Maintenance Dialog as the list owner or as the system administrator and manually add the user information.  The other way is to use the listserver commands to send a request to the listserver account for the node that maintains the list and ask it to add you to that mailing list.  In this case, you may have to go through a moderator in order to get added to the list.

There are three edit fields in the user account type configurable section: List Name, Configuration, and Owner.  The List Name edit field allows a human readable name to be associated with the mailing list.  This name should reflect the purpose of the mailing list in as few characters as possible while being readable.  This List Name will be placed in all of the messages that go out through the mailing list component of the system.

The Configuration edit field specifies a file that holds the configuration for the mailing list.  By default, this filename is constructed using the system directory, the first eight characters of the user id, and the .cfl extension.  A check is performed to make sure that the configuration file does not exist before it is accepted.  Access to this configuration file can be performed through the Show Configuration button that appears below the Configuration edit field.  This action will bring the user to the Mailing List Configuration Dialog.

Finally, the Owner edit field allows the user to specify an owner of a given mailing list.  Currently, the list owner does not have any extra privileges, but in the next release of the WinSmtp software, there will be some facility for the remote maintenance of mailing lists.


System Users Dialog

This dialog is accessible through the Users menu item, available under the Configuration submenu.  The purpose of this dialog is to perform maintenance on user accounts.  The main focus of this dialog is a listbox titled Users and an edit field titled User Id.  Below this is a group of radiobuttons that identify what type of a user account is to be set up.  The valid types are: User, Alias, Responder, Forward, and Mailing List.  Below this is an area that changes depending on the type of user account that is being modified.

At the bottom of this is a section that has three buttons titled Add, Modify, and Delete.  If a new user account name is specified in the User Id edit field, then the Add button is enabled and the Modify and Delete buttons are disabled.  Otherwise, the Add button is disabled and the other two buttons are enabled.  The Add button will add a new user of the specified type and user id into the system.  Similarly, the Delete button will remove the User Id and all associated information from the system.  The Modify button is used to save changes in the user account type dependent area.  If this Modify button is not pressed prior to selecting a new user account, the information that has been entered up to that point will be lost.

As was mentioned earlier, there are five types of users:

User accounts

Alias accounts

Forward accounts

Auto-responder accounts

Mailing List accounts


Register Dialog

This dialog is used to provide the Wildbear Consulting staff with the information necessary to register the product for you.  There are four edit fields that are used to accomplish this goal.  They are the User field, Organization field, the Program Code field, and the Register Key field.  The first three fields are automatically filled in for you, and it is these fields that you need to pass on to register the product.  Please make sure that you specify these fields exactly, as any small change will invalidate the registration process.

When the product is registered, you will receive a Registration Key.  These key needs to be entered in the Register Key field for the registration to work properly.  Once again, please make sure that the information entered is copied exactly.  When finished, you complete the registration process by hitting the OK button.  If successful, a message box will come up with the text Registration Successful.  Otherwise, there will be a message box that says Registration has failed.


Registration Information Dialog

This dialog is accessible through the Registration Info menu item, available under the Help submenu.  The purpose of this dialog is to allow you to register you version of the product.  To register the product, you will need to go to the Register Dialog to get the information needed to fill out the form that you will need to print out.

There are two buttons located on this dialog.  The View Registration Form button will invoke the Notepad application with the form to be used to register the product.  Unless an exception is made by one of the Wildbear Consulting employees, this form must accompany the cheque or money order for your registration.

The second button is labeled Register, and will bring up the Register Dialog.  It is very important to note that any information to do with registration must be reported or entered exactly as shown.  If the information is not reported and entered exactly as specified, the registration process will fail.


List Server Commands

The following is a list of commands that may be sent to the listserver account.  This account is used as a control channel for all mailing lists that are maintained on a given server.  If necessary for a given command, the name of the specific mailing list will be specified as the first parameter after the command word.  In this case, the list name will be specified in the description of the command as <list name>. This special responder, like the other responders, is not case sensitive.

subscribe <list name> <user name> - This command will subscribe a user to the specified list.  If the list is a moderated add list, then the request will place the users information in the pending submission area of the mailing list.

unsubscribe <list name> - This command will unsubscribe a user from the specified mailing list.

set <list name> <option> - This command sets the options for the user.  These are the same options that are accessible through the Mailing List Members Dialog.

query <list name> - This command is the reciprocal of the set command and is used to query the listserver on the senders current options.

review <list name> - This command is used to generate a listing of all the members of a list.  The list that is generated reports the addresses and names of all members that are not concealed, followed by a count of those users who are concealed.

info [commands | lists ] - If no suboption is specified or if the commands suboption is specified, then the command listing file listrcrd.txt (stored in the same directory as the executable) is sent back to the sender.  Otherwise, if the lists subcommand is specified, then a list of all the mailing lists on the current server is sent back to the sender.

subs - This command queries the listserver to determine which lists the sender belongs to and to send a small report back to the user.


RFCs Used By This Product

Currently, the WinSmtp product adheres to the following Internet RFCs:

RFC 821 - Simple Mail Transport Protocol

RFC 822 - Internet Mail Format (types of addressing)

RFC 876 - Survey of SMTP Implementations

RFC 1123 - Requirements for Internet Hosts

RFC 1460 (obs 1225) - Post Office Protocol - Version 3

RFC 1651 (obs 1425) - SMTP service extensions (ESMTP)

RFC 1653 (obs 1427) - SMTP Extension for Message Size Declaration

In addition, this product uses a non-registered extension to the ESMTP protocol.  The Extended Turn command was added to allow for some extra flexibility in the product.  The above link gives a detailed description of this extension.

If there is a new RFC that relates to this product, every effort will be made to adhere to the specification as soon as we are aware of it.  In addition, if you wish to have other mail related features added to this product, please let us know about your request and we will attempt to fulfill it if time allows and if we feel that its feature set will compliment the product.


SMTP and POP3

The two protocols used extensively by this product are the SMTP protocol (and its modifications, the ESMTP protocol) and the POP3 protocol.  While a full description of those protocols is left up to the reader, here is a brief summation.

The Simple Mail Transport Protocol (SMTP) is used to shuttle mail messages between one site and another site.  While the protocol has a host identification stage, a positive verification of a remote hosts identity is not required to accept a message.  It is assumed that any host will accept any message, unless there are timing or size constraints on the receiving host.  The rest of the SMTP protocol deals with specifying the sender, recipients, and body of the message to be sent.

The Extended SMTP (ESMTP) protocol was developed as an upgrade to the SMTP protocol.  This protocol relies on the SMTP protocol, but adds extra features to the base protocol.  These features include a feature broadcasting ability as well as specifications on how to add new features to the protocol.  Along with the release of the ESMTP protocol were the release for the 8BITMIME feature and the SIZE feature.  In addition, the stipulation for using new features not covered in a RFC are followed in the documentation and use of the XTRN or Extended TURN command.

The POP3 protocol is the third in a series of protocols designed solely to retrieve mail messages from a given mail drop.  In creating a client to access a mail drop, it is important to note that since POP3 can only be used to retrieve messages, another protocol such as SMTP is needed in order to send messages.  While the POP3 protocol seems pretty simplistic, it can be used for both online and offline reading of a mail drop.


Extended TURN command

Due to the inability of the standard SMTP or ESMTP protocol to deal with transient connections to the Internet, it was necessary to implement the XTRN command.  The SMTP protocol does contain a similar protocol, the TURN command.  However, the current definition of this command has a flaw that would allow someone to sign on to a given SMTP node and request the messages for a specific node.

The TURN command operates by changing the message flow on a given connection so that it appears as if the destination node had called the originator.  However, this command is performed regardless of any security checks saying that the specified node is invalid.  This is where a knowledgeable user could gain access to someone elses messages.

The XTRN command is an improved version of this command, available only in an ESMTP mode as it is an extension to the protocol.  Instead of reversing the flow of the connection, the XTRN takes as an argument the name of a node to retry.  Since there is a new connection created from the daemon, a connection that would automatically be generated when the retry time-out occurs for that given node.  The decision as to whether or not a given mail node is allowed to start the retry for a given node is up to the daemon that receives the XTRN command.  Currently, WinSmtp does not perform any such check.  This command is allowed at any stage of the ESMTP connection as soon as the identity of the other node is known and verified.

If you have any questions about the XTRN extension to the ESMTP protocol, please contact us at winsmtp@wildside.kwnet.on.ca and specify a subject of XTRN.


MX Resolution Module

The MX resolution module allows the daemon to find information out about where to send mail for a particular node.  Most sites broadcast address information, MX records, and CNAME records.  Combined, these types of addressing allow a mail node to specify its IP address, a list of computers to contact for that node name, and a redirection for that node name.  The ability to request this information from a name server and to understand the implications and organization of a response to that request is imperative to understanding where to send a given mail message.


MX Records

MX records are used to redirect mail over the Internet.  Standing for Mail exchange records, these records exist on certain systems and may be queried for information on how to deliver mail to a given node.  A typical MX record will be used to specify multiple sites where mail can be delivered for a given node.  These records are acquired through the use of a name server.  A typical entry for a MX record for a given node, foo.com, may be as follows:

foo.com	0	mailhost.foo.com

foo.com	10	mailhost.bar.com

foo.com	20	mailhost.foobar.com

mailhost.foo.com        1.0.0.1

mailhost.bar.com        1.0.0.2

mailhost.foobar.com     1.0.0.3

In this example, there are three entries in the MX record.  If at all possible, mail will be delivered to the node mailhost.foo.com with an address of 1.0.0.1.  If the mail daemon that is sending the mail is unable to contact that node, then it may attempt to send the mail to one of the other nodes listed in the MX record.  If this occurs, it must try the nodes in ascending order.


CNAME Record

CNAME records are used on the Internet to redirect an MX record to another name.  It is often the case where a computer name mailhost.somenode.com is being used as the mail node for the somenode.com domain.  In this case, it is sometimes necessary to place a CNAME record from one name to another.


Smart Hosts

Smart hosts exist to allow mail daemons to pass mail messages to another computer that perhaps knows more about the network than it does.  They also exist in order to allow for the operation of Firewalls.  A smart host is a mail node that is supposed to be smarter than the mail node you are currently using.  In a typical situation, any given network will have many computers, the smart hosts for a given node being a mail node higher up in the hierarchy of the network.

While the importance of a smart host has dwindled with the advent of direct connections and MX records, the concept of having an authoritative source to send mail messages of seemingly unknown destination to is still valid and useful.  For reasons of economy, efficiency, or implementation, there is often a single smart host or a single group of smart hosts that service a given domain.  While this may induce some congestion at the selected mail node, this congestion may be offset by the centralized processing of the mail messages.


Name Servers

A name server allows other computers to connect up to them using the port reserved for Domain Name Services, and to ask them information about names for machines within their domains and other domains.  Typically, a system has a name server that is used to submit these requests to.  If that request cannot be fulfilled locally, the name server will seek out a response for that request itself.  In this manner, the request can get processed by many systems, but only one session with a name server is required. In addition, most name servers will cache information regarding previous requests.  Therefore the first request may take some time, but subsequent requests (within a given frame of time) will already be at the name server and thus those requests will finish more quickly than the previous request.


The daemon reports my name as 'foo' when it should be 'foo.bar.com'.

Because of the WinSock API does not allow a node to obtain information through the API about the domain in which a node exists, it is very difficult to obtain the full name of a given node as the WinSock API will only return the local node name (without a domain name).  To solve this problem, go to the System Configuration dialog and enter the proper node name and the proper IP address in the appropriate edit fields.  Then go to the checkboxes at the bottom of the dialog and make sure that the Verify Node At Startup checkbox is not checked.

Note that having the Verify Node At Startup checkbox in the unchecked state will not check the node name or the node IP address upon startup and may cause problems if incorrect values are entered or if the values change and the field is not updated.


My computer name is 'foo.bar.com' and I want to process the mail for 'bar.com'.

Most companies and educational institutions have many computers that are on the Internet, only one of which usually receives the mail intended for the company.  These machines are most commonly named mailhost.bar.com or mail.bar.com, signifying that they are the machines that are supposed to receive the mail.

As this is an arbitrary decision, and can only be ascertained by looking at the MX records, there was a need to make sure that this was handled by the daemon itself.  This problem can be solved by using the system aliases.  If you want the local node to look like foo.com, place foo.com in the outgoing aliases edit field.  If you want the daemon to accept mail for foo.bar.com without making it look like foo.bar.com, place it in the incoming aliases edit field.  Note that there may be multiple incoming aliases (separated by semi-colons) but only one outgoing alias.


Mail is coming in to my computer and it never seems to put it into a mailbox.

This problem usually indicates that what you think is the node name and what the computer thinks is the node name are different.  This is very often caused by a single computer receiving mail for a multiple computer network.  In this case, you want to use system aliases to tell the daemon that you want your computer to do some extra checking for other names.


Troubleshooting System Node Configuration

This is a list of commonly asked questions regarding setting up a mail daemon and the associated bureaucracy.

Problem: The daemon reports my node name as 'foo' when it should be 'foo.bar.com'.

Problem: Mail is coming in to my computer and it never seems to put it into a mailbox.

Problem: My computer name is 'foo.bar.com' and I want to process the mail for 'bar.com'.


Product Disclaimer

The author is not liable for any damages, expressed or implied, caused by the use or misuse of this software.  Commercial use of this product is illegal without the express consent of the author.  Use of the shareware version of this product is allowed for a period of 90 days as an evaluation period for the software.  Continued use of the product after that time without registration is illegal.

Distribution of the shareware version of this product for private use is permitted with the provision that all of the files contained in the distribution archive are distributed together.  Distribution of the commercial version of this product or a non-personal distribution of the shareware version of the product without the express permission of the author is illegal.

With regards to any questions concerning permissions to distribute this product, in its commercial or shareware form, the author shall have the ability to set out these policies and change them at any time, except where legally bound by a legal contract, written or spoken.

Any warranty, either implied or defined by law is void if this program is tampered with in any way shape or form.  To get more information about this and other products, contact your supplier or the owner of this program, Wildbear Software, at winsmtp@wildside.kwnet.on.ca.


Introduction

This product is intended to provide SMTP and POP3 services  to a SMTP or POP3 client.  In addition, there are routing services, mailing list services, and auto-responder services that are included to make the daemon more useful.  To make this product easy to use, there is a workstation based configuration interface that allows a user to interactively change the system.

While all efforts have been placed into this program to make it as easy as possible to set up, the sheer number of possibility precludes capturing all of them.  However, as more people use the product, we gather more information on problems that can occur when setting up the system.  These problems and their solutions are documented in this file for your reference.


Product Description

WinSmtp is a small product with a ferocious roar!  Able to run on a Windows machine with a Windows Sockets (WinSock) interface, this product transforms your Windows machine into a fully operational mail node on the Internet using the SMTP protocol.  In addition, this product uses the POP3 protocol to allow users to access their mailboxes from computers other than the one on which the daemon itself is running.  To facilitate the process of moving the messages to other  SMTP nodes and the POP3 mailboxes, this product also includes the processes necessary to route mail messages.

In addition, there was a strong argument for implementing two additional processes, auto-responders and mailing lists, into the WinSmtp daemon itself.  Therefore, these processes are part of the daemon itself, eliminating extra processes running on your computer system.


Product Features

As described in the section on product description, the WinSmtp SMTP daemon is more than just a simple SMTP daemon.  It also includes a Mx Resolution module that allows the daemon to query the specified name server for information on where to deposit mail for a given computer.  To make it practical to run on Windows systems, the POP3 services, routing services, mailing list services, and auto-responder services were added.  In addition, the daemon provides a very clean, easy to use interface to these functions.  With the feedback that we get from users, we try and improve the feature set and the user interface.

The product adheres to a number of Internet RFCs.  These RFCs are used by many computers over the world to define how the computers talk to one another and exchange information.  Adherence to these protocols gives you the assurance that this product will be able to talk with other computers and to exchange mail messages with them.

In addition, the following features of the product should be pointed out:

integrated auto-responder and mailing list support

fast and friendly product support over the Internet

user input into the future features of the product

easy to read status screen, with output relayed to a log file.

outgoing mail support though a rmail like interface

access to incoming mail in mailboxes though the UNIX mailbox type format in addition to the POP3 server support

configurable connection methods, and the ability to specify groups of connections based on the node or class of nodes

If you require any information on this product, or any of our other products, please send mail to our auto-responder at info-wildbear@wildside.kwnet.on.ca for a quick reply.  If you need to talk to someone regarding the product, please send mail to wildbear@wildside.kwnet.on.ca or for information specifically on WinSmtp, please send mail to winsmtp@wildside.kwnet.on.ca.


Company Information

Wildbear Consulting is a small company specializing in communications solutions and quality Windows software.  Our emphasis is on building a good software infrastructure, and standing firmly beside the products that we support.  By maintaining a small size and a low overhead, we hope to reduce the costs to the end users.  However, this may sometimes lead to small delays, also attributable to our small size.  This also allows us to have a good rapport with our clients, a rapport that we feel is invaluable.

For information regarding our current products, our company, or questions that are closely related to our products, please feel free to talk to us about it.  For this and any more information, please contact us through electronic mail at wildbear@wildside.kwnet.on.ca or send us postal mail at:

Wildbear Consulting

8-589 Beechwood Drive,

Waterloo, Ontario, Canada

N2T 2K9

If you wish a reply by postal mail, please enclosed a SASE (Self Addressed Stamped Envelope) with your request for information.  Otherwise, all responses will be issued through electronic mail.


Firewalls

Firewalls are named after the concrete walls that are used in buildings to prevent flames from spreading to many parts of the building unhindered.  On the Internet, it is sometimes desirable to make all of the traffic for a given company or network go through a single node.  Often for security reasons, these firewalls usually allow people from inside to get out, but prevent people from the outside getting in.


daemons

A daemon is a process that waits around for something to happen before taking action.


Retrying Messages

It often occurs that one daemon may not be able to forward mail effectively to another daemon.  In this case, there is a mechanism set up to try and establish the contact at a later time.  This is known as a retry, and the collections of objects upon which this action needs to be performed are referred to as retries.


Requests For Comments (RFC)

On the Internet, there are many protocols being used.  To keep track of and to document these protocols so others may implement them, all Internet protocols have one or more documents written about them.  These documents are referred to as RFCs because the protocols are continuously evolving as comments about the protocols are received by the authors.  Currently (as of March 17, 1995) there are over 1800 RFCs.


binary files

A binary file is a file that contains characters with the high bit of an 8 bit character set, with some exception.  The standard US ASCII range of printable characters includes the Carriage Return, the Line Feed, the space character, letters, numbers, and punctuation.  If any characters outside of this range are detected in the first 512 bytes of the file, the file is assumed to have binary content.


Autoresponders
auto-responders

An auto-responder is a mail process that automatically responds to a users request for data.  Most often, an auto-responder is set up to respond with information about a given organization or a given product.


mailing lists

A mailing list is a collection or list of mail addresses.  A mailing list is usually formed on a common theme, such as information about a given product, a given type of entertainment, or a given type of socialization.