Program Descriptions

This reference section relates to version 2.10 of NTMAIL. Previous versions are available.

1 SMTP Service

This is the most complicated part of the set of mail servers. This service waits for incoming mail from any source. It checks the mail as it comes in to work out whether it is mail for a local or remote destination. Once the mail has been received, it will be written to either a local mail box or re-send queue. SMTP can be configured to accept any mail for the local domain and place it into a specific local mailbox. This is useful if you simply want to accept any mail arriving at your machine.

The SMTP Service can handle an indefiniate number of mail boxes with up to 30 aliases each. This means you could set up a mail box for "david" which will receive mail to "dave" or "david". It can also handle an indefinate number of "receivers" of the same mail message (e.g. when you select multiple receipients of the same mail message or Carbon Copies in your mail client). In this case the mail message is broken up into lots of individual mail messages then each message is treated individually.

Mail message length is limited by the system, not the program, therefore MIMEd email messages of several MB are not a problem.

SMTP can log the source (claimed and real), destination and size of all mail messages it handles. This can be useful for spotting unusually high use of the mail service by individuals within an organisation.

The Service is multi-threaded. This means that the service can handle multiple connections from other mail servers at the same time and distribute the messages correctly. The number of threads is configurable although we have only five. The SMTP service also provides all the list server functionality. You may set up a "list manager" which will accept the JOIN, LEAVE and HELP commands. The list manager may control one or more lists. When a user mails a list, the mail is duplicated and forwarded to every member of the list. The people who can join and post to a list may be resitricted or left open. This allows several different types of lists to be created:

2. POP Service

The Post Office Protocol Server will accept connections from all remote clients and then insist on username and password being correct before details of mail are released. Each time a username and password are incorrect the details are logged. Note that two users with different usernames and passwords may have access to the same mail box (if that's how you want to set it up). In addition POP will automatically encrypt passwords so that they cannot be read directly from the registry.

On successful connection the entire mail box is read and re-written after the POP Server has finished with it. While the mail box is held for reading, no mail can be accepted for the user (but it will not be lost since the sending post will try again later).

The POP Server is multi-threaded. This means that more than one client can access the mail at the same time. The number of threads required is surprisingly small since most clients take about 0.5 seconds to check the mailbox and only do it every (say) 10 minutes then potentially you could have 10*60*2 = 1200 clients using only one POP thread. Obviously you are going to run into problems at that point especially if you have some clients on a slower network connection (e.g. PPP or SLIP). Therefore we suggest five threads and if you have complaints, simply increase the number!

3. POST Service

The post daemon handles all out going mail. It checks the directory for messages that have yet to be sent, reads the destination of the mail and then attempts to connect to the destination mail server. If it fails, it will try the gateway. Once a connection has been made the mail will be sent onbound. Any error after the connection has been made (e.g. User unknown) will cause the message to be re-routed back to the message source with the error message inserted to inform the sender of the mail. (If this has already happened, we have infinitly bouncing mail, so the POST services will re-route the mail to the root account).

The post daemon can be configured to attempt to send mail on any (or none) of the following events:

We recommend having the Timed option set to (say) 9 minutes.

POST is multi-threaded and the most difficult to configure regarding the optimum number of threads. The optimum number of threads depends upon your link to your outbound mail server. If you have a low speed link (e.g. 64Kbaud) you will need to have fewer threads because you may have a couple of large mail messages waiting and each will time out. If there is no link restriction - this is not a problem! We recommend three POST threads for a 64Kbaud line and five otherwise.

4. MAIL Utility

This program will perform lots of different actions all to help with the running of NTMAIL. There are several diagnositic options (look up MX and CNAMEs), a mail-to option, an option to get the services to re-read the registry, load the registry from a script file and lastly some routines for helping with dialup connections. The MAIL utility will accept a sequence of commands and work though them one after another.

5. NT PULLMAIL V1.0

PULLMAIL is a simple command line utility to pull email from a pop account and send it to an SMTP server. It looks for a To: or Apparently-To: field in the header of each email and uses this in the RCPT-TO command to the SMTP server.

"PULLMAIL was originally written by Mark Woollard of 7th Wave Software Ltd. to interface NTMAIL with Frontier Internet Services Ltds email forwarding system. Mark has now produced a general purpose version suitable for use with any POP based internet service provider.

For further information and support for PULLMAIL please email pullmail@swsoft.co.uk. For details of Frontier Internet Services Ltd. email info@ftech.net or take a look at http://www.ftech.net"


webmaster@net-shopper.co.uk (12th May 1995)