home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / vmsnet / mail / pmdf / 2130 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  1.8 KB
  1. Path: sparky!uunet!wupost!sdd.hp.com!nigel.msen.com!emory!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!simpact!inland!cmkrnl!infopiz!mccall!ipmdf-newsgate!list
  2. From: klensin@infoods.mit.edu (John C Klensin)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE: Mail User agents
  5. Message-ID: <714007369.34166.KLENSIN@INFOODS.MIT.EDU>
  6. Date: 16 Aug 92 23:22:49 GMT
  7. Organization: The Internet
  8. Lines: 16
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 16 Aug 1992 19:22:49 -0400 (EDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. In-Reply-To: <9208162253.AA02779@jarrah.itd.adelaide.edu.au>
  13. CC: info-pmdf@YMIR.CLAREMONT.EDU
  14. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  15. Resent-Message-ID: <01GNNM61MJ3M95N7DN@YMIR.CLAREMONT.EDU>
  16. X-Vms-To: IN%"andrewr@itd.adelaide.edu.au"
  17. X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
  18. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  19. Content-Transfer-Encoding: 7BIT
  20. Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>
  21.  
  22. >    This doesn't get around one of the problems I was raising,
  23. >which is that these "mainframe derived" schemes only allow for the
  24. >user to read their mail from one physical location, their PC. This is
  25. >not acceptable in our institution, which is why we've gone cc:Mail and
  26.  
  27. Absolutely, it does not solve that problem.  And, in general, it is a
  28. bad idea for several other reasons as well.  Whether cc:Mail is a right
  29. solution in an "anyone can log in from nearly anyplace and be able to
  30. access their mail, etc" environment is really a separate question: there
  31. seems to be a strong feeling around here that such arrangements should
  32. require much stronger and safer user authentication than most of these
  33. micro-based products offer.  But that is really a separate issue whose
  34. answer depends more on your alternatives and your user community than it
  35. does on the technical issues.
  36.  
  37.    john
  38.