🚀 go-pugleaf

I am concerned about one aspect of e-mail delivery in an environment
consisting of "fileserver" and "workstation" systems.

Suppose a user (call him Fred) logs in on, and gets his mail on, a work-
station host (call it W).  Fred's files, however, are not physically on
W, but are instead of a fileserver host (call it F) and are accessed via
NFS.

(Since this is comp.mail.sendmail, of course, let's also assume that
Fred's site uses Sendmail to deliver e-mail.)

Now, if Fred is not doing anything fancy with his mail delivery, there's
no problem.  His mail is delivered to /usr/spool/mail/fred on W (the
workstation).  Life couldn't be simpler.

However, if Fred is using a ".forward" file, there is the possibility
that mail delivery might not go as planned =if= a message arrives while
W (the workstation) is up, but F (the fileserver) is down.  The sendmail
on W won't see Fred's ".forward" -- it's on F, and F is temporarily
nonexistent -- so it'll assume normal delivery and deposit the message
in /usr/spool/mail/fred instead of wherever Fred's ".forward" file said
it should go.

Now, assuming the site is using a version of Sendmail for which it has
the sources, it should be possible to add a test to see whether Fred's
home directory is currently accessible; if yes, delivery would proceed,
but if not, delivery would be delayed until the next queue run.  This
should presumably fix things . . . .

Well, not quite.  If Fred is invoking a program amongst his own files
from inside his ".forward" -- and/or if Fred is using some scheme that
pre-sorts his incoming mail among a group of "folders" or files in his
home directory -- there could still be trouble if the fileserver F man-
ages to go down immediately after the workstation W's sendmail checks
for Fred's directory and finds it's there.  (The chances of this happen-
ing are a bit higher than the likelihood of a local disk vanishing in
the middle of mail delivery, I'm afraid.)

Depending on the exact timing, some of Fred's mail might be delivered to
/usr/spool/mail/fred (where he might or might not be expecting to see
it) -- or some of his mail might be lost (hopefully creating a spurious
error message that would confuse the sender enough to re-send the mail
or go annoy the site's postmaster and ask if the error report means the
user's account no longer exists).

Because of this, I've been claiming that a fileserver/workstation model
cannot be counted on to work with Sendmail, since no matter what I do,
there's still a brief "window" during which a fileserver crash/hang can
mess up the processing of incoming mail.  Others around here feel I'm
making a mountain out of a molehill; that the "window" is so small that
it can be safely disregarded, and in any case is a small risk to take
for the joys of fileserver/workstation living.

I feel a bit silly arguing against the fileserver/workstation approach
to things (given that it's seen by so many people, even myself, as an
inevitable trend of the future), but I can't in good conscience advocate
a mail setup that could bounce or misdeliver mail whenever the network
decides to hiccup.

I suppose we could go to a "mail center" model, where Fred's mail would
be delivered on the fileserver F, and Fred would somehow access it from
his workstation W.  But this would mean that Fred (and other users like
him) would have to log on to the fileserver to get their mail -- some-
thing one presumably wants to avoid.  Or, alternatively, each and every
mail reading program people like to use (Berkeley mail, MH, MUSH, Emacs
mail, or whatever else) would have to be modified to use a "post office
protocol" to pick up their mail.  And there would still be the problem
of notifying people when new mail had arrived, since the current "com-
sat" daemon (as well as the "you have new mail" code in the shells)
assumes new mail is delivered locally.

Comments?  Suggestions?

--
Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (310) 825-5683