PMDF System Manager's Guide

As the PostScript language includes operators to create, read, and write files, the PS_TO_G3 channel has been carefully coded to protect system security.
When interpreting the body of a message, the PS_TO_G3 channel: (1) sets its username to be the username specified by the system logical PMDF_USER_USERNAME, (2) sets its UIC to be the UIC specified by the system logical PMDF_USER_UIC, and (3) turns any privileges it has off. (Note: The channel never actually logs in under the PMDF_USER_USERNAME account.) To ensure proper system security, the account and UIC specified by the PMDF_USER_ logicals should not be in a group with any other account or have a group UIC number which is less than or equal to the SYSGEN parameter MAXSYSGROUP (typically 8). Many sites use the choice PMDF_USER_USERNAME = DECNET, PMDF_USER_UIC = [376,376] (or whatever the DECnet account's UIC is). As the DECnet account usually has the desired characteristics, this is often a good choice. When processing mail messages, header lines displayed on the cover page are treated only as text strings and always carefully quoted (in the PostScript sense) so as to prevent PostScript commands embedded in header lines from ever being interpreted.

Note also that the TEXT_TO_PS channel has a special file inclusion operator which allows the content of files to be included in messages transmitted. A channel option is provided to disable this feature. Regardless of whether or not this feature is enabled, the TEXT_TO_PS channel goes through the same security steps as the PS_TO_G3 channel prior to processing the body of a message. (No processing is performed on the header lines by this channel.)

Since cover page template files are interpreted from a privileged context, the COVER addressing attribute is only honored when a FAX_COVER_PAGE mapping table is defined. It is important that this table not simply return user specified cover pages but rather, in response to a requested cover page, return a known cover page file. See Section 37.2.16.1.1 for details. Note that this is only an issue if you define a FAX_COVER_PAGE mapping table. If you do not define that table, then this is never a security issue as the COVER addressing attribute will be ignored.