| Previous | Contents | Index |
PMDF uses two sources of information to construct message headers for messages it receives from VMS MAIL. The first is VMS MAIL itself, which provides a To:, From:, Cc:, and Subject: line, and a list of addressees. The second source of information consists of logical names which you can define yourself. The following logical names can be defined to create header lines:
| ° PMDF_COMMENTS (*) | ° PMDF_READ_RECEIPT_TO | |
| ° PMDF_DELIVERY_RECEIPT_TO | ° PMDF_REFERENCES (*) | |
| ° PMDF_ERRORS_TO (*) | ° PMDF_REPLY_TO (*) | |
| ° PMDF_FROM | ° PMDF_RESENT_FROM | |
| ° PMDF_HEADER | ° PMDF_RESENT_REPLY_TO | |
| ° PMDF_HEADER_n | ° PMDF_SENSITIVITY (*) | |
| ° PMDF_IMPORTANCE (*) | ° PMDF_TIMEZONE | |
| ° PMDF_KEYWORDS (*) | ° PMDF_WARNINGS_TO (*) | |
| ° PMDF_ORGANIZATION (*) | ° PMDF_X_FAX_DEFAULTS (*) | |
| ° PMDF_PRIORITY (*) | ° PMDF_X_PS_QUALIFIERS (*) |
The PMDF_TIMEZONE logical name is set by the system manager in the system logical name table to translate to the system's local timezone; users can only override this setting if no system PMDF_TIMEZONE logical is set. None of the other logical names are set by default, and even if they are, users can define their own overriding values to customize the headers attached to the messages they send.
When changing the value of the PMDF_TIMEZONE logical, note that this logical is normally defined at system startup by the SYS$STARTUP:pmdf_startup.com
procedure created when PMDF was installed; see the OpenVMS edition of
the PMDF Installation Guide.
After changing the value of the PMDF_TIMEZONE logical, the Dispatcher should be restarted so that services under the Dispatcher will be made aware of the change and properly use the new value.
If the PMDF_TIMEZONE logical does not exist (for example if you choose to deassign it in pmdf_com:pmdf_site_startup.com
), then PMDF looks for the following system logicals to determine the
local time zone. First it looks for SYS$LOCALTIME, then if that is not
defined, it looks for SYS$TIMEZONE_DIFFERENTIAL and SYS$TIMEZONE_NAME.
|
VMS MAIL provides no indication of where the envelope addresses it passes to PMDF came from (To: line, Cc: line, or both). PMDF tries to match the address with the contents of the X-VMS-To: and X-VMS-Cc: lines, but this attempt is necessarily imperfect and can fail. If it does fail and PMDF cannot localize an address it will be placed on the To: line by default. The result is that addresses that originated on the VMS MAIL Cc: line can end up on the outgoing message's To: header.
charset7
or charset8
channel keywords on the local channel. Files sent with SEND/FOREIGN
will be labelled as "application/vms-rms" if no special RMS
semantics are attached. Currently the only RMS semantics that are
recognized are DDIF, DOTS, and DTIF; these are labelled as
"application/ddif", "application/dots", and
"application/dtif" respectively. In any of these cases the
Content-type: header will also contain a VMS-FDL parameter containing
an FDL description of the file.
When a message labelled as "application/vms-rms" or any of the special semantic tags is received by VMS MAIL the encoding will be reversed and the stored FDL information will be applied to the message as it is delivered. The result will be a foreign format message whose file attributes and contents are preserved.
If the PMDF_FROM line does not translate to anything (by default it will not), the address of the person sending the message is used as the From: address and no Sender: line is inserted in the message header.
The setting of PMDF_FROM is ignored when messages pass through VMS MAIL because of automatic forwarding. Addresses specified by the PMDF_FROM logical undergo normal PMDF address rewriting; they are not exempt from rewrite processing.
If PMDF_FROM translates to a string beginning with and ending in a question mark "?", PMDF will take the enclosed string and prompt the user with it. Whatever the user types will be placed on the From: header line. This prompt will appear after any message has been entered.
Prompting is only possible in regular command-oriented VMS MAIL; it cannot be done in DECwindows MAIL. PMDF checks to make sure that prompting is possible and will ignore any requests for prompts in environments that don't support it.
No logical name is provided to set this header.
VMS MAIL provides no indication of where the envelope addresses it passes to PMDF came from (To: line, Cc: line, or both). PMDF tries to match the address with the contents of the X-VMS-To: and X-VMS-Cc: lines, but this can fail. If it does fail PMDF places the address on the To: line by default. The result is that addresses that originated on the VMS MAIL Cc: line can end up on the outgoing message's To: header.
The X-Envelope-to: line is not user-settable. Its presence or absence in a particular copy of a message is controlled by the x_env_to
, single
, and nox_env_to
keywords on the corresponding channel; see Section 2.3.4.61.
X-Envelope-to: lines are unique among header lines in that they are completely replaced each time a message is enqueued by PMDF. (Most other header lines are cumulative.) An X-Envelope-to: header line only reflects the most recent envelope destination in the case of forwarding. The diagnostic usefulness of an X-Envelope-to: header line has been almost entirely superseded by the use of "received for" clauses in Received: header lines and NOTARY notification messages including final-recipient information.
X-Envelope-to: header lines are an extension to RFC 822. |
X-VMS-Cc: header lines are an extension to RFC 822. |
X-VMS-To: header lines are an extension to RFC 822. |
| Previous | Next | Contents | Index |