6. Appendix A - Mappings Specific to SMTP

   This Appendix is specific to the Simple Mail Transfer  Protocol (RFC
   821std10(-> 2821prop)).  It describes specific changes in the context of this protocol.
   When MIXER is used with SMTP, conformance to this appendix is
   mandatory.

   1.  Probes

   When servicing a probe, as described in section 5.3.9, use may be
   made of the SMTP VRFY command to increase the accuracy of information
   contained in the delivery report.

   2.  Long Lines

   SMTP is a text oriented protocol, and is required to support a line
   length of at least 1000 characters.   Some implementations do not
   support line lengths greater than 1000 characters.   This can cause
   problems.  Where body parts have long lines, it is recommended to use
   a MIME encoding that folds lines (quoted printable).

   3.  SMTP Extensions

   There are several RFCs that specify extensions to SMTP. Most of these
   are not relevant to MIXER.  The NOTARY work to support delivery
   report defines extensions which are relevant [29].  Use of these
   extensions by a MIXER gateway is optional.  If these extensions are
   used, they shall be used in the manner described below.

   3.1.  SMTP Extension mapping to X.400

   Mappings are defined for the following extensions:

   NOTIFY
      This is used to set the report and non-delivery bits of
      MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
      If the value is NEVER, both bits are zero.  If SUCCESS is present,
      the report bit is set.  Otherwise, the non-delivery-report bit is
      set.  If the gateway uses the NOTIFY command, it shall perform
      this mapping in all cases.

   ORCPT
      If the address type of the original recipient is "x400" or
      "rfc822", this may be used at the MTS level, to generate an
      element of redirection history, with the redirection date being
      the date of conversion and the reason set to "alias".

   ENVID
      If present, this may be used to generate a content correlator.
      This is used rather than the MTS Identifier, as the ENVID is
      unique for the UA only and is likely to be too large to map to an
      MTS identifier. The content correlator is encoded as an IA5 String
      containing the ENVID and prefixed by the string:

                            "SMTP/NOTARY ENVID: "

      If the ENVID starts with the string "X400-MTS-Identifier: ", then
      this ENVID was generated from an X.400 MTS Identifier.  The
      reverse mapping defined in Section 3.2 of Appendix A shall not be
      used, as this may cause problems in certain situations (e.g.,
      where the message was expanded by an Internet mailing list).

   3.2.  X.400 Mapping to SMTP Extensions

   The following extensions may be used as a part of the MIXER mapping:

   NOTIFY
      The originator-report and originator-non-delivery-report bits of
      MTA.PerRecipientMessageTransferFields.per-recipient-indicators
      determine how this is used.   If both bits are zero, the parameter
      is NEVER.  If the report bit is set, SUCCESS is used.   Otherwise,
      FAILURE is used.  If this is done, the gateway shall not generate
      a delivery report for this recipient, unless this is needed in the
      case where the originating MTA service report requirements differ
      from the user requirements.   Additional originating MTA
      requrirements are satisfied by the gateway.

   ORCPT
      If the MTS.perRecipientDeliveryFields.originally-intended-
      recipient-name is present, the ORCPT command may be used to carry
      this value, using the "x400" syntax.

   ENVID
      This may be generated, with the value taken from the
      MTS.MessageDeliveryEnvelope.message-delivery-identifer.  If this
      is done, it shall be encoded as EBNF.mts-msg-id, preceded by the
      string "X400-MTS-Identifier: ".

   RET
      If MTA.PerMessageTransferFields.per-message-indicators.content-
      return-request is set to FALSE, the parameter RET may be set to
      HDRS, to specify return of headers only.