🚀 go-pugleaf

In article <1992Aug20.173310.4492@murdoch.acc.Virginia.EDU> smb3u@kiptron.psyc.virginia.edu (Steven M. Boker) writes:
   We are setting up SLIP for a number of our professors who have NeXT
   machines at home as well as at work.  They prefer to read their
   mail using the NeXT Mail GUI.  Has anyone a list of practical do's
   and don'ts for setting up a mail client over a SLIP line?

   The SLIP server is also the mail server for our NetInfo cluster.  I
   assume that I could go ahead and make the same NFS mounts that I
   normally would for a mail client, but I have heard that NFS can be
   troublesome over SLIP.  What is the common net wisdom on this?

Unless you turn on UDP checksumming on both the NFS server and the NFS
client (note: these aren't necessarily the endpoints of the SLIP link,
these are the NFS-level endpoints), it's unsafe to run NFS over a SLIP
link.  Since the SLIP protocol incorporates no error detection, the
SLIP driver can unknowingly hand damaged packets up to IP, which will
hand them up to UDP, which will (lacking a checksum or CRC check) hand
them to NFS, where the corrupted data will be silently included in
your file.  This has happened to me, even over error-correcting
modems, and it wasn't pleasant.  End-to-end data errors can be
introduced by factors other than telephone line noise - e.g. UART
overruns.

This isn't a problem for TCP applications, which can safely assume
that TCP's checksums will provide them with a reliable, sequenced,
error-free data stream.  If a damaged frame arrives, TCP will discard
it, and the retransmission algorithms will ensure that it is
eventually delivered clean.

You have several alternatives:

1) Turn on UDP checksumming on the NFS server and clients.  I don't
   know how to do this on NeXT systems.  It may already be turned on
   by default, or it may be non-turn-on-able.

2) Use PPP rather than SLIP, because PPP provides a 16-bit CRC on each
   frame for packet-level error detection.  A damaged packet is
   discarded by the PPP driver, before it can be handed up to IP and
   then on up the protocol stack.  Higher-level layers worry about
   retransmissions.  Both PPP and SLIP can be had either for free, or
   from commercial providers, for your NeXTs.

3) Make a local mail spool on each home machine, and use normal SMTP
   delivery between each node's sendmail.  This is perhaps the most
   straightforward to implement, but could become a hassle because of
   all those standalone machines running in unmanageable locations.
   You'll probably want to configure the remotes to hand their
   outgoing mail to the central site for delivery, so you at least
   stand a chance of getting their headers right before they head
   outside your domain.

4) Run the NeXT mail application on the office server, with its
   display redirected to the home machine's window server.

5) Use a mail management protocol like POP or IMAP, for which servers
   and nice clients exist for NeXTs.  I don't know if those clients
   provide all the features your users now enjoy in NeXT's Mail app.

Our home systems use (2) and (3), and occasionally (4) for other
applications.