home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / bit / listserv / pmdfl / 1794 < prev    next >
Encoding:
Text File  |  1992-08-16  |  2.5 KB  |  56 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!INFOODS.MIT.EDU!KLENSIN
  3. Errors-to: epmdf@YMIR.BITNET
  4. X-Envelope-to: PMDF-L@IRLEARN.BITNET
  5. X-VMS-To: IN%"ip_boss@degsyd.syd.deg.csiro.au"
  6. X-VMS-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
  7. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  8. Content-transfer-encoding: 7BIT
  9. Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>
  10. Message-ID: <01GNN4MNNV2A95NBLN@YMIR.CLAREMONT.EDU>
  11. Date:         Mon, 17 Aug 92 10:21:23 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN>
  13. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  14. Subject:      RE: Mail User agents
  15. X-To:         ip_boss@degsyd.syd.deg.csiro.au
  16. X-cc:         info-pmdf@YMIR
  17. Newsgroups: bit.listserv.pmdf-l
  18. In-Reply-To:  <1992Aug16.201127.143@degsyd.syd.deg.csiro.au>
  19. Lines: 35
  20.  
  21. >>      So the concept employed is that there is one central place
  22. >> that stays up all day, and you can access from all over the place. The
  23. >> problem now is that PC and Mac users expect a GUI as opposed to the
  24. >>...
  25. >That's why "store and forward" methods like POP have been very popular for
  26. >PCs and MACs of late.  There some very nice looking POP client programs
  27. >available to overcome the issue of not having your personal computer
  28. >turned on all the time.
  29.  
  30. Jack,
  31.   While not disagreeing with anything you've said, I think a
  32. terminology clarification would be helpful before this discussion goes
  33. down the path of a parallel discussion about these mail-receiving
  34. protocols...
  35.   Strictly speaking, one could easily construct "store and forward", and
  36. a solution to the shut-off workstation problem with SMTP alone.  You
  37. would set up MX records for the workstations that would deposit the mail
  38. somewhere else if the workstation was off, e.g.,
  39.      workstation MX 0  workstation
  40.      workstation MX 10 postoffice
  41. You would then set "postoffice" up with a channel (or equivalent) for
  42. delivery to local workstations distinct from its channels for delivery
  43. to the rest of the network.  And you would set a really aggressive retry
  44. schedule on that channel s.t., when the workstation came up, it would
  45. get its mail dumped on it in rather short order.  You'd be effectively
  46. polling its SMTP port all the time, and delivering as soon as it came
  47. up.
  48.  
  49. Is this a good idea?  Well, no, and for a number of reasons.  But it is
  50. "store and forward".   POP et al., which depend on the workstation
  51. announcing to the server that they have come up and then retrieving the
  52. mail, are more like "store and fetch".
  53.    --john
  54.  
  55.   Is th
  56.