| Previous | Contents | Index |
Access to each type of mail server functionality is controlled using
the MAILSERV_ACCESS mapping table in the PMDF mapping
file. Use of this mapping is optional; reasonable defaults are assumed
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, simple
From: address information access checks offer only
marginal protection at best. Although they can make it difficult for
unsophisticated users to unintentionally cause damage they offer no
protection at all against malicious attack.
So for greater protection, MAILSERV can be configured to
generate a challenge-response double-check; see Section 4.3.7.4.
4.3.7.1 Access Check Strings
Each command presented to the mail server is used to compose one or
more access query strings. The MAILSERV_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, PURGELIST for the PURGE/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.
ERRORHELP is a special
command-keyword used to construct entries
specifying an error message file to send back to users in response to
any errors processing the users' commands.
The command-parameter depends on the command. In
the case of the file 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, (that is, the
subdirectory, if any, under PMDF_MAILSERV_MAIL_DIR), 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 list commands,
DIRECTORY/LIST, PURGE/LIST, SEND/LIST, SUBSCRIBE, and UNSUBSCRIBE, the
command-parameter is the name of the list; more
precisely, it is the filename of the list, without the
.dis extension. 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 query string is built, and
address is the address of the originator
(envelope From: address) for the request. In some cases, notably the
SUBSCRIBE and UNSUBSCRIBE commands, two addresses can be involved ---
the address responsible for the request and the address on whose behalf
the request is presented, (i.e., the address for which the
request is being made). In these cases the two-address form of access
query string is used, where the request is made by
address1 for address2.
Note that a user's own subaddress is not considered to be a second
address in that the one address form of access query string is
constructed for the case of a user subscribing or unsubscribing one of
their own subaddresses, i.e., a user
user subscribing or unsubscribing an address of
the form user+string.
These rules are summarized in Table 4-2.
| MAILSERV command | MAILSERV_ACCESS check string format | Default access |
|---|---|---|
| DIRECTORY file-spec |
DIRECTORY|
file-spec|
from-address
|
Allowed |
| DIRECTORY/LIST list-name |
DIRECTLIST|
file-spec|
from-address
|
Allowed |
| DIRECTORY/LIST |
DIRECTLIST|
file-spec|
from-address
|
Allowed |
| HELP |
HELP|HELP.TXT|
from-address
|
Allowed |
| INDEX |
INDEX|INDEX.TXT|
from-address
|
Allowed |
| LISTS |
LISTS|LISTS.TXT|
from-address
|
Allowed |
| PURGE/LIST list-name |
PURGELIST|
list-name|
from-address
|
Disallowed |
| SEND file-spec |
SEND|
file-spec|
from-address
|
Allowed |
| SEND/LIST list-name |
SENDLIST|
list-name|
from-address
|
Disallowed |
| SET MAIL list-name |
SETMAIL|
list-name|
from-address
|
Disallowed |
| SET MAIL list-name other-address |
SETMAIL|
list-name|
from-address|
other-address
|
Disallowed |
| SET NOMAIL list-name |
SETMAIL|
list-name|
from-address
|
Disallowed |
| SET NOMAIL list-name other-address |
SETMAIL|
list-name|
from-address|
other-address
|
Disallowed |
| SUBSCRIBE list-name |
SUBSCRIBE|
list-name|
from-address
|
Allowed |
| SUBSCRIBE list-name subaddress |
SUBSCRIBE|
list-name|
from-address
|
Allowed |
| SUBSCRIBE list-name other-address |
SUBSCRIBE|
list-name|
from-address|
other-address
|
Allowed |
| UNSUBSCRIBE list-name |
UNSUBSCRIBE|
list-name|
from-address
|
Allowed |
| UNSUBSCRIBE list-name subaddress |
UNSUBSCRIBE|
list-name|
from-address
|
Allowed |
| UNSUBSCRIBE list-name other-address |
UNSUBSCRIBE|
list-name|
from-address|
other-address
|
Disallowed |
| invalid command |
ERRORHELP|
from-address|
from-address
|
Allowed |
As always for PMDF mapping tables, if using entries that contain wildcards, e.g., * or %, it is
important to put more specific entries before less specific entries.
And keep in mind that wildcard matches can include the vertical bar
character, |; or in other words, a wildcard such as an
asterisk can match across a vertical bar. In particular, for
MAILSERV_ACCESS mapping SUBSCRIBE and UNSUBSCRIBE checks note that one
should put two address checks before wildcarded one address
checks.
|
4.3.7.2 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.
For an entry that would otherwise succeed, a $* 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. This message can be suppressed by
appending $S to the mapping's result. The first line in the example
below allows user@a.b.c.d to subscribe others to the
info-boink list; all others who try to subscribe to the
list will get referred to user@a.b.c.d.
MAILSERV_ACCESS
SUBSCRIBE|info-boink|user@a.b.c.d|* $Y
SUBSCRIBE|info-boink|* $*user@a.b.c.d
|
To specify referral for a command that would normally fail, such as by default third party UNSUBSCRIBES, note that one must specify $Y as well as $*, e.g.,
MAILSERV_ACCESS
UNSUBSCRIBE|info-boink|user@a.b.c.d|* $Y
UNSUBSCRIBE|info-boink|*|* $Y$*user@a.b.c.d
|
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.
For SUBSCRIBE, UNSUBSCRIBE, and SENDLIST access check mapping entries, a $K specifies that, rather than immediately performing the requested action, MAILSERV should send a message to the address in question (the [un]subscribee address or the address apparently making the SEND/LIST request) asking the user to confirm the requested action. This MAILSERV message will contain a cookie---a string that the user must include in a confirmation message, if they want the action to be performed. See Section 4.3.7.4 for further details.
For a SENDLIST access check mapping entry, a
$X specifies that by default, any RFC 822 comment fields
should be stripped from the distribution list sent back to the user. A
user who is allowed to get a copy of the list (note that
SEND/LIST is disabled by default) can override this
default with the optional /COMMENTS qualifier of the
SEND/LIST command.
Normally, a successful SUBSCRIBE or
UNSUBSCRIBE causes a "You have been [un]subscribed
to/from the list ..." message to be sent to the [un]subscribee
address. In a SUBSCRIBE or UNSUBSCRIBE access
check mapping entry, a $D alters that behavior. When $D is specified,
the usual notification message to the [un]subscribee address in the
case of a third party [un]subscribe can be blocked by specifying
/NONOTIFY; a notification message back to the
[un]subscriber will still be sent.
The available flags are summarized in Table 4-3.
| Flag | Description |
|---|---|
| $Y | Honor the request |
| $T | Honor the request |
| $N | Do not honor the request |
| $F | Do not honor the request |
| $* | If honoring, refer request to the specified address |
| $K | If honoring, send a cookie response back to the address in question; see Section 4.3.7.4 |
| $S | Suppress "Your request has been referred to..." messages |
| $D | Honor /[NO]NOTIFY requests on [UN]SUBSCRIBE commands |
| $< | Honor requests from senders in the specified file |
| $> | Do not honor requests from senders in the specified file |
| $V | When performing a third party command where $K is set, send the "please confirm" message to the address issuing the command, rather than the address on whose behalf the command was issued |
| $X |
When checking a
SEND/LIST command, default to not including comments in
returned list
|
| Flag comparisons | Description |
$:K
|
Match only when processing the confirmation (response to $K) of a command |
4.3.7.3 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 and
PURGE/LIST commands refuse all access and the
UNSUBSCRIBE command only allows users to unsubscribe
themselves from lists and no one else. See Table 4-2 for a summary
of these defaults.
4.3.7.4 Access Confirmation via a Challenge-Response Cycle
Given the nature of contemporary messaging protocols, it is fairly easy
to forge an e-mail address. Thus the security offered by regular mail
server access checks, which are primarily e-mail envelope
From: address based, is rather fragile; it can protect
against naive users, but is not sufficient to protect against a
malicious attacker who forges his envelope From: address.
Greater security for some commands can be obtained by having
MAILSERV engage in a challenge-response cycle, by setting
the $K flag in appropriate MAILSERV_ACCESS
access check entries.
When a successful MAILSERV_ACCESS SUBSCRIBE,
UNSUBSCRIBE, or SENDLIST access check entry
returns the $K flag, then rather than immediately
performing the requested operation, MAILSERV instead sends
a challenge message to the purported address to be affected by the
command. (This would be the purported From: address for most commands,
or the subscribee or unsubscribee address for third party
SUBSCRIBE or UNSUBSCRIBE commands.) The
challenge message from MAILSERV will contain a cookie
string---the user will have to confirm the request via a response
including that exact cookie string.
For instance, suppose a site example.com wants to allow any users in
the example.com domain to subscribe themselves, or any other address,
to the list, but does not want to allow any non-example.com addresses
to perform any subscriptions to the list. Then a
MAILSERV_ACCESS mapping such as the following could be
used:
MAILSERV_ACCESS SUBSCRIBE|example-list|*@example.com|* $Y$K SUBSCRIBE|example-list|*|* $N SUBSCRIBE|example-list|*@example.com $Y$K SUBSCRIBE|example-list|* $N |
forger@somewhere.edu sends a message to
MAILSERV. For this message they forge the envelope
From: address to appear to be
John.Doe@example.com---an address apparently within
example.com. Suppose this forged message is a third-party
subscribe request--- the apparent (forged)
John.Doe@example.com From: address requesting
that the malicious user's true address
forger@somewhere.edu be subscribed. But because of the
$K on the first entry in this sample
MAILSERV_ACCESS table, MAILSERV does not
directly subscribe the malicious outside user to example-list; instead,
MAILSERV sends a message to
John.Doe@example.com including a challenge (cookie)
string. Unless John.Doe@example.com sends back a
confirmation message including the cookie, the subscribe of
forger@somewhere.edu will not be performed. In particular,
forger@somewhere.edu would have to guess or otherwise
obtain the cookie string in order to achieve their attempted subscribe.
On an implementation note, any initial messages awaiting cookie
confirmation are stored in the directory
PMDF_QUEUE:[mailserv.spool] (OpenVMS) or
/pmdf/queue/mailserv/spool/ (UNIX); if no cookie
confirmation is received, such messages will time out after seven days
and be returned to the sender (envelope From: address).
4.3.7.5 Access Example
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|* $Y
SUBSCRIBE|info-boink|* $*user@a.b.c.d
SENDLIST|info-boink|* $Y
|
| Previous | Next | Contents | Index |