From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE:  vrfy and expn commands
Date: 1 Sep 92 22:58:39 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 01 Sep 1992 15:58:39 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO9XYFO8IA95OSJZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

John Klensin writes:

>   Given that RFC1123 provides for disabling these things for security
> reasons, would it be sensible to have a per-list attribute that could be
> set to, e.g., NOEXPN so that one could selectively protect lists?  Seems
> more straightforward than hiding them behind aliases, and it seems to me
> that a clear "no, you don't get any information" message would have
> advantages in at least some situations.

In general list access can be controlled via the named parameter mechanisms in
PMDF. This does not speak to the issue of handling expansion access differently
than list use access, however.

I have accordingly gone ahead and added (for the next release) a new
[nonexpandable] attribute for lists. This can be used specifically to block
expansion via the EXPN verb.

Question: There seems to be only one status code EXPN can return when an
expansion fails, and that's 550. It would be useful to be able to distinguish
between "that's not a list" and "it's a list but you cannot expand it". Any
thoughts?

>   This would also presumably disable MAILSERV SEND/LIST if applied to
> one of those lists.

The mechanisms are somewhat more complex than this and cannot really be
unified. Think of it this way: A single list can have several "views". A view
provides a particular means to access and/or modify the list. Access
restrictions can be applied separately to each view. What we think of as the
list name in the PMDF alias file is what I'm calling a "view" here for clarity.

For example, it is perfectly permissible to have one list for freshman, one for
sophomores, one for juniors, one for seniors, one for faculty, and one for
staff. You could then build a bunch of different "views" of these lists:
freshman, sophomores, juniors, seniors, underclasspersons, upperclasspersons,
students, faculty, staff, employees, everybody, etc. The access restrictions
are likely to be different depending on the "view" you're talking about.

But MAILSERV would see these lists each as a separate entity; it does not have
to deal with the views. In other words, if you add someone to the freshman
list, the association of that list with the freshman, underclasspersons, and
students views is assumed and should be automatic.

MAILSERV also has to deal with write access and list locking (certain types of
"send me the list" actions are supposed to lock the list until it has been
updated and replaced). MAILSERV therefore has a bunch of things to worry
about that a "view" never has to deal with.

As a result the authorization mechanisms are split. I plan to release
documentation about the latent authorization support in MAILSERV in the near
future.

It is unfortunate and confusing that we don't have the terminology in place
to talk about the lists versus views. It makes things rather confusing. But
the difference is nevertheless very real and quite often is very important
in being able to implement maintainable lists.

> As I think about this, it may be that the right list analogy to
> VRFY isn't EXPN but some new command that would take the list name and
> a mailbox address and return, like VRFY, an indication as to whether or
> not that address was on the designated list.  Slightly more invasive
> than VRFY, but not nearly as much so as EXPN.  Maybe someone should find
> an SMTP Extensions WG and propose it to them :-).

It is a very interesting idea. The good old "what form is the address in this
time" problem is there, but after dealing with it in MAILSERV I must say that
it can be managed. Implementing it in PMDF would be trivial too. If anyone else
thinks this would be valuable I'd be happy to pursue it further.

				Ned