RFC 822 specifies a large number of fields that can appear in the header of a message. These include familiar things like "From:", "To:", "Subject:", and "Return-Path:" and obscure things like "Encrypted:", "Resent-Message-ID:", and "Resent-reply-to:". Unfortunately, VMS MAIL only provides for "From:", "To:", "Cc:", and "Subj:" information in its message headers. This leaves PMDF with two choices: either discard header lines that do not correspond to VMS MAIL header lines, or insert them somewhere in the body of the message. Neither choice is completely satisfactory --- deleting header lines causes the loss of valuable information but inserting header lines into the message text interferes with the proper operation of VMS MAIL's EXTRACT/NOHEADER command. PMDF, unless configured otherwise by the system manager, uses the latter approach: PMDF preserves additional header lines by merging them into the text of the message.

Now, the addresses which appear in the VMS MAIL From:, To:, and Cc: header lines are not necessarily the same as those which appear in the original message's header. The reason for this is that RFC 822 headers can specify several different types of From:, To:, and Cc: addresses. PMDF has to choose the addresses which best suit VMS MAIL's usage of the VMS MAIL From:, To:, and Cc: header lines. The selection criteria used by PMDF are described below. Regardless of the addresses chosen, each address will be converted from RFC 822 format to VMS MAIL format (e.g., IN%"address") before being given to VMS MAIL. Doing this allows REPLY commands in VMS MAIL to work correctly. (Also, "reply-to-all" type commands such as those in the Pathworks MAIL programs, will work correctly too.)

From:

PMDF tries to use the header line from the original message header that is most likely to contain the address to which replies should be directed. Whether or not PMDF uses any Resent- headers in this process is controlled by the useresent channel keyword. If the local channel has useresent 2 or useresent 1, then the header lines that are used, in order of decreasing precedence, are:+

	1.	Resent-Reply-To: (if present)	5.	Resent-Sender: (if present)
	2.	Resent-From: (if present)	6.	Sender: (if present)
	3.	Reply-To: (if present)	7.	envelope return address (if non-empty)
	4.	From: (if present)	8.	MISSING_ADDRESS PMDF option value+

If the local channel has useresent 0, the default, then the header lines that are used, in order of decreasing precedence, are:

	1.	Reply-To: (if present)	3.	Sender: (if present)
	2.	From: (if present)	4.	envelope return address (if non-empty)
			5.	MISSING_ADDRESS PMDF option value+

To:

PMDF tries to use the header line from the original message header that is most likely to indicate to whom this version of the message was sent. If the local channel has usseresent 2, then the fields that are used, in order of decreasing precedence, are:

1.

Resent-To: (if present)

2.

To: (if present)

If the local channel has useresent 1 or useresent 0 the default, then the To: field is used. If neither a Resent-To: or To: header line is present, then the VMS MAIL To: line will be left blank.

Cc:

PMDF tries to use the field from the message header that is most likely to indicate who the most recent Cc: recipients of the message were. If the local channel has useresent 2, then the fields that are used, in order of decreasing precedence, are:

1.

Resent-Cc: (if present)

2.

Cc: (if present)

If the local channel has useresent 1 or useresent 0, then the Cc: field is used. If neither a Resent-Cc: or Cc: header line is present, then the VMS MAIL Cc: line will be left blank.

Subject:

The Subject: line for VMS MAIL is simply copied verbatim out of the original message header. If no Subject: line is present, the VMS MAIL Subject: line is left blank.