home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / mail / sendmail / 2062 < prev    next >
Encoding:
Text File  |  1992-08-12  |  2.7 KB  |  50 lines
  1. Newsgroups: comp.mail.sendmail
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!physik.tu-muenchen.de!berg
  3. From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
  4. Subject: Re: Reliable mail delivery in fileserver/workstation environment?
  5. Message-ID: <1992Aug12.143851.9785@Urmel.Informatik.RWTH-Aachen.DE>
  6. Originator: berg@hathi.informatik.rwth-aachen.de
  7. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  8. Nntp-Posting-Host: hathi
  9. Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
  10. References: <1992Aug8.021202.6182@cs.ucla.edu>
  11. Date: Wed, 12 Aug 92 14:38:51 GMT
  12. Lines: 36
  13.  
  14. Rich Wales writes:
  15. >However, if Fred is using a ".forward" file, there is the possibility
  16. >that mail delivery might not go as planned =if= a message arrives while
  17. >W (the workstation) is up, but F (the fileserver) is down.  The sendmail
  18. >on W won't see Fred's ".forward" -- it's on F, and F is temporarily
  19. >nonexistent -- so it'll assume normal delivery and deposit the message
  20. >in /usr/spool/mail/fred instead of wherever Fred's ".forward" file said
  21. >it should go.
  22.  
  23. >I suppose we could go to a "mail center" model, where Fred's mail would
  24. >be delivered on the fileserver F, and Fred would somehow access it from
  25. >his workstation W.  But this would mean that Fred (and other users like
  26. >him) would have to log on to the fileserver to get their mail -- some-
  27. >thing one presumably wants to avoid.  Or, alternatively, each and every
  28. >mail reading program people like to use (Berkeley mail, MH, MUSH, Emacs
  29. >mail, or whatever else) would have to be modified to use a "post office
  30. >protocol" to pick up their mail.  And there would still be the problem
  31. >of notifying people when new mail had arrived, since the current "com-
  32. >sat" daemon (as well as the "you have new mail" code in the shells)
  33. >assumes new mail is delivered locally.
  34.  
  35. How about a compromise like, creating a second set of home directories
  36. on the mail server (which will contain the .forward files only).  This
  37. way, mail is delivered as usual, forwarding works instantly, and if a
  38. user does anything fancy in his .forward file, then it is the problem
  39. if the programs/shell scripts he starts in there to ensure that they
  40. deliver the mail or not (e.g. EX_TEMPFAIL).
  41.  
  42. This way the users do not have to log in to the central server to read their
  43. mail, only if they would want to change their .forward files.  And, best
  44. of all, it works without having the source of sendmail.
  45. -- 
  46. Sincerely,                                  berg@pool.informatik.rwth-aachen.de
  47.            Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de
  48.  
  49. Real programmers don't produce results, they return exit codes.
  50.