<![CDATA[
<!-- BEGIN HEADER -->
<body
style="font-family: Verdana, Arial; font-size: smaller">
<table border="0" cellspacing="0" width="520" cellpadding="2">
<tr>
<td><!-- END HEADER --> <!--webbot bot="Include" startspan tag="BODY" u-include="general.htm" -->
<table border="0" cellspacing="0" width="520" cellpadding="2">
<tr>
<td> <p align="center"><b><img src="dp_icon1.gif" width="32"
height="32"> The <a name="_Toc391887987">DMail Email
Server</a>s <img src="dp_icon2.gif" width="32"
height="32"></b></p>
<p align="center"><b>Users Manual</b> </p>
<p>This manual describes DPOP (a POP3 mail server), DSMTP (an SMTP mail server), and DList (an
email list server). Together they provide a complete email server solution for small and
large internet and intranet service providers.</p>
<p>DPOP is a highly efficient scaleable POP3 mail server which operates as
a single process, and can handle a large number of concurrent email client sessions. It is
a drop-in replacement for popper and other POP3 servers. It provides an efficient and
scaleable solution for email providers. It places no unnecessary limits on concurrent
connections, though smaller systems may opt to limit concurrent connections to a few hundred.
The total number of user or client email accounts may be limited by the type of license.
(for example <5, <50, <500 or unlimited versions are available) Systems with
500,000 client accounts and many hundreds of concurrent connections are quite achievable,
even with relatively modest hardware.</p>
<p>DSMTP is an efficient and scalable SMTP mail delivery server. It
operates as a single process and can handle a large number of concurrent connections. It
is a drop in replacement for sendmail. It works with DPOP in order to provide a complete email
solution. When a user sends email, their email client package connects to an SMTP server
(DSMTP). If the email is for a local user, DSMTP writes directly to the dropfile, if the
email is for a remote site then DPOP will connect and transfer the email as required.</p>
<p>DList is an easy to use and efficient email list server. It allows
mailing lists to be easily setup and maintained. It can be entirely controlled via email.
A Web based manager for the DList administrator and email list moderators will be
available shortly.</p>
<p><a href="contents.htm" target="main_info"><b>Table of Contents:</b></a></p>
<blockquote>
</blockquote>
<hr>
<p><a name="Introduction to Internet Mail Servers"><b>Introduction to
Internet Mail Servers</b></a></p>
<p>The provision of internet email depends on a number of software
components working together. These days, most email users access email by running an email
client application such as Eudora or Pegasus mail on a personal computer. This client
application talks to two server applications which are normally located on a host machine
which is run by an internet service provider or local computer service group.</p>
<p>In order to provide internet email to computer users, three applications must work
together - the client, the collection server and the delivery server. The collection server
is what an email client connects to in order to collect or read the user's email. The
delivery server is what the client connects to when it wants to send a message. </p>
<p>An email client sends outgoing mail to an SMTP server which transfers
the mail to other SMTP servers and eventually one of them stores it on the machine from
which the client will read it. DSMTP is Netwin's SMTP server product. It would often
replace applications such as sendmail.</p>
<p>The most common collection servers use the POP or POP3 protocol when
interacting with the client. Such a server is referred to as a POP server. DPOP is
Netwin's POP3 server product. It would often replace applications such as popper, or
qpopper.</p>
<p>A fourth optional component of most email systems is an email list
server. Email lists are lists of email users to whom you can send messages as a group. For
example, you might have a group of users who are all part of the social club organizing committee.
When discussing the organization of social events via email, you need to be able to send
messages to all of the committee members. This is sometimes handled by a simple list of
email addresses stored on the users PC within the email client software. This is very
inefficient in that the same message is sent repeatedly from the client PC to the host
server and then perhaps from there to various other sites. A more efficient method is to
have a list server running alongside the mail server. It accepts messages for a pseudo
user named social_cmty, for example, and passes them on to all users listed on its social
committee list. This avoids the need to repeatedly send messages, and avoids the need for
the users to all maintain a list of people on the committee. It can also provide other
features such as an archive of emails to the list, a set of shared files which list
members can download etc. DList is Netwin's email list server product. It would often
replace such applications as majordomo.<br>
</p>
<p>Traditionally, the various parts of the email server family, particularly
on Unix platforms, have not been designed with efficiency in mind. Email was traditionally
short text messages, and the number of users small. Each connection was a sort of pseudo
login starting a new process up and interacting with the client software. With much larger
numbers of users and larger email messages which often contain file and image attachments,
more efficient systems are required. The management of the components of an email server
system, and the gathering of usage statistics were also problematic. The setup and
maintenance of mailing lists was often sufficiently complex as to deter many small groups
of users from using real mail lists. The NetWin suite of mail products; DSMTP, DPOP and
DList were designed to overcome these limitations, and to allow the hosting of complete
mail systems on quite modest hardware. The ease of management of email servers was also
paramount in the design.</p>
<hr>
<p><a name="Controlling the DPOP Server"><b>Controlling the DSMTP/DPOP
Servers</b></a></p>
<p>Following installation, various options and settings can be adjusted to
tailor DSMTP and DPOP to your specific requirements. You may also want to check on the
current status of the servers in order to see how many connections are in use etc. </p>
<p>In addition to the settings in the configuration file, command line utilities Tellpop and Tellsmtp are provided for such management tasks on each of
the servers.
Of special note are the 'reload' commands, on both utilities, which cause the server
specific to that utility to reload the configuration file without having to restart, e.g.
'tellpop reload' makes DPOP reload the configuration file.</p>
<p>Alternatively, both of the configuration settings and the commands to the server
can be managed with the DMAdmin utility, which also controls all three servers.</p>
<p><a href="general.htm#dpop manager" target="main_info">DMAdmin:</a></p>
<p>DMAdmin is a graphical user interface for controlling DSMTP/DPOP/DList
and their configuration settings. It runs on the Windows 95 or Windows NT platform. It is
automatically installed and then started by DMSetup on these platforms. It can also be
used to control a <a href="general.htm#DMAdmin-Unix">Unix</a> version of DMail/DPOP
remotely. </p>
<p><a href="tellsmtp.htm" target="main_info">Tellsmtp Command Line Utility</a></p>
<p>A command line application. This runs on all systems and provides a
quick and simple method of controlling and monitoring DSMTP. </p>
<p><a href="tellpop.htm" target="main_info">Tellpop Command Line Utility</a></p>
<p>A command line application. This runs on all systems and provides a
quick and simple method of controlling and monitoring DPOP. </p>
<p>NOTE 1: Initial installation and setup of DSMTP and DPOP is best handled
by the DMSetup wizard. Tellpop, Tellsmtp and DMAdmin are for later fine tuning etc.</p>
<p>NOTE 2: Modifying a dmail.conf setting which is relevant to both DPOP
and DSMTP requires you to reload <strong><u>both</u></strong> servers individually with
their reload configuration file commands, e.g. tellsmtp reload <strong><u>and</u> </strong>tellpop
reload. DMAdmin will do this automatically.</p>
<p><a name="Controlling the DList Server"><b>Controlling the DList
Server</b></a></p>
<p>Following installation, various <a href="dl_set.htm" target="main_info">DList
options and settings</a> can be adjusted in order to tailor DList to your specific requirements.
You may also want to create additional mailing lists and check on the status and use of
current lists. To perform such tasks you edit the configuration files appropriate to
DList, dmail.conf and lists.dat or use the DMAdmin utility, which will do the editing for
you. Simple administration of lists, e.g. subscribing someone to a list, can also be
carried out by sending messages to a list request address,see the <a href="Dl_cmds.htm"
target="main_info">DList mail commands</a> page, in particular the <a
href="Dl_cmds.htm#NOTE to Moderators:">Note to Moderators</a>. </p>
<p><a href="general.htm#dpop manager" target="main_info">DMAdmin:</a></p>
<p>DMAdmin is a graphical user interface (GUI) for controlling
DSMTP/DPOP/DList and their configuration settings. It runs on the Windows 95 or Windows NT
platform. It is automatically installed and then started by DMSetup on these platforms. It
can also be used to control a <a href="general.htm#DMAdmin-Unix">Unix</a> version of
DMail/DPOP remotely. See <a href="general.htm#dpop manager" target="main_info">DMAdmin:</a>
for more detail.</p>
<p>dmail.conf</p>
<p>The DList list server settings are held in dmail.conf, some are in
common with the other two servers, e.g. log_path, but those given in the summary list <a
href="dl_set.htm#dlist settings in dmail.conf:" target="main_info">DList settings in
dmail.conf</a> are specific to DList only.</p>
<p>lists.dat</p>
<p>Management settings for who may be a moderator, who may join a list and
other <u>list specific</u> settings are edited in the <a
href="dl_set.htm#list specific settings" target="main_info">lists.dat</a> file.</p>
<p>NOTE 1: All settings can be changed by directly editing the <a
href="dl_set.htm#dlist settings in dmail.conf:" target="main_info">DList settings in
dmail.conf</a> or the <a href="dl_set.htm#list specific settings" target="main_info">lists.dat</a>
file in a text editor. Alternatively, the DMAdmin GUI server management utility will do the
editing for you.</p>
<p>NOTE 2: Initial installation and setup of DList is best handled by the <a
href="install.htm#The DMSetup Wizard" target="main_info">DMSetup</a> wizard. DMAdmin and
direct editing are normally used for later fine tuning and creation/modification of
mailing lists.</p>
<hr>
<p><b><a name="dpop manager">DMAdmin</a><i> </i></b></p>
<p>DMAdmin is a graphical user interface for controlling DSMTP, DPOP, DList
and their configuration settings. This will be available for Windows 95 and Windows NT, but
can also be used to control Unix versions remotely.</p>
<p><a name="DMAdmin-Unix">Unix</a> installation</p>
<p>Copy dmadmin.exe and dmail.hlp to your PC using a 'binary' transfer
mode. Install it in a DMail subdirectory and then add it to your button bar in the usual
way. The default directory should be set to c:\dmail or wherever you installed it on your
PC.</p>
<p>Using DMAdmin remotely</p>
<p>First you must set the DMail administration password. In order to do this, type in
on the actual machine running DMail:</p>
<blockquote>
<p>tellpop password xxxxxx (replace xxxxxx with a
password)</p>
</blockquote>
<p>Then in DMAdmin you can select your mail server as the host to
administer and type in the same password. Then it will be able to control your mail server
remotely.</p>
<p>Screen Shot</p>
<p><img src="genera1.gif" width="520" height="341"></p>
<hr>
<p><a name="log file"><b>Logging of information and error messages:</b></a></p>
<p>Various informational messages are logged during the normal operation of
the DSMTP, DPOP and DList servers. These events logged include such things as server
startup, creation of work files , rejection of connection request etc. These messages
appear in separate log files for each application; dpop.log for DPOP, dsmtp.log for DSMTP
and dlist.log for DList</p>
<p>When the log file exceeds a preset maximum size it is renamed and a new
file is created. For example, dpop.log becomes dpop1.log This is referred to as log file
rotation. For DPOP, four old log files are kept - dpop4.log is the oldest and dpop.log is the
current log file.</p>
<p>The path for the log file is normally the same as the work directory but
can also be set individually in the configuration file using the log_path setting. For
Example:</p>
<p>log_path \data\logs</p>
<p>In addition, error, warning and debug messages can optionally be stored
in the log file. The level of information logged is set by the log_level setting in the
configuration file.The available settings are shown in the table below: </p>
<table border="3" cellspacing="4" width="400">
<tr>
<td>error</td>
<td>only logs error messages</td>
</tr>
<tr>
<td>warn</td>
<td>logs warning messages and error messages </td>
</tr>
<tr>
<td>info</td>
<td>logs informational messages and error messages</td>
</tr>
<tr>
<td>debug</td>
<td>logs debugging messages, informational messages and error messages</td>
</tr>
</table>
<p>The default setting is <strong>info</strong>. The log_level setting may
also be changed temporarily using the Tellpop or Tellsmtp <a
href="tellpop.htm#log_level cmd" target="main_info">log_level</a> commands:</p>
<blockquote>
<p>e.g. <strong>tellpop log_level info </strong></p>
</blockquote>
<p>The logging level will revert when the system is restarted or when the
configuration file is reloaded.</p>
<hr>
<p> </p>
<p><a name="Controlling client access"><b>Controlling client access to
DPOP </b></a></p>
<p>DPOP provides a variety of methods for limiting access from clients
trying to read mail. </p>
<blockquote>
<p>First the client must use a valid username. This is limited by a
wildcard list of valid names in the configuration file. </p>
<p>There must be a drop file for that user. </p>
<p>The username/password combination must be valid. This can mean a valid
Unix or NT user/password. A variety of other methods for checking this combination are
provided for and controlled by settings in the configuration file. An external
authentication routine can also be used, see authenticate settings in configuration file.</p>
<p>The from address ip_name or number can be limited using wildcard lists
in the configuration file</p>
<p> </p>
</blockquote>
<p>By using an <a href="general.htm#External" target="main_info">external
authentication process</a> other controls may be imposed, such as limiting access from
certain classes of users or users of certain machines to specific times of day. For
example, student users on laboratory machines may not be allowed to read mail during work
hours. An example external authentication program is provided with DPOP. See the next
section for details.</p>
<p> </p>
<hr>
<p><a name="External"><b>External authentication of users</b></a></p>
<p>DPOP allows the use of an external application for authenticating client
connections:</p>
<p>by setting the Authentication method in the configuration file to
external. </p>
<p>To set the authentication method to external, set the
following two settings in the dmail.conf file,</p>
<table border="0" cellpadding="0" cellspacing="10" width="100%">
<tr>
<td valign="top" width="40%" nowrap><a
href="dm_conf.htm#lookup">authent_method</a> external</td>
<td valign="top" width="60%"># sets up external as
authentication process</td>
</tr>
<tr>
<td valign="top" width="40%" nowrap><a
href="dm_conf.htm#aprocess" target="main_info">authent_process</a> c:\myauth.exe</td>
<td valign="top" width="60%"># uses program myauth.exe
as authentication process</td>
</tr>
</table>
<p>Plus some other settings you may require,</p>
<table border="0" cellpadding="0" cellspacing="10" width="100%">
<tr>
<td valign="top" width="40%" nowrap><a
href="dm_conf.htm#authent_domain" target="main_info">authent_domain</a> true</td>
<td valign="top" width="60%"># forces user@domain to be
passed</td>
</tr>
<tr>
<td valign="top" width="40%" nowrap><a
href="dm_conf.htm#anumber">authent_number</a> 3</td>
<td valign="top" width="60%"># tells DSMTP/DPOP to run 3
authent processes at once</td>
</tr>
<tr>
<td valign="top" width="40%" nowrap><a
href="dp_set.htm#authent_timeout">authent_timeout</a> 20</td>
<td valign="top" width="60%"># sets DPOP's length of
time until timeout to 20 seconds</td>
</tr>
<tr>
<td valign="top" width="40%" nowrap><a
href="dp_set.htm#authent_cache">authent_cache</a> 500</td>
<td valign="top" width="60%"># tells DPOP to cache 500
authentication requests</td>
</tr>
</table>
<p>External authentication can be used for adding special connection
restrictions, for example, allowing email from laboratory computers only outside working
hours. A sample authentication program is supplied with the distribution set, the C code
for it is shown on this page, <a href="http://www.netwinsite.com/authent/index.htm" target="_top">nwauth.c</a>.
On NT, use Visual C to build an authent process as pipes don't appear to work with
some versions of Borland C.</p>
<p>You must also provide a path to the executable which you want to use. Let us
assume that you wish to use an application called myauth.exe for authentication. The
application myauth.exe must read commands from standard in and write replies to standard
out. The commands and replies defined allow the same system to be used by both DPOP and
DSMTP. Note some parts of the reply are not needed for DPOP.</p>
<p>The only three input commands are:</p>
<blockquote>
<blockquote>
<ul>
<li><p>exit </p>
</li>
<li><p>check username@domain password
fromIPaddress </p>
</li>
<li><p>lookup username@domain </p>
<p>(lookup - is used when drop file path is needed but user is not
connecting so the password does not need checking) </p>
</li>
</ul>
</blockquote>
</blockquote>
<p>The replies are </p>
<blockquote>
<blockquote>
<ul>
<li><p>+OK username drop_file_path
uid forward </p>
</li>
<li><p>+OK username drop_file_path
uid forward </p>
</li>
<li><p>-ERR reason (less than 100 bytes) </p>
</li>
</ul>
<p>UID can be given as 0 on systems which don't require a uid. It
cannot be left out.</p>
</blockquote>
</blockquote>
<p>exit:</p>
<p>The exit input tells the external authentication program to shutdown.</p>
<p><br>
check:</p>
<p>username: The username that the user used to connect to DMail. DMail
adds on the @domain to the username. The domain name that it uses is either the domain
name of the machine which DPOP is running on, or the domain name returned by matching the virtual
domain line, vdomain, in the configuration file.</p>
<p>password: The username that the user used to connect to DMail</p>
<p>fromIPaddress: The IP address from which the user connected.</p>
<p><br>
lookup: </p>
<p>The lookup input is as per the check input. It is used when the drop
file path is needed but the user is not connecting, so the password does not need to be
checked.</p>
<p><br>
+OK:</p>
<p>Returned if the user lookup has been successful. It can have the
following information about the user attached.</p>
<p>username: As per above.</p>
<p>drop_file_path: Full path to the dropfile, including filename, for the
user.</p>
<p>uid: User ID, can be a number or a name or zero or left out. If it is a
number, Unix uses that uid number when it checks the ownership of the drop file. If it is a
name, then DPOP/DSMTP looks up that name in the Unix password file and uses the
corresponding uid. If uid is the number 0 or is left blank, the drop file ownership
is not checked.</p>
<p>forward: An email address. If returned, DSMTP should forward
messages to the given address rather than delivering them here.(not used by DPOP)</p>
<p><br>
-ERR:</p>
<p>The error reply, giving a reason, which is less than 100 bytes in
length. </p>
<p> </p>
<p>Notes: <ol>
<li>The @domain is only sent by DPOP if the configuration file contains line:
authent_domain true</li>
<li>The returned drop file path must contain the full path and filename of
the drop file for that user. </li>
<li>If any directory hashing is required it must be included in the returned
drop_file_path string.</li>
<li>The forward field is not used by DPOP (only by DSMTP) and may be left
blank if not required. </li>
<li>If 'forward' is returned then uid must also be returned.</li>
<li>If the normal drop file path specified in the configuration file is to be
used then the drop file path in the response may be replaced by the single word config</li>
<li>The uid is used to set/check user ownership of drop files.</li>
<li>The uid returned may be numeric or an alphanumeric username.</li>
<li>If no uid checking/setting for drop files is to be used then the uid
returned may be blank.</li>
<li>The @domain passed as part or the username can often be ignored. It is to
allow for the use of <a href="general.htm#Virtual Domains" target="main_info">virtual
domains</a> where a single DPOP server responds to connections to several IP addresses. In
this case, two users with the same username but who read their mail from different domains
may connect to DPOP. See <a href="general.htm#Virtual Domains" target="main_info">virtual
domains</a> for more details.</li>
</ol>
<p>Depending on delays and the speed of the authentication process, it may
be advantageous to run multiple copies of the authentication process. This can be set in
the configuration file by adding the line</p>
<p><a href="dm_conf.htm#anumber">authent_number</a> 5
# To tell DPOP to run five copies</p>
<p>all requests will be then be queued to these five processes</p>
<p>It is often appropriate to cache these authentication requests. DPOP
will optionally cache the responses. The default is to cache the last 1000 successful
requests with a time-out of 12 hours on entries for individual records. Failing
connections are always checked on real data as well as the cache, so a changed password is
immediately recognized. The number of entries to be cached can be set in the configuration
file by adding the line:</p>
<p><a href="dp_set.htm#authent_cache">authent_cache</a> 3000 # To tell DPOP
to cache 3000 entries</p>
<p>Note: the DPOP process size will grow with cache usage at about 100 bytes
per cache entry, so a 10,000 user cache will add about 1 megabyte to the process size.</p>
<hr>
<p><a name="Virtual Domains">Virtual Domains</a> (Added in version 1.08)</p>
<p>An ISP may wish to provide email server support for several distinct groups of users
who collect their email from supposedly different mail servers. For example, there may be
two distinct users both with username fred, let us call them fred1 and fred2</p>
<blockquote>
<ul>
<li>Fred1 has his email client software setup to read mail from <a
href="mailto:fred@mail.domain.one">fred@mail.domain.one</a></li>
<li>Fred2 has his email client software setup to read mail from <a
href="mailto:fred@mail.domain.two">fred@mail.domain.two</a> </li>
</ul>
<p>Both mail.domain.one and mail.domain.two point to a single machine with multiple IP
numbers running one copy of DPOP. In order to handle these two 'virtual-domains' and not
mix up fred1 and fred2 even though they have the same username, DPOP must keep them
separate. When a connection is made to DPOP, it checks the IP number that the connection
was made to. This is then matched against entries in the dmail.conf file of the form; </p>
<blockquote>
<p>vdomain Btwo 161.33.44.55 mail.domain.one /var/spool/mail/B</p>
<p>vdomain C 222.33.44.22 mail.domain.two /var/spool/mail/domaintwo</p>
<p>The entries in these virtual domain lines are as follows:<ol>
<li>Prefix string used to identify this domain</li>
<li>IP number users reading from this domain will connect to</li>
<li>domain name which translates to number above </li>
<li>path for drop files for users of this domain.</li>
</ol>
</blockquote>
<p>These are used to enable the <a href="mailto:username@domain">username@domain</a>
passed to the authentication process to contain enough information to allow the two users
to be distinguished and assigned different drop file paths and passwords. </p>
<p>From the above it might appear that virtual domains can only be supported when an
external authentication process is used, as two different passwords for user fred are
required. This is not the case, virtual domains can also be supported using normal Unix
user/passwords by using the following scheme:<ul>
<li>User fred from domain one is known as A_fred and user fred from domain B is known as
B_fred. The usernames and uid's use the form A_fred and B_fred in order to keep them separate. The
user does not need to change the email client settings, as the translation from fred to
A_fred is done by DPOP. The vdomain prefix can be a string rather than a single letter.</li>
<li>Connections to IP numbers not listed in vdomain records will use the normal drop_path
form and will have normal usernames, dropfile and binfile names.</li>
<li>The drop file path for for each virtual domain is specified in the vdomain record</li>
<li>If the a bin path has been specified for bin files, this is used for all domains BUT a
prefix of A_ B_ etc. is used to distinguish files for users from different virtual
domains.</li>
<li>If bin files are stored in the same place as drop files then the drop paths from vdomain
records are used.</li>
</ul>
</blockquote>
<p>An example: As virtual domains can be used in a number of different ways, a simple
concrete example is probably useful in understanding the use of virtual domains. Imagine
the scenario below:<ul>
<li>You currently have a DPOP server running on machine my.server.domain at ip address
100.2.3.1 </li>
<li>Your email clients connect using addresses such as <a
href="mailto:fred@my.server.domain">fred@my.server.domain</a></li>
<li>Their drop files are stored in a directory /var/spool/mail</li>
<li>You provide no virtual domain support</li>
<li>You use simple Unix user/passwords for authentication</li>
</ul>
<p>Then you are asked to take over (or add) email server support for a second group of
users who used to get their email from johns server using addresses such as <a
href="mailto:fred@johns.server.domain">fred@johns.server.domain</a> What do you need to do
to provide a service for this second group:<ul>
<li>Arrange for the DNS to point johns.server.domain at a second IP number assigned to your
DPOP machine. Let's say this new IP number is 100.2.3.2 (<a href="general.htm#multips"
target="main_info">Setting up multiple IP numbers on a single interface</a>)</li>
<li>Setup a directory for the drop file to arrive in. Let's say /var/spool/mail/johnsusers,
for example</li>
<li>Setup an SMTP server which will deliver mail sent to <a
href="mailto:user@johns.server.domain">user@johns.server.domain</a> to this directory.
DSMTP could do this for you.</li>
<li>Choose a letter or short string to prefix users from johns group. Let's say J</li>
<li>Create usernames and passwords for John's users. J_fred, J_JSmith etc.</li>
<li>Add the following line to your file:<p>vdomain J 100.2.3.2 johns.server.domain
/var/spool/mail/johnsusers </p>
</li>
<li>Restart DPOP</li>
</ul>
<p>Suffix Based Virtual Domains</p>
<p>As an alternative to having multiple IP numbers, virtual domains can be setup by asking
users of the virtual domain to connect using email usernames of the form Fred/jds. This
form of virtual domains can be used with no changes to the POP server, but of course
inconveniences all the users who have to change their client software settings to connect
as username/suffix instead of just username.</p>
<p>No settings are needed in DPOP to handle this form of virtual domains, but it is
sometimes convenient to still use vdomain lines as follows:</p>
<p>Mappings from usernames of the form name/domainsuffix can also be handled by the use of
vdomain records, where the IP number is replaced by /domainsuffix. For example, we might
have:</p>
<blockquote>
<p>vdomain J /jds johns.server.domain /var/spool/mail/johnsusers</p>
<p> </p>
</blockquote>
<p><a name="drop_prefix">drop_prefix</a></p>
<blockquote>
<p>This config setting determines how the drop file name is constructed when virtual
domains are being used. Drop_prefix can be set to true or false. The default is true. When
this setting is true, the drop file name will include the virtual domain prefix. For
example, consider the case when the following vdomain line is being used and a user fred is
connecting to abc.com which maps to ip number 1.2.3.4<ul>
<li>vdomain abc 1.2.3.4 abc.com /mail/abc_com</li>
</ul>
<p>If drop_prefix is true, the drop file used will be /mail/abc_com/abc_fred</p>
<p>while if drop_prefix is false, the drop file used will be /mail/abc_com/fred</p>
</blockquote>
<p>The <a href="https://netwinsite.com/authent/index.htm" target="_top">LDAP</a> authentication module (not yet
available) will also provide support for virtual domains.</p>
<hr>
<p><a name="Multiple IP numbers">Multiple IP numbers</a> on a single machine:</p>
<p>It is fairly easy to add multiple IP numbers for a single machine, up to 255 per
interface is fairly straightforward. 1024 is usually possible with minor patches. The
exact method varies from one form of Unix to another see <a
href="http://www.nethelp.no/net/vif/readme.html">http://www.nethelp.no/net/vif/readme.html</a>
for more information.</p>
<p>As an example on Linux you would do the following:</p>
<blockquote>
<p>su - root<br>
ifconfig eth0:2 999.59.4.31 up<br>
</p>
</blockquote>
<p>to add a second ip number 999.59.4.31. The number :2 can be anything between :1 and
:255</p>
<p><a name="a7">Should I use username suffixes or multiple IP numbers for virtual domain
support?</a></p>
<blockquote>
<p>Multiple IP numbers has the advantage that the users do not need to change their
username setting in their email client packages. Username suffixes save you having to
configure your server machine to respond to multiple ip numbers. The two schemes work as
follows:</p>
</blockquote>
<blockquote>
<p>If a vdomain setting line has an IP number like 1.2.3.4 in it, DPOP checks what ip
number the user was connecting too and does stuff based on matching vdomain lines. If the
vdomain setting line has a suffix string rather than an IP number in the same place ( e.g.
/xusers) then when users connect to DPOP and send user fred/xusers DPOP picks up the
/xusers and uses that to match a vdomain line. The suffix is stripped off and the prefix
is added just as it would be for an ip based vdomain. From then on, the two systems are the
same. The other question is what do we end up with as a drop file name?</p>
<p>Consider the two vdomain lines:</p>
<blockquote>
<ul>
<li>vdomain abc 1.2.3.4 xdomain.com /var/spool/mail/xdomain</li>
<li>vdomain abc /xdom xdomain.com /var/spool/mail/xdomain</li>
</ul>
</blockquote>
<p>If a user connects to 1.2.3.4 or uses a username fred/xdom <br>
Then the Unix username used will be <ul>
<li>abc_fred</li>
</ul>
<p>and the drop file used will be<ul>
<li>/var/spool/mail/xdomain/fred<br>
</li>
</ul>
<p>Some mail transport systems find it easier to deliver to a drop file<ul>
<li>/var/spool/mail/xdomain/abc_fred</li>
</ul>
<p>To allow for this another setting has been added<ul>
<li>drop_prefix true/false</li>
</ul>
<p>if this setting is true, DPOP will use the second form for the drop file name.</p>
</blockquote>
<hr>
<p><a name="gathering statistics"><b>Gathering connection statistics</b></a></p>
<p>DPOP can optionally provide a per connection log of client usage
statistics for use in charging clients etc. In order to disable this feature, modify the
configuration file to include a blank path for the stats_path:</p>
<p>Example:</p>
<p>stats_path my/stats/path</p>
<p>becomes</p>
<p>stats_path # To disable logging of connection statistics for charging</p>
<p>A new statistics file is produced each day with a filename
dpopmmmdd.stats</p>
<p>For example, for the first of January the file name will be
dpopjan01.stats </p>
<p>The statistics file is a printable text file containing one line per
connection with the six fields separated by spaces:</p>
<blockquote>
<blockquote>
<blockquote>
<ul>
<li>start time of connection in seconds</li>
<li>end time of connection in seconds</li>
<li>username</li>
<li>from host name</li>
<li>bytes transferred</li>
<li>number of messages transferred</li>
</ul>
</blockquote>
</blockquote>
</blockquote>
<p>The command: <a href="tellpop.htm#stats" target="main_info">tellpop
stats</a> can be used to summarize the information from a collection of .stats files. It
will produce a one line summary for each user, giving number of connections, number of
messages, average time between connections etc. See <a href="tellpop.htm#stats"
target="main_info">Tellpop</a> commands section for more details.</p>
<hr>
<p><a name="DPOP Performance"><b>DPOP Performance</b></a></p>
<p>The performance of DPOP will obviously be effected by the type of mail
messages being received by your users and the frequency of connections etc. However, some
benchmark figures taken from test configurations we have run with user simulation software
are as follows:</p>
<p>Two machines were tested with similar results:</p>
<p>The first machine was a 133MHz Pentium laptop running windows NT with
32meg of RAM and a thinwire network connection: The second machine was a 66MHz 486 running
Linux with 20meg of RAM.<ul>
<li>With 86 concurrent connections and 5000 mail accounts, the process is
<2meg and completes (connect/check drop file/quit) in an average of 0.1 seconds for
empty drop files.</li>
<li>Processing a drop file with 3,000 ten line messages takes about 3
seconds.</li>
<li>Retrieving large messages is non blocking, so does not effect response to
other connections.</li>
<li>DPOP processes messages a line at a time, so large messages do not effect
the process size.</li>
<li>Total user accounts will effect process size, but 200,000 accounts will
add less than 4 megabytes to the process size.</li>
<li>Caching of authentication will add to process size, but only about 1
megabyte for every 10,000 users cached</li>
</ul>
<p> </p>
<p><a name="DMAIL Free Trial"><b>DMail Free Trial</b></a></p>
<p>You may try out the DMail package free of charge for one month by
downloading the free trial version from our web site. It includes the DSMTP, DPOP and
DList servers, management utilities and full documentation. During this trial, email
support is provided free of charge. If you decide to continue using DMail, you then need to
register your copy in order to receive a key to keep it working. This ensures that you do not waste the
effort involved in configuring DSMTP, DPOP and DList for your situation. Once you receive
your key you can continue using the DMail servers without any need to reinstall or modify
settings. Registration requests are normally sent by email, and a key is emailed to you
within two days of receipt of payment. <br clear="left">
<a href="download.htm">Download Trial Version</a></p>
<p>To generate the registration details to email or fax to NetWin, use the
command</p>
<blockquote>
<blockquote>
<p>tellsmtp register (or tellpop register if just DPOP is being used)</p>
<p>It will ask you a series of questions and then generates a register.txt
file which you can <ul>
<li>Email to us at <a href="mailto:netwin@netwinsite.com">netwin@netwinsite.com</a>
</li>
<li>Fax to us at (+64) 9 630 0689</li>
<li>Post to us (but we prefer email)</li>
</ul>
</blockquote>
</blockquote>
<hr>
<p><a name="Contacting Netwin"><b>Contacting NetWin</b></a></p>
<p>We can be contacted in a number of ways:</p>
<blockquote>
<blockquote>
<ul>
<li>via our web site<p><a href="dp_fram2.htm">https://netwinsite.com/index.htm</a> </p>
</li>
</ul>
<ul>
<li>via email at<p><a href="mailto:netwin@netwinsite.com">netwin@netwinsite.com</a> </p>
</li>
<li>NetWin FTP site<p><a href="ftp://ftp.netwinsite.com">ftp.netwinsite.com</a> </p>
</li>
<li>via paper mail at<p>NetWin Ltd.<br clear="left">
PO Box 27574<br clear="left">
Mt. Roskill<br clear="left">
Auckland <br clear="left">
New Zealand </p>
</li>
<li>via fax or phone at<p>(+64) 9 630 0689 </p>
</li>
</ul>
</blockquote>
</blockquote>
<p><a name="Netwin/DPOP Mailing List">DMail & DPOP Mailing
List</a></p>
<p>A mailing list for people interested in DPOP and the other
DMail servers. This can be used to exchange experiences with these products and, of course,
announcements on new features etc. will be posted to this list.</p>
<p>To join the DPOP mailing list, send an email message to <a
href="mailto:dpop-request@netwin.co.nz">dpop-request@netwin.co.nz</a> with a message
containing the line<br>
subscribe DPOP<br>
You can then send messages to the list by sending to <a href="mailto:dpop@netwin.co.nz">dpop@netwin.co.nz</a></p>
<hr>
<p><a href="products.htm" target="main_info">Other NetWin Products</a></p>
<p> </p>
<p> </p>
<p> </td>
</tr>
</table>
<p><img src="FrontPage:comment_bitmap"></p>
<!--webbot
bot="Include" i-checksum="33756" endspan -->
</td>
</tr>
</table>
<table CELLPADDING="0" CELLSPACING="0" BORDER="0" WIDTH="500">
<tr>
<th ><a HREF="../index.html" target="_top">Products</a></th>
<th ><a HREF="download.htm">Downloads</a></th>
<th ><a HREF="../prices.htm">Prices</a></th>
<th ><a HREF="../support.htm" target="_top">Support</a></th>
<th ><a HREF="../company.htm" target="_top">Company</a></th>
</tr>
<tr>
<td><img SRC="img/nada.gif" WIDTH="100" HEIGHT="1" BORDER="0" ALT></td>
<td><img SRC="img/nada.gif" WIDTH="100" HEIGHT="1" BORDER="0" ALT></td>
<td><img SRC="img/nada.gif" WIDTH="100" HEIGHT="1" BORDER="0" ALT></td>
<td><img SRC="img/nada.gif" WIDTH="100" HEIGHT="1" BORDER="0" ALT></td>
<td><img SRC="img/nada.gif" WIDTH="100" HEIGHT="1" BORDER="0" ALT></td>
</tr>
<tr>
<td><table>
<tr>
<td></td>
</tr>
</table>
</td>
</tr>
</table>
<!-- END FOOTER -->
</body>
]]>