[comp.mail.uucp] PC/Courier <-> Internet gateways?

paul@frcs.UUCP (Paul Nash) (11/22/90)

We have a client who has (foolishly?) invested heavily in a PC
LAN-based mail system called ``Courier''.  They have some 20+
Novell LANS with Courier installed, and about 10000 users (!).
The users are mostly quite naive (in computer terms) and prefer
Courier features such as picking the recipient off a menu (of
10000 possibles!) to having to remember user names.  The LANs 
are all interlinked, and PC users can send mail to other PC users,
via their Ethernet backbone.  They now want to link their PC mail
systems to a bunch of Unix machines, also on the same Ethernet.
They also want to talk to the rest of the world, via the Internet.

Telnet and FTP between PCs and Unix is easy, thanks to the packet
drivers.  Currently, PC users who want to send mail to Unix people
have to get a Unix account, telnet to the Unix box containing that
account and send normal Unix mail.  Mail in the reverse direction
is even more difficult (create an account for the recipient, etc).

There is a Courier/SMTP gateway available from Courier, but this
would cost more than the initial installation.  Courier does not 
Novell's MHS as its transport agent, but has a proprietry agent,
which carries the mail in _encrypted_ format.

As I see it, we have the following options:

1) Purchase the SMTP gateway from Courier, and hope that it works

2) Purchase the MHS gateway from Courier (which is probably cheaper),
   and hack up an SMTP/UUCP/whatever interface.  This will not
   be a terribly slick interface, as MHS user names are 10 upper-
   case characters, as are system names.
   
3) Purchase the Courier API libraries, and try to hack up a new
   gateway from scratch.  This would mean that users would have
   to put most of the Internet address into the document itself
   (not good for beginners) and mail to a dummy user account.
   
4) Scrap everything and buy/develop a new system.  This would allow
   us to integrate the two types of network, and would also allow
   us to provide network news to PC users.
   
We favour option 4), for fairly obvious reasons, but it will take
both time and money (probably more than option 1)).  

Does anyone out there know whether there are existing products that
integrate nicely between PC and Unix mail systems?  What are the
de-facto standards for such links (NNTP for news, SMTP for mail?)?  
Is there a protocol like SMTP to link a mail _user_ to a remote 
mailbox (like NNTP does for news)?  Can NNTP handle updating
a central `.newsrc' for a remote user, so that s/he can log on
from _any_ workstation on _any_ network, or is this not very 
realistic?

Are there any other questions that we should be asking?

All and any comments would be appreciated.  I _do_ follow the
news, but our feed is quite erratic, so mail would be appreciated
(as welll as posting?).  I will summarise for the net once I 
have some clear responses.

	--------	--------	--------	--------
"Vanity of vanities", saith the Preacher, "vanity of vanities; all is vanity"

Isaac@gui.consumers.com (11/29/90)

In a recent article in comp.mail.misc, Paul Nash <paul@frcs.UUCP> wrote a 
number of interesting points, some that were far from facts, that just begged 
for a detailed response.

Please email me follow-ups as I do not have easy access to these news groups.

>We have a client who has (foolishly?) invested heavily in a PC
>LAN-based mail system called ``Courier''.  They have some 20+
>Novell LANS with Courier installed, and about 10000 users (!).
>The users are mostly quite naive (in computer terms) and prefer
>Courier features such as picking the recipient off a menu (of
>10000 possibles!) to having to remember user names.

First, according to the latest IDC and Gartner Group reports, Consumers 
Software's "The Network Courier" is the largest selling third party, LAN 
based electronic mail system available today!  If your client has "foolishly" 
invested heavily in the "Courier", so has such organizations as IBM who 
resell Courier as their endorsed e-mail system, American Airlines, who have 
selected Courier for their 12,500 travel agencies, etc.  These organizations 
have the infrastructure to thoroughly test products, and just like your 
client, Courier has been their product of choice.

In terms of ease of use, The Network Courier has won awards for its 
user-friendliness.  It has been designed to be intuitive for both the 
computer literate and non-experienced user.  As for directory selection, 
users of the Courier find that selecting names off of a menu is a lot 
simplier to do then to have to remember names.  Picking from a list of 10,000 
is actually very easy.  By typing the first few letters of the user's name, 
the address window quickly moves to that address (right arrowing on the name 
gives all the addressing details, location, etc. in a nice window)  Courier 
also allow addresses to be typed in on the fly if the user knows the address 
and preferred to do it this way.

>The LANs are all interlinked, and PC users can send mail to other PC users,
>via their Ethernet backbone.  They now want to link their PC mail
>systems to a bunch of Unix machines, also on the same Ethernet.
>They also want to talk to the rest of the world, via the Internet.
>
>Telnet and FTP between PCs and Unix is easy, thanks to the packet
>drivers.  Currently, PC users who want to send mail to Unix people
>have to get a Unix account, telnet to the Unix box containing that
>account and send normal Unix mail.  Mail in the reverse direction
>is even more difficult (create an account for the recipient, etc).

>There is a Courier/SMTP gateway available from Courier, but this
>would cost more than the initial installation.  Courier does not 
>Novell's MHS as its transport agent, but has a proprietry agent,
>which carries the mail in _encrypted_ format.

Courier does use its own transport in most cases to ensure that mail is 
transported in encrypted format as compared to the Novell MHS transport.  
Courier's transport also does not fan out mail (i.e. a single mail item 
addressed to 50 users does not produce 50 copies as in MHS).

>As I see it, we have the following options:

>1) Purchase the SMTP gateway from Courier, and hope that it works

The Courier SMTP gateway is very robust and reliable.  It supports features 
such as the exchange of attachments according to RFC 1154; allows Network 
Courier networks to "tunnel" through SMTP using back-to-back SMTP gateways; 
and, makes the Network Courier users appear to the SMTP world as though they 
are SMTP users so there is no need to create additional accounts. 
Furthermore, because we use the standard Network Courier as the User Agent, 
there is no re-learning.  Sending an SMTP message is as simple as sending a 
basic Network Courier message and receiving an SMTP message is as simple as 
reading a standard Network Courier message. Courier supports native SMTP 
addressing internally, so there is no mapping to other address types (as in 
the MHS solution) required.  The SMTP gateway can run on top of DOS TCP/IP 
stacks from FTP software, Excelan and Wolongong. 

>2) Purchase the MHS gateway from Courier (which is probably cheaper),
>   and hack up an SMTP/UUCP/whatever interface.  This will not
>   be a terribly slick interface, as MHS user names are 10 upper-
>   case characters, as are system names.

This is definitely a possibility but, MHS in itself has many inherent 
problems that have already been discussed.  Furthermore, you would not want 
to introduce another level of complexity by using two gateways (Courier/MHS, 
MHS/SMTP) when a SMTP gateway already exists.  By the way, Courier also 
support gateways for X.400, PROFS, SNADS, IBM Office Vision, MCI, FAX in 
addition to SMTP and MHS.

>3) Purchase the Courier API libraries, and try to hack up a new gateway 
>   from scratch.  This would mean that users would have to put most of the 
>   Internet address into the document itself (not good for beginners) and 
>   mail to a dummy user account.
   
A number of companies have used our API to build gateways to foreign mail 
systems but no one has ever used it to re-invent an established, robust
"wheel".

>4) Scrap everything and buy/develop a new system.  This would allow
>   us to integrate the two types of network, and would also allow
>   us to provide network news to PC users.
   
I don't understand this alternative.  If your client has already invested in 
The Network Courier, and because we already have a powerful gateway into 
their SMTP environment, it would be ludicrous to suggest starting all over 
again.

>We favour option 4), for fairly obvious reasons, but it will take both time 
>and money (probably more than option 1)). 
 
What are the fairly obvious reasons?  In reviewing your article, there is 
absolutely nothing that suggests for your client to scrap everything and 
start again.  The technology exists and is proven.  What is the problem?
The only problem I see in reading your article is possibly pricing.  But the 
cost of the gateway in an environment with 10,000 users works out to only 
pennies per user.

Isaac Chan

Email: Isaac@gui.consumers.com
Phone: (604) 688-4548
Smail: Consumers Software Inc.
       73 Water Street, 7th Floor
       Vancouver, BC V6B 1A1
       Canada