NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/vmsnet/networks/tcpip/multinet/2781

Internet Message Format | 1993-01-28 | 3.7 KB

Path: sparky!uunet!stanford.edu!rutgers!gvls1!udel!bogus.sura.net!howland.reston.ans.net!usc!news.service.uci.edu!unogate!mvb.saic.com!info-multinet
From: [e-mail]
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RE: mail problem
Message-ID: <[e-mail]>
Date: 26 Jan 93 22:28:31 GMT
Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
Lines: 61
X-Gateway-Source-Info: Mailing List


>Counterexamples taken from real-world cases and uses of email and FAX:
>
>(1) Notes about reservations on planes, trains, reunions, dates, etc. It helps
>    a lot to know when one of these is delayed beyond a reasonable amount of
>    time.
>
>(2) Stock quotes -- they aren't applicable if delayed.
>
>(3) Weather reports and predictions.
>
>Now, you can make a case for not sending this sort of stuff via email, and you
>can make a case for using explicit expiration dates instead of nondelivery
>notifications, but the fact remains that people do use email for this sort of
>stuff and rightly or wrongly they depend on temporary nondelivery notifications
>to tell them when things are messed up. You may not use mail this way, I may
>not use mail this way, but believe me there are lots of people who do, and
>they're probably the majority.

I definitely agree with Ned on this one.  We may not have much external
e-mail traffic, but a significant portion of our internal network load
is due to e-mail.  The emphasis here is to eliminate telephone tag by
using e-mail.  Our complex is distributed across town much like a college
campus, so many meetings are replaced by e-mail discussions.  When e-mail
isn't delivered in a timely fashion, daily business is adversely affected.
Even our network/computer help desk receives the majority of user complaints
via e-mail.

We have a goal of ensuring that e-mail is delivered within 15 minutes when
it is routed through the central e-mail hub (which takes care of protocol
conversions between a number of heterogenous operating systems), and 7
minutes when it is routed between like systems.  To ensure that the key
gateways of the e-mail network are functioning, a monitor node periodically
sends a probe message to a mirror account on each gateway.  The gateways
then return the message to the monitor node, which records the round-trip
time.  Alarms are triggered when thresholds are exceeded.  (Actually the
mirror accounts return the message to whoever originated it, so they are
also used to debug e-mail connectivity issues.)

However, not every node in the network is so monitored.  Thus a node or
branch mail system may be down and the administrators aren't aware of it.
If the originator doesn't receive an indication of nondelivery, then neither
the originator, the receiver, or the administrators are aware of the problem.

There are very few computer/network applications in our environment that
don't provide an immediate indication when an error occurs.  Unfortunately
one of our most critical computer/network applications (e-mail) is an
application that doesn't provide immediate notification.  Do any Multinet
sites have an automated alarm system to determine when e-mail is not being
delivered?  Waiting for user complaints is not appropriate in our business.

>The only thing that's unreliable about nondelivery notices is the inconsistency
>of their generation. However, users adapt amazingly quickly to the nature of
>the systems they use, so they usually take these differences in stride.

And the amount of time that must pass before they are generated.  The default
value on systems here ranges from 7 days to a few hours.  The user community
prefers a standard delay (preferably single digit hours), but that is hard
to implement when some vendors hardcode this value.

Bob