PMDF System Manager's Guide
PMDF-REF-6.0

The SEND_ACCESS and ORIG_SEND_ACCESS mapping tables may be used to control who may or may not send mail, receive mail, or both. The access checks have available a message's envelope From: address and envelope To: addresses, and knowledge of what channel the message came in, and what channel it would attempt to go out. Note that when the To: addresses are irrelevant and only the From: address matters, then use of the FROM_ACCESS mapping table, described below in Section 16.1.3 , may be more convenient and efficient.

If a SEND_ACCESS or ORIG_SEND_ACCESS mapping table exists, then for each recipient of every message passing through PMDF, PMDF will probe the table with a probe string of the form (note the use of the vertical bar character, |)

src-channel|from-address|dst-channel|to-address

The addresses here are envelope addresses, that is, envelope From: address and envelope To: address. In the case of SEND_ACCESS, the envelope To: address is checked after rewriting, alias expansion, etc., have been performed; in the case of ORIG_SEND_ACCESS the originally specified envelope To: address is checked after rewriting, but before alias expansion.

Now, if the probe string matches a pattern (i.e., the left hand side of an entry in the table), then the resulting output of the mapping is checked. If the output contains the flags $Y or $y, then the enqueue for that particular To: address is permitted. If the mapping output contains any of the flags $N, $n, $F, or $f, then the enqueue to that particular address is rejected. In the case of a rejection, optional rejection text may be supplied in the mapping output. This string will be included in the rejection error PMDF issues.¹ If no string is output (other than the $N, $n, $F, or $f flag), then default rejection text will be used. See Table 16-1 for descriptions of additional flags.

In the following example, note that mail sent from OpenVMS user agents such as VMS MAIL, PMDF MAIL, etc., or from UNIX user agents such as mail, Pine, etc., originates from the local, l, channel and messages to the Internet go out a TCP/IP channel of some sort. Now, suppose that local users, with the exception of the postmaster, are not allowed to send mail to the Internet but can receive mail from there. Then the SEND_ACCESS mapping table shown in Example 16-1 is one possible way to enforce this restriction. In that example, the local host name is assumed to be acme.com. In the channel name "tcp_*", a wild card is used so as to match any possible TCP/IP channel name (e.g., tcp_local, tcp_gateway, etc.). In the rejection message, dollar signs are used to quote spaces in the message. Without those dollar signs, the rejection would be ended prematurely and only read "Internet" instead of "Internet postings are not permitted". Note that this example ignores other possible sources of "local" postings such as from PC based mail systems or POP or IMAP clients.

Example 16-1 Restricting Internet mail access

SEND_ACCESS 
 
  *|postmaster@acme.com|*|*  $Y 
  *|*|*|postmaster@acme.com  $Y 
  l|*@acme.com|tcp_*|*       $NInternet$ postings$ are$ not$ permitted 

Table 16-1 Access mapping flags®

Flag	Description
$B	Redirect the message to the bitbucket
$H	Hold the message as a .HELD file
$Y	Allow access
	Flags with arguments, in argument reading order+
$Jaddress	Replace original envelope From: address with specified address§
$Kaddress	Replace original Sender: address with specified address§
$Iuser|identifier	Check specified user for specified identifier (OpenVMS) or groupid (UNIX)
$<string	Send string as an OPCOM broadcast (OpenVMS) or to syslog (UNIX) or to the event log (NT) if probe matches++
$>string	Send string as an OPCOM broadcast (OpenVMS) or to syslog (UNIX) or to the event log (NT) if access is rejected ++
$Ddelay	Delay response for an interval of delay hundredths of seconds; a positive value causes the delay to be imposed on each command in the transaction; a negative value causes the delay to be imposed only on the address handover (SMTP MAIL FROM: command for the FROM_ACCESS table; SMTP RCPT TO: command for the other tables)
$Ttag	Prefix with tag tag
$Aheader	Add the header line header to the message
$Xerror-code	Issue the specified error-code extended SMTP error code if rejecting the message
$Nstring	Reject access with the optional error text string
$Fstring	Synonym for $N string , i.e., reject access with the optional error text string

Note

¹ Note that it is up to whatever is attempting to send the message whether the PMDF rejection error text is actually presented to the user who attempted to send the message. In particular, in the case when SEND_ACCESS is used to reject an incoming SMTP message, PMDF merely issues an SMTP rejection code including the optional rejection text; it is up to the sending SMTP client to use that information to construct a bounce message to send back to the original sender.