[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 4141

Network Working Group                        K. Toyoda, MGCS
Internet Draft                       D. Crocker, Brandenburg
     draft-ietf-fax-esmtp-conneg-04.txt             Feb 2003
Expires: <7-03>



                   SMTP Service Extensions
                 for Fax Content Negotiation



     STATUS OF THIS MEMO

     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     RFC2026. Internet-Drafts are working documents of the
     Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum
     of six months and may be updated, replaced, or
     obsoleted by other documents at any time.  It is
     inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be
     accessed at
     http://www.ietf.org/shadow.html.

     COPYRIGHT NOTICE

     Copyright (C) The Internet Society (2003).  All Rights
     Reserved.

     SUMMARY

     A message originator sometimes wishes to send content
     that is in a form the recipient cannot process.  In
     order for the recipient to process the content, the
     content must be converted to a related form, with the
     same or with restricted information, such as changing
     from color to black and white.  In a store-and-forward
     environment, it can be convenient to have this
     conversion performed by an intermediary.



     CONTENTS

     1.   Introduction
     2.   Conventions
     3.   Service Specification
     3.1. Sending Permission
     3.2. Returning Capabilities
     3.3. Next-Hop Non-Support of Service
     4.   Content Conversion Permission SMTP Extension
     4.1. Content Conversion Permission service extension
          definition
     4.2. CONPERM parameter to Mail-From
     4.3. Syntax
     5.   Content Negotiation SMTP extension
     5.1. Content Negotiation service extension definition
     5.2. CONNEG parameter to RCPT-TO
     5.3. Syntax
     6.   MIME CONTENT-CONVERT Header
     7.   MIME Content-Converted Header
     8.   EXAMPLES
     8.1. CONPERM Negotiation
     8.2. Example CONNEG Negotiation
     8.3. Content-Converted
     9.   IANA Considerations
     10.  Security Considerations
     11.  Acknowledgements
     12.  References (Normative)
     13.  AuthorsÆ Addresses
     14.  Full Copyright Statement
     Appendix A:   CONNEG with Direct SMTP



1.   INTRODUCTION

     A message originator sometimes wishes to send content
     that is in a form the recipient cannot process.  This
     specification enables MIME content conversion on behalf
     of a message originator and a message recipient. It
     defines a means of matching message content form to the
     capabilities of a recipient device or system, through
     an SMTP-based negotiation mechanism.  An SMTP client is
     given permission by an email originator to request and
     use information about content capabilities of the
     target device or system that is serviced by an SMTP
     server.  An SMTP server reports the targetÆs content
     capabilities back to the SMTP client, and the client is
     then able to convert message content to a form that is
     supported by the target device or system.

     This specification provides mechanisms to support such
     a conversion service, through an ESMTP hop-by-hop
     service.  It uses two SMTP service extensions: CONPERM
     and CONNEG, and two MIME Content headers: Content-
     Conversion and Content-Converted

     An example email relay environment is shown here:

      +------------+                        +-----------+
      | Originator |                        | Recipient |
      +------------+                        +-----------+
            ||Posting                   Delivering/\
            \/                                    ||
        +--------+    +-----------------+    +--------+
        |  SMTP  |    |    SMTP Relay   |    |  SMTP  |
        | Client |--->| Server | Client |--->| Server |
        +--------+    +--------+--------+    +--------+

     SMTP host permission to perform specified content
     conversions is communicated by message senders, through
     the ESMTP CONPERM service extension and MIME Content-
     Conversion headers.  Target device or system
     capabilities are communicated in SMTP sessions through
     the ESMTP CONNEG service extension.

     Conversions are performed by the first ESMTP host that
     can obtain both the senderÆs permission and the
     recipientÆs capabilities.   When an SMTP relay or
     server performs content conversion, it records which
     specific conversions are made, into Content-Converted
     MIME headers associated with each, converted MIME body-
     part.

          [[EditorÆs note:  The specification does not
          provide for sending an MDN back to the originator,
          when a conversion is performed.  Without
          CONPERM/CONNEG, conversions are performed by the
          recipient.  Therefore it is acceptable to ensure
          that the recipient, rather than the originator, is
          informed of conversions.  This is achieved with
          Content-Converted.  Informing the Originator of
          conversions could generate a substantial increase
          in email control traffic.  Note that conversion by
          a recipient does not currently result in
          notification of the originator.]]

     When a relay or client is unable to transmit the
     message to a next-hop that supports CONPERM or to
     perform appropriate conversion, then it terminates
     message transmission and returns a [DSN] to the
     originator.



2.   CONVENTIONS

     In examples, "C:" and "S:" indicate lines sent by the
     client and server respectively.

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
     NOT", and "MAY" in this document are to be interpreted
     as defined in "Key words for use in RFCs to Indicate
     Requirement Levels" [KEYWORDS].



3.   SERVICE SPECIFICATION

     This service integrates two ESMTP extensions and two
     MIME content-types, to permit authorized, accountable
     content form conversion by intermediaries.
     Intermediaries are ESMTP hosts (clients and servers)
     along the transmission path between an originator and a
     recipient.

     Authorization is provided to intermediaries by the
     originator, through ESMTP CONPERM. Authorized
     conversions are specified in MIME Content-Convert
     headers.  Recipient capabilities are communicated to
     intermediaries by ESMTP CONNEG, and a record of
     conversions is placed into MIME Content-Converted
     headers.

     CONPERM and CONNEG operate on a per-message basis.
     Therefore they are issued through the ESMTP MAIL-FROM
     and RCPT-TO request.  CONNEG response information is
     provided on a per-recipient basis, through the response
     to ESMTP RCPT-TO.

     Conversion is performed by the first intermediary that
     obtains recipient capability information.  When an
     intermediary obtains different capability information
     for different recipients of the same message, it has
     the choice of creating a single, converted copy of the
     content that can be supported by all of the recipients,
     or it can create multiple converted copies, each
     version sent separately, and matching a subset of the
     recipients.

     A special case of differential capabilities occurs when
     an intermediary receives capability information about
     some recipients, but no information about others.  An
     example of this scenario can occur when sending a
     message to some recipients within oneÆs own
     organization and other recipients located elsewhere.
     The intermediary might have capability information
     about the local recipients, but will not have any for
     distant recipients. This is treated as a variation of
     the handling required when the permissible conversions
     are the null set.  However, rather than simply failing
     transmission to the recipients for which there is no
     capability information, the intermediary MAY choose to
     send the original content to those recipients, via the
     CONPERM mechanism.

3.1.      Sending Permission

     +------------+
     | Originator |
     +------------+
      SMTP  ||
       or   || CONPERM
     SUBMIT \/
        +--------+            +----------------+
        |  SMTP  |   SMTP     |    SMTP Relay  |
        | Client |----------->| Server |       |
        +--------+  CONPERM   +--------+-------+

     A message originator that permits content conversion by
     intermediaries MAY use the CONPERM ESMTP service
     extension and Content-Conversion MIME headers to
     indicate what conversions are permitted by
     intermediaries.  Other mechanisms by which a message
     originator communicates this permission to the SMTP
     message transfer service are outside the scope of this
     specification.

     When an ESMTP client is authorized to participate in
     the CONPERM service it MUST interact with the next SMTP
     hop server, about:

     *    The serverÆs ability to support authorized conversions,
          through ESMTP CONPERM
     *    The capabilities supported for the target device or
          system, through ESMTP CONNEG

                                           +-----------+
                                           | Recipient |
                                           +-----------+
                                     Capabilities||
                                                 \/
                  +----------------+         +--------+
                  |   SMTP Relay   |  CONNEG |  SMTP  |
                  |       | Client |<--------| Server |
                  +-------+--------+         +--------+

3.2.      Returning Capabilities

     A target recipient device or system communicates its
     capabilities to the SMTP service through a means
     outside the scope of this specification.  When an ESMTP
     server knows a targetÆs capabilities, it MAY offer the
     CONNEG ESMTP service extension.

     When a message is being processed according to this
     specification, if a next-hop ESMTP server responds that
     it supports CONNEG, then the SMTP client:

     (1)  MUST request CONNEG information

     (2)  MUST perform the requisite conversions before sending
          the message to the next-hop SMTP server

     (3)  MUST add a Content-Converted header to each MIME body-
          part that has been converted and must specify the previous
          form of the body-part and the current form.

     When performing conversions, the Client MUST either:

     (1)  Send a single copy to the next-hop SMTP server, using a
          best capabilities that are supported to all recipients along
          that path, or

     (2)  Separate the transfers, to provide the best conversions
          possible for subsets of the recipient.

     If  the transfers are separated, then the current
     session MUST be terminated, and new sessions conducted
     for each subset.

     The conversions that are performed are determined by
     the intersection of three lists:

     *    Conversions permitted by the sender
     *    Content capabilities of the target
     *    Conversions that can be performed by the SMTP client
          host

     If the result of this intersection is the null set of
     representations, for an addressee, then delivery to
     that addressee MUST be handled as a failure.

     If the next-hop SMTP host does not indicate that it can
     represent the targetÆs capabilities through CONNEG, but
     does respond that it can support CONPERM, then the
     client SMTP MUST send the existing content, if all
     other SMTP transmission requirements are satisfied.

3.3.      Next-Hop Non-Support of Service

     If a Client is participating in this service, but the
     next-hop SMTP server does not support CONPERM and does
     not support CONNEG, then the SMTP client

     (1)  MUST terminate the session to the next-hop SMTP server,
          without sending the message

     (2)  MUST return a DSN notification to the originator that
          content negotiation could not be performed.

     If a Client is participating in this service and the
     next-hop SMTP server supports CONNEG but provides no
     capabilities for an individual RCPT-TO addressee, then
     the SMTP clientÆs processing for that recipient MUST be
     either to:

     (1)  Treat the addressee as rejected, or

     (2)  Separate the addressee from the address list that is
          processed according to CONNEG, and continue to process the
          addressee according to CONPERM.



4.   CONTENT CONVERSION PERMISSION SMTP EXTENSION

4.1.      Content Conversion Permission service extension
     definition

     (1)  The name of the SMTP service extension is

          "Content_Conversion_Permission"

     (2)  The EHLO keyword value associated with this extension
          is

          "CONPERM"

     (3)  A parameter using the keyword "CONPERM" is added to the
          MAIL-FROM command

     (4)  The server responds with acceptance or rejection of
          support for CONPERM, for this message

4.2.      CONPERM parameter to Mail-From

     Parameter:

          CONPERM

     Arguments:

          There are no arguments.  Specification of
     permitted conversions is located in a Content-
     Conversion header for each MIME body-part for which
     conversion is permitted.

     Client Action:

          If the server issued a 250-CONPERM, as part of its
     EHLO response for the current session, and the client
     is participating in the CONPERM service for this
     message -- such as by having received the message with
     a CONPERM requirement -- then the client MUST issue the
     CONPERM parameter in the MAIL-FROM.   If the server
     does not issue  250-CONPERM, and the client is
     participating in the CONPERM service for this message,
     then the client MUST treat the transmission as
     permanently rejected.

     Server Action:

          If the client specifies CONPERM in the MAIL-FROM,
     but the server does not support the CONPERM parameter,
     the server MUST reject the MAIL-FROM command with a 504-
     CONPERM reply.

          If the client issues the CONPERM parameter in the
     MAIL-FROM, then the server MUST conform to this
     specification. Either it must relay the message
     according to CONPERM, or it must convert the message
     according to CONNEG information.

4.3.      Syntax

     Content_Conversion_Permission =    "CONPERM"



5.   CONTENT NEGOTIATION SMTP EXTENSION

5.1.      Content Negotiation service extension definition

     (1)  The name of the SMTP service extension is:

          "Content_Negotiation"

     (2)  The EHLO keyword value associated with this extension
          is:

           "CONNEG"

     (3)  A parameter using the keyword "CONNEG" is added to the
          RCPT TO command

     (4)  The server responds with a report of the content
          capabilities of the device or system that embodies each
          target RCPT-TO address.

5.2.      CONNEG parameter to RCPT-TO

     Parameter:

          CONNEG

     Arguments:

          There are no arguments.

     Client Action:

          If message is subject to CONPERM requirements and
     the server issues a 250-CONNEG, as part of its EHLO
     response for the current session, the client MUST issue
     the CONNEG parameter in the RCPT-TO request. If the
     message is not subject to CONPERM requirements and the
     server issues a 250-CONNEG, the client MAY issue the
     CONNEG parameter with RCPT-TO.

          If the client issues the CONNEG parameter with
     RCPT-TO, then it MUST honor the capabilities specified
     in the CONNEG RCPT-TO replies for that message, and
     convert the message content, so that the target can
     accept the data.

          The conversions that are performed are determined
     by the intersection of the:

          *    Conversions permitted by the sender
          *    Content capabilities of the target
          *    Conversions that can be performed by the SMTP client
               host

          If the result of this intersection is the null set
     of representations, then the Client processing depends
     upon whether the message is subject to CONPERM
     processing:

          (1)  If the message is subject to CONPERM, the Client MAY
               continue to transmit the original content, according to
               CONPERM.

          (2)  Otherwise, the Client MUST treat the address as
               rejected.

          If the result of the intersection is not null, the
     client SHOULD convert the data to the "highest" level
     of capability of the server.  Determination of the
     level that is highest is left to the discretion of the
     server.

          The client MUST record the nature of the
     conversion by using the MIME Content-Converted header
     for each converted MIME body-part, indicating the
     previous and new body-part form.

     Server Action:

          If the client specifies CONNEG in the RCPT-TO, but
     the server does not support the CONNEG parameter, the
     server MUST reject the RCPT-TO addressees with 504
     replies.

          If the server does support the CONNEG parameter
     and it knows the capabilities of the target device or
     system, then it MUST provide that information through
     CONNEG.

          The response to a CONNEG RCPT-TO request will be
     multi-line RCPT-TO replies.  For successful (250)
     responses, at least the first line of the response is
     for RCPT-TO information other than CONNEG.  Additional
     response lines are for CONNEG.    In order to avoid
     problems due to variations in line buffer sizes, the
     total parametric listing must be provided as a series
     of lines, each beginning with "250-CONNEG " except for
     the last line, which is "250 CONNEG".

          The contents of the capability listing MUST
     conform to the specifications in [FAX].

5.3.      Syntax

     Content_Negotiation =    "CONNEG"
     Capability =             <<as per [FAX]>>



6.   MIME CONTENT-CONVERT HEADER

     Content-Convert is an optional header field that
     specifies permitted conversions for the associated
     content. In its absence, the content originator has
     provided no guidance about content conversions.
     Therefore intermediaries SHOULD NOT perform content
     conversion.

     It is desirable to keep the set of possible disposition
     types small and well defined, to avoid needless
     complexity. Even so, evolving usage will likely require
     the definition of additional disposition types or
     parameters, so the set of disposition values is
     extensible; see below.

     In the extended ABNF notation, the Content-Convert
     header field is defined as follows:

     Convert =                "Content-convert" ":"
                              permitted

     Permitted =              "ANY" / <<permitted
                              conversions, per [FAX]>>

     If the permitted conversions are specified as "ANY"
     then the intermediary may perform any conversions it
     deems appropriate.



7.   MIME CONTENT-CONVERTED HEADER

     When an intermediary has performed conversion of the
     associated content, the intermediary MUST record the
     nature of the conversion that was performed.  This
     information is placed in a Content-Converted header
     associated with the converted content.

     In the extended ABNF notation, the Content-Converted
     header field is defined as follows:

     converted =         "Content-converted" [CFWS] ":"
                         [CFWS]
                         "Date " [CFWS] date-time [CFWS]";"
                         [CFWS]
                         "By " [CFWS] domain [CFWS]";"
                         [CFWS]
                         "Old " [CFWS] type [CFWS]";" [CFWS]
                         "New " [CFWS] type [CFWS]

     domain =            <<Per [IMF], domain name of
                         intermediary that performed
                         conversion>>

     date-time =         <<Per [IMF], date and time at which
                         conversion was performed>>

     type =              <<content characteristics, per
                         [FAX], without alternatives>>



8.   EXAMPLES

8.1.      CONPERM Negotiation

     S: 220 example.com IFAX
     C: EHLO example.com
     S: 250- example.com
     S: 250-DSN
     S: 250 CONPERM
     C: MAIL FROM:May@some.example.com CONPERM
     S: 250 <May@some.example.com> sender ok
     C: RCPT TO:<June@some.example.com>
     S: 250-<June@some.example.com> recipient ok
     C: DATA
     S: 354 okay, send data
     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
        Per:
        (  image-file-structure=TIFF-minimal
           dpi=400
           image-coding=JBIG
           size-x=2150/254
           paper-size=letter
        )
        with MIME body-parts including:
        CONTENT-CONVERT:
           (&(image-file-structure=TIFF-minimal)
             (MRC-mode=0)
             (color=Binary)
             (|(&(dpi=204)
                 (dpi-xyratio=[204/98,204/196]) )
               (&(dpi=200)
                 (dpi-xyratio=[200/100,1]) )
               (&(dpi=400)
                 (dpi-xyratio=1) ) )
             (|(image-coding=[MH,MR,MMR])
               (&(image-coding=JBIG)
                 (image-coding-constraint=JBIG-T85)
                 (JBIG-stripe-size=128) ) )
             (size-x<=2150/254)
             (paper-size=[letter,A4])
             (ua-media=stationery) )
        >>
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye


8.2.      Example CONNEG Negotiation

     S: 220 example.com IFAX
     C: EHLO example.com
     S: 250- example.com
     S: 250-DSN
     S: 250 CONNEG
     C: MAIL FROM:<May@some.example.com>
     S: 250 <May@some.example.com> sender ok
     C: RCPT TO:<June@ifax1.jp> CONNEG
     S: 250-<June@some.example.com> recipient ok
     S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
     S: 250-CONNEG   (MRC-mode=0)
     S: 250-CONNEG   (color=Binary)
     S: 250-CONNEG   (|(&(dpi=204)
     S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
     S: 250-CONNEG     (&(dpi=200)
     S: 250-CONNEG       (dpi-xyratio=[200/100,1]) ) )
     S: 250-CONNEG   (image-coding=[MH,MR,MMR])
     S: 250-CONNEG   (size-x<=2150/254)
     S: 250-CONNEG   (paper-size=[letter,A4])
     S: 250 CONNEG   (ua-media=stationery) )
     C: DATA
     S: 354 okay, send data
     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
          Per:
          (  image-file-structure=TIFF-minimal
             dpi=400
             image-coding=JBIG
             size-x=2150/254
             paper-size=letter
           )
        >>
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye


8.3.      Content-Converted
     Content-converted:
        Date  Tue, 1 Jul 2001 10:52:37 +0200 ;
        By  relay.example.com ;
        Old
           (&(image-file-structure=TIFF-minimal)
             (MRC-mode=0)
             (color=Binary)
             (&(dpi=400)
               (dpi-xyratio=1) )
             (&(image-coding=JBIG)
               (image-coding-constraint=JBIG-T85)
               (JBIG-stripe-size=128) )
             (size-x=2150/254)
             (paper-size=A4)
             (ua-media=stationery) ) ;
        New
           (&(image-file-structure=TIFF-minimal)
             (MRC-mode=0)
             (color=Binary)
             (&(dpi=200)
               (dpi-xyratio=1) )
             (image-coding=MMR)
             (size-x=2150/254)
             (paper-size=letter)
             (ua-media=stationery) )



9.   IANA CONSIDERATIONS

     This memo is not intended to create any new issues for
     IANA.



10.       SECURITY CONSIDERATIONS

     This service calls for participants to disclose their
     capabilities.  Mechanisms for determining the
     requestorÆs and the respondentÆs authenticated identity
     are outside the scope of this specification.  It is
     intended that these mechanisms permit disclosure of
     public information; hence there is no particular need
     for security measures.

     However there is nothing to prevent disclosure of
     sensitive information that should receive restricted
     distribution.  It is, therefore, the responsibility of
     the disclosing ESMTP server or disclosing ESMTP client
     to determine whether additional security measures
     should be applied to the use of this ESMTP option.



11.       ACKNOWLEDGEMENTS

     Graham Klyne and Eric Burger provided diligent review
     and useful suggestions.



12.       REFERENCES (NORMATIVE)

     [DISPLAY]      Masinter, L., Holtman, K., Mutz, A. and
                    D. Wing, "Media Features for Display,
                    Print, and Fax", RFC 2534, March 1999.

     [DSN]          Moore, K., "SMTP Service Extension for
                    Delivery Status Notifications", RFC
                    1892, January 1996.

     [ESMTP1]       Klensin, J., Freed, N., Rose, M.,
                    Stefferud, E. and D. Crocker, "SMTP
                    Service Extensions", RFC 1869, November
                    1995

     [ESMTP2]       Klensin, J., "Simple Mail Transfer
                    Protocol", RFC 2821, April 2001.

     [FAX]          McIntyre, L. and G. Klyne, "Content
                    Feature Schema for Internet Fax", RFC
                    2879, August 2000

     [IMF]          Resnick, P., "Internet Message Format",
                    RFC 2822, April 2001

     [TAG]          Holtman, K., Mutz, A. and T. Hardie,
                    "Media Feature Tag Registration
                    Procedure", RFC 2506, March 1999.

     [SETS]         Klyne, G., "A syntax for describing
                    media feature sets", RFC 2533, March
                    1999.



13.       AUTHORSÆ ADDRESSES

     Kiyoshi Toyoda
     Network Technology Development Center
     Panasonic Communications Co., Ltd.
     2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan

     tel: +81-3-5434-7161
     fax: +81-3-5434-7156
     toyoda.kiyoshi@jp.panasonic.com


     Dave Crocker
     Brandenburg InternetWorking
     675 Spruce Drive
     Sunnyvale, CA  94086  USA

     Tel: +1.408.246.8253
     dcrocker@brandenburg.com



14.       FULL COPYRIGHT STATEMENT

     Copyright (C) The Internet Society (2003).  All Rights
     Reserved.

     This document and translations of it may be copied and
     furnished to others, and derivative works that comment
     on or otherwise explain it or assist in its
     implementation may be prepared, copied, published and
     distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and
     derivative works.  However, this document itself may
     not be modified in any way, such as by removing the
     copyright notice or references to the Internet Society
     or other Internet organizations, except as needed for
     the purpose of developing Internet standards in which
     case the procedures for copyrights defined in the
     Internet Standards process must be followed, or as
     required to translate it into languages other than
     English.

     The limited permissions granted above are perpetual and
     will not be revoked by the Internet Society or its
     successors or assigns.

     This document and the information contained herein is
     provided on an "AS IS" basis and THE INTERNET SOCIETY
     AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
     WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
     LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
     PARTICULAR PURPOSE.



APPENDIX A:   CONNEG WITH DIRECT SMTP

     In some configurations it is possible to have direct
     email-based interactions -- where the originator's
     system conducts a direct, interactive TCP connection
     with the recipient's system.  This configuration
     permits a use of CONPERM/CONNEG that conforms to the
     specification here, but it also permits some
     simplifications, because there is a single SMTP
     session, rather than multiple, relaying sessions.

     The Originator's system provides user-level functions
     for the originator, and it contains the SMTP Client for
     sending messages. Hence, the formal step of email
     "posting" is a process that is internal or virtual,
     within the Originating system.  The recipient's service
     contains the user-level functions for the recipient,
     and it contains the SMTP server, for receiving
     messages. Hence the formal steps of email "delivering"
     and "receipt" are internal or virtual, within the
     Receiving system.

     The figure below shows these relationships:

      Originating system       Receiving system
     +------------------+     +-----------------+
     |  +------------+  |     |  +-----------+  |
     |  | Originator |  |     |  | Recipient |  |
     |  +------------+  |     |  +-----------+  |
     |       ||Posting  |     |      /\Receipt  |
     |       \/         |     |      ||         |
     |   +---------+    |     |   +--------+    |
     |   |  SMTP   |<---|-----|---|  SMTP  |    |
     |   | Client  |----|-----|-->| Server |    |
     |   +---------+    |     |   +--------+    |
     +------------------+     +-----------------+

     In this case CONPERM is not needed, because the SMTP
     Client is part of the originating system.  Therefore it
     already has the necessary permission.  Similarly, the
     SMTP server will be certain to know the recipient's
     capabilities, because the server is part of the
     receiving system.

     *    For Originating systems that conform to this
          specification and are operating in a Direct SMTP mode, the
          communication process between originator and recipient is
          the same as would take place between the last-hop SMTP Relay
          and the Delivering SMTP server.  That is, the Client and
          Server MUST employ CONNEG and the Client MUST perform any
          requisite conversions.


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/