Missingrecipientpolicy Channel Option

Handling messages that lack any recipient headers
RFC 822, the original Internet message format standard, had a requirement that all messages contain at least one recipient header field: a To:, Cc:, or Bcc:.

As of RFC 2822, the original update to RFC 822, relaxed the RFC 822 requirement and allowed submitted messages to be lacking in any recipient header line. This change was carried forward to the current message format standard, RFC 5322.

However, there are still MTAs around that operate according to RFC 822, and in particular may try to be helpful by adding a To: field containing all of the envelope recipients when no recipient fields are present. As such, it may be unwise to emit a message lacking all recipient header lines, since the behavior of an RFC 822-compliant MTA or mail user agent may be undesirable when encountering a message that is, from its point of view, illegal---results may include rejection of such a message, potentially undesired exposure of recipient information such as recipients intended as Bcc: recipients, etc.

The  channel option provides various capabilities that may be useful in addressing this issue. It takes an integer value specifying what approach to use to "fix" messages with no recipient field; the default value, if the channel option is not explicitly present, is to use the MTA option     value (which itself defaults to 0, if not set, which as of MS 6.2 is equivalent to a value of 1 meaning that messages are passed through unchanged---in MS 6.0 and MS 6.1 the default value of 0 had been equivalent to a value of 2 meaning that envelope To addresses are placed in a To: header).

Note that the    MTA option can be used to set an MTA system default for this behavior.

See also:
 * missing_recipient_policy MTA Option
 * missing_recipient_group_text MTA Option
 * acceptalladdresses Option
 * Addresses channel options
 * Headers channel options
 * Channel options