home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2254 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.2 KB
  1. Path: sparky!uunet!olivea!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. From: ned@sigurd.innosoft.com (Ned Freed)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE:  vrfy and expn commands
  5. Message-ID: <01GO9XXMVP4Q9S3Q9U@SIGURD.INNOSOFT.COM>
  6. Date: 1 Sep 92 22:58:39 GMT
  7. Organization: The Internet
  8. Lines: 70
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 01 Sep 1992 15:58:39 -0700 (PDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GO9XYFO8IA95OSJZ@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
  15. X-Vms-Cc: IPMDF
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  18. Content-Transfer-Encoding: 7BIT
  19.  
  20. John Klensin writes:
  21.  
  22. >   Given that RFC1123 provides for disabling these things for security
  23. > reasons, would it be sensible to have a per-list attribute that could be
  24. > set to, e.g., NOEXPN so that one could selectively protect lists?  Seems
  25. > more straightforward than hiding them behind aliases, and it seems to me
  26. > that a clear "no, you don't get any information" message would have
  27. > advantages in at least some situations.
  28.  
  29. In general list access can be controlled via the named parameter mechanisms in
  30. PMDF. This does not speak to the issue of handling expansion access differently
  31. than list use access, however.
  32.  
  33. I have accordingly gone ahead and added (for the next release) a new
  34. [nonexpandable] attribute for lists. This can be used specifically to block
  35. expansion via the EXPN verb.
  36.  
  37. Question: There seems to be only one status code EXPN can return when an
  38. expansion fails, and that's 550. It would be useful to be able to distinguish
  39. between "that's not a list" and "it's a list but you cannot expand it". Any
  40. thoughts?
  41.  
  42. >   This would also presumably disable MAILSERV SEND/LIST if applied to
  43. > one of those lists.
  44.  
  45. The mechanisms are somewhat more complex than this and cannot really be
  46. unified. Think of it this way: A single list can have several "views". A view
  47. provides a particular means to access and/or modify the list. Access
  48. restrictions can be applied separately to each view. What we think of as the
  49. list name in the PMDF alias file is what I'm calling a "view" here for clarity.
  50.  
  51. For example, it is perfectly permissible to have one list for freshman, one for
  52. sophomores, one for juniors, one for seniors, one for faculty, and one for
  53. staff. You could then build a bunch of different "views" of these lists:
  54. freshman, sophomores, juniors, seniors, underclasspersons, upperclasspersons,
  55. students, faculty, staff, employees, everybody, etc. The access restrictions
  56. are likely to be different depending on the "view" you're talking about.
  57.  
  58. But MAILSERV would see these lists each as a separate entity; it does not have
  59. to deal with the views. In other words, if you add someone to the freshman
  60. list, the association of that list with the freshman, underclasspersons, and
  61. students views is assumed and should be automatic.
  62.  
  63. MAILSERV also has to deal with write access and list locking (certain types of
  64. "send me the list" actions are supposed to lock the list until it has been
  65. updated and replaced). MAILSERV therefore has a bunch of things to worry
  66. about that a "view" never has to deal with.
  67.  
  68. As a result the authorization mechanisms are split. I plan to release
  69. documentation about the latent authorization support in MAILSERV in the near
  70. future.
  71.  
  72. It is unfortunate and confusing that we don't have the terminology in place
  73. to talk about the lists versus views. It makes things rather confusing. But
  74. the difference is nevertheless very real and quite often is very important
  75. in being able to implement maintainable lists.
  76.  
  77. > As I think about this, it may be that the right list analogy to
  78. > VRFY isn't EXPN but some new command that would take the list name and
  79. > a mailbox address and return, like VRFY, an indication as to whether or
  80. > not that address was on the designated list.  Slightly more invasive
  81. > than VRFY, but not nearly as much so as EXPN.  Maybe someone should find
  82. > an SMTP Extensions WG and propose it to them :-).
  83.  
  84. It is a very interesting idea. The good old "what form is the address in this
  85. time" problem is there, but after dealing with it in MAILSERV I must say that
  86. it can be managed. Implementing it in PMDF would be trivial too. If anyone else
  87. thinks this would be valuable I'd be happy to pursue it further.
  88.  
  89.                 Ned
  90.