🚀 go-pugleaf

>From:	IN%"GHC@VGER.NIDDK.NIH.GOV"  "Gerson H Cohen" 21-DEC-1992 07:06:32.44
>To:	IN%"ipmdf@YMIR.CLAREMONT.EDU"
>CC:
>Subj:	Problem with Mailserv
>
>Being a long term user of Mailserv, from before it was a supported
>channel within PMDF, I had pretty much ignored the various postings
>about problems/solutions that have appeared, not realizing that I
>was having the same.  I was thrown a bit to receive the following
>in response to a send/list:
>
>> You are not authorized to obtain the contents of list SADUG-L
>> Use the HELP command to get a list of legal MAILSERV commands.

This is disabled by default, the documentation for enabling it should be
found in the bookreader version, the text version is included in this
message.

>
>Now I place myself at the mercy of the list asking someone to
>get me over this hump and other similar problems that you think
>I might encounter.  [I do seem to be able to sub, unsub and
>retrieve files.]
>
>Thanks,
>
>Gerson Cohen

----------------------------------------------------------------------------
Access to each type of mail server functionality is controlled using the
MAILSERV_ACCESS mapping in the PMDF mapping file. Use of this mapping is
optional; reasonable defaults are taken for each sort of access if no mapping
is specified.

Access control is necessarily based on addressing information. Since it is in
practice possible to forge any sort of address information access checks offer
only marginal protection at best. Although they may make it difficult for
unsophisticated users to unintentionally cause damage they offer no protection
at all against malicious attack.


ACCESS CHECK STRINGS

Each command presented to the mail server is used to compose one or more access
query strings. The access mapping is then applied to each of these strings. The
result of the mapping is examined and determines whether or not the requested
operation is allowed. If the operation is not allowed the mail server returns
an indication to the requestor indicating that an access failure has occurred.

The access query strings are always in one of the following two formats:

  command-keyword|command-parameter|address
  command-keyword|command-parameter|address1|address2

"command-keyword" is derived from the name of the command being checked. It
will be "DIRECTORY" for the DIRECTORY command, "DIRECTLIST" for the
DIRECTORY/LIST command, "SEND" for the SEND command, "SENDLIST" for the
SEND/LIST command, "SUBSCRIBE" for the SUBSCRIBE command, and "UNSUBSCRIBE" for
the UNSUBSCRIBE command. Although commands can be abbreviated abbreviations do
not carry over into the "command-keyword" strings.

The "command-parameter" depends on the command. In the case of the file
access commands DIRECTORY and SEND the parameter is the name of the particular
file being accessed. The file name string consists of the directory
specification (if any), the file name, and the file type. Wildcards don't carry
over into access strings; the wildcard expansion process is done first and then
each resultant file generates a separate access check. In the case of the list
access commands DIRECTORY/LIST, SEND/LIST, SUBSCRIBE, and UNSUBSCRIBE the
"command-parameter" is the name of the list. Wildcards are once again
expanded prior to doing any access checks.

When a mail server request involves only one address the single-address form of
access check string is built, and "address" is address of the party responsible
for the request. In some cases, notably the SUBSCRIBE and UNSUBSCRIBE commands,
two addresses may be involved -- the address responsible for the request and
the address the request is acting on. In this case the two-address form of
access check string is used, where "address1" is the responsible party's
address and "address2" is the address being acted on.

PMDF V4.1 uses the envelope From: address as the responsible party's address.
PMDF V4.2 uses the header Sender: address if one is present. If no Sender:
address is present the header From: address is used instead. The Sender:
address is nominally supposed to represent a "authentic" source of information.
Please keep in mind that given the nature of contemporary messaging protocols
it is fairly easy to forge any or all of these addresses. As a result, the
security offered by mail server access checks is extremely fragile at best.




ACCESS CHECK MAPPING RESULTS

Access check mapping entries set flags to indicate whether or not the request
should be honored. A "$Y" or "$T" specifies that the request should be honored.
A "$N" or "$F" indicates that the request should be rejected.

A "$<" specifies that the entry has returned a file name. The file name should
be specified as a full absolute path. This file is opened and read as a series
of addresses. The request is rejected if the requestor's address does not
appear in the list. A "$>" does the same thing except that rejection occurs if
the requestor's address is in the list. "$<" and "$>" cannot be used in the
same entry; if they are the result is unpredictable.

A "$*" in PMDF V4.2 specifies that the entry has returned a referral address.
Instead of honoring the request directly the mail server forwards the request
to the specified referral address. The request is rejected if the referral
address is bogus. A message is also sent to the requestor indicating that his
or her request has been referred elsewhere. The requestor message can be
suppressed by appending "$S" to the mapping's result.

If both "$*" and "$<" or "$>" are used simultaneously the string returned by
the mapping entry should consist of the file name, a comma, and then the
referral address.



ACCESS DEFAULTS

The DIRECTORY, DIRECTORY/LIST, SEND, and SUBSCRIBE commands all allow full
access if no access mapping is provided or the access check string does not
match any mapping entry. The SEND/LIST command refuses all access and the
UNSUBSCRIBE command only allows access to the requestor's address.



ACCESS EXAMPLES

The following mapping controls access to the INFO-BOINK list. It specifies that
user@a.b.c.d has full access to the list and handles subscription requests by
referral. Users in domain f.g.h.i cannot access the list in any way. It also
specifies that anyone not in the domain f.g.h.i can retrieve a copy of the
list membership.

MAILSERV_ACCESS

    *|INFO-BOINK|user@a.b.c.d                      $Y
    *|INFO-BOINK|user@a.b.c.d|*                    $Y
    *|INFO-BOINK|*@f.g.h.i                         $N
    *|INFO-BOINK|*@f.g.h.i|*                       $N
    SUBSCRIBE|INFO-BOINK|user@a.b.c.d|*            $*user@a.b.c.d
    SENDLIST|INFO-BOINK|*                          $Y

--  the end --------------------------------------------------------------------


		/portia
		portia@innosoft.com	(909)624-7907	New area code!
		Innosoft International Inc.