| 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 |