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 may 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 may 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 file-spec |
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 file-spec |
SENDLIST|
file-spec|
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 |
Note:
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 wish 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) may 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 may 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 may 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 UNSUBSCIBE 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 acme.com wishes to allow any users in the acme.com domain to subscribe themselves, or any other address, to the list, but does not wish to allow any non-acme.com addresses to perform any subscriptions to the list. Then a MAILSERV_ACCESS mapping such as the following could be used:
MAILSERV_ACCESS SUBSCRIBE|acme-list|*@acme.com|* $Y$K SUBSCRIBE|acme-list|*|* $N SUBSCRIBE|acme-list|*@acme.com $Y$K SUBSCRIBE|acme-list|* $NWith such a mapping in effect, suppose a malicious user forger@somewhere.edu sends a message to MAILSERV. For this message they forge the envelope From: address to appear to be John.Doe@acme.com---an address apparently within acme.com. Suppose this forged message is a third party subscribe request---the apparent (forged) John.Doe@acme.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 acme-list; instead, MAILSERV sends a message to John.Doe@acme.com including a challenge (cookie) string. Unless John.Doe@acme.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