One document matched: draft-ietf-fax-esmtp-conneg-08.txt-36674.txt
Differences from 08.txt-07.txt
Network Working Group K. Toyoda, MGCS
Internet Draft D. Crocker, Brandenburg
draft-ietf-fax-esmtp-conneg-08.txt June 2003
Expires: <12-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 sends content in a form
the recipient cannot process. Such content needs to 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. This specification integrates two
ESMTP extensions and three MIME content-types, to
permit authorized, accountable content form conversion
by intermediaries.
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-Previous Header
8. MIME Content-Features Header
9. Examples
9.1. CONPERM Negotiation
9.2. Example CONNEG Negotiation
9.3. Content-Previous
10. IANA Considerations
11. Security Considerations
12. Acknowledgements
13. References
14. Authors' Addresses
15. Full Copyright Statement
Appendix A: CONNEG with Direct SMTP
1. INTRODUCTION
A message originator sometimes sends content 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. 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 three MIME Content headers (Content-
Convert, Content-Converted and Content-Features).
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-
Convert 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
and Content-Features MIME headers associated with each,
converted MIME body-part.
Note: The specification does not provide for
sending an MDN back to the originator, when a
conversion is performed. If there is no use
of CONPERM/CONNEG, then 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-Previous and Content-
Features. Informing the Originator of conversions
could generate a substantial increase in email
control traffic. Note that any conversion done 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 three
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.
The MIME headers occur in each MIME body-part to which
they apply. That is, each MIME body-part contains its
own record of conversion permission and history.
Originator Action:
The originator MAY indicate authorization for
intermediaries to perform conversions, by using the
ESMTP CONPERM service extension when posting a new
message. Authorized conversions MUST be specified in
MIME Content-Convert headers, in each MIME body-part
for which conversions are authorized.
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+
Recipient Action:
Recipient capabilities SHOULD be communicated to
intermediaries by the ESMTP CONNEG service extension.
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+
Intermediary Actions:
An intermediary MAY be given CONPERM direction
when receiving a message, and MAY be given CONNEG
guidance, before sending the message. CONPERM and
CONNEG operate on a per-message basis. Therefore they
are issued through the ESMTP MAIL-FROM request. CONNEG
response information is provided on a per-recipient
basis, through the response to ESMTP RCPT-TO.
Conversion MUST be performed by the first CONPERM
intermediary that obtains CONNEG recipient capability
information. When an intermediary obtains different
capability information for different recipients of the
same message, it MAY either:
* Create a single, converted copy of the content that
can be supported by all of the recipients, or
* Create multiple converted copies, matching the
capabilities of subsets of the recipients. Each
version is then sent separately, to an appropriate
subset of the recipients.
A record of conversions is placed into MIME
Content-Previous headers. The current form of the
content is provided in MIME Content-Features headers.
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 -- that is, no valid conversions are
possible for a recipient.
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. Hence, the handling for such recipients is
performed as if no CONNEG transaction took place.
Once an intermediary has performed conversion, it
MAY terminate use of CONPERM. However some relay
environments, such as those re-directing mail to a new
target device, will benefit from further conversion.
Intermediaries MAY continue to use CONPERM or MAY re-
initiate CONPERM use, when they have knowledge about
possible variations in target device.
3.1. Sending Permission
A message originator that permits content conversion by
intermediaries MAY use the CONPERM ESMTP service
extension and Content-Convert 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
Successful use of CONPERM does not require that
conversion take place along the message transfer path.
Rather, it requires that conversion take place whenever
a next-hop server reports recipient capabilities,
through CONNEG, and those capabilities do not include
support for the current representation of the content.
It is acceptable to have every SMTP server -- including
the last-hop server -- support CONPERM, with none
offering CONNEG. In this case, the message is
delivered to the recipient in its original form. Any
possible conversions to be performed are left to the
recipient. Hence the recipient is given the original
form of the content, along with an explicit list of
conversions that the originator deems acceptable.
An SMTP server MAY offer ESMTP CONPERM, without being
able to perform conversions, if it knows that
conversions can be performed by the target device or
system.
3.2. Returning Capabilities
A target recipient device or system communicates its
content form 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, if
possible, before sending the message to the
next-hop SMTP server
(3) MUST fail message processing, if any conversion
for the message fails, and MUST return a failure
DSN to the originator
(4) MUST add a Content-Previous header and a Content-
Features header to each MIME body-part that has
been converted.
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 recipients.
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
Failed Conversion
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 conversion 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
to:
(1) Treat the addressee as a conversion failure, and
(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-Convert
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 returned
in the CONNEG RCPT-TO replies for that message, and it
MUST convert the message content, if the current form
of the content is not included in the recipient
capabilities.
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 conversion
as failed.
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
host performing the conversion.
Each converted MIME body-part, MUST have a Content-
Converted header that indicates the previous body-part
form and a Content-Features header, indicating the 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 [SYN, FAX].
5.3. Syntax
Content_Negotiation = "CONNEG"
Capability = <<as per [SYN, FAX]>>
6. MIME CONTENT-CONVERT HEADER
Content-Convert is an optional header field that
specifies permitted conversions for the associated
content. It MAY be used without the other mechanisms
defined in this document. If present, this header MUST
be carried unmodified and delivered to the recipient.
In its absence the content originator has provided no
guidance about content conversions, and intermediaries
SHOULD NOT perform content conversion.
In the extended ABNF notation, the Content-Convert
header field is defined as follows:
Convert = "Content-convert" ":"
permitted
Permitted = "ANY" / "NONE" /
<<permitted conversions, per
[SYN, FAX]>>
If the permitted conversions are specified as "ANY"
then the intermediary may perform any conversions it
deems appropriate. If the permitted conversions are
specified as "NONE" then the intermediary SHOULD NOT
perform any conversions to this MIME body-part, even
when the target device or system does not support the
original form of the content.
7. MIME CONTENT-PREVIOUS HEADER
When an intermediary has performed conversion of the
associated content, the intermediary MUST record
details of the previous representation, from which the
conversion was performed. This information is placed
in a Content-Previous header that is associated with
the MIME body-part having converted content. There is a
separate header for each, converted MIME body-part.
In the extended ABNF notation, the Content-Previous
header field is defined as follows:
previous = "Content-Previous" [CFWS] ":"
[CFWS]
date by type
date "Date " [CFWS] date-time [CFWS]";"
[CFWS]
by "By " [CFWS] domain [CFWS]";"
[CFWS]
type = <<content characteristics, per
[SYN, FAX], without alternatives>>
The Date field specifies the date and time at which the
indicated representation was converted into a newer
representation.
The By field specifies the domain name of the
intermediary that performed the conversion.
An intermediary MAY choose to derive the Content-
Previous header, for a body-part, from an already-
existing Content-Features header in that body-part,
before that header is replaced with the description of
the current representation.
8. MIME CONTENT-FEATURES HEADER
When an intermediary has performed conversion, the
intermediary MUST record details of the result of the
conversion that was performed. This information is
placed in a Content-Features header associated with
each MIME body-part having converted content. There is
a separate Content-Features header for each MIME body-
part.
The specification for this header is contained in
[FEAT].
9. EXAMPLES
9.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: image/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
9.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: image/tiff
Per:
( image-file-structure=TIFF-minimal
dpi=200
image-coding=MMR
size-x=2150/254
paper-size=letter
)
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
9.3. Content-Previous
Content-Previous:
Date Tue, 1 Jul 2001 10:52:37 +0200;
By relay.example.com;
(&(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) )
10. IANA CONSIDERATIONS
This memo is not intended to create any new issues for
IANA.
11. SECURITY CONSIDERATIONS
This service calls for recipients 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 information that can safely be public; hence there
is no inherent 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.
12. ACKNOWLEDGEMENTS
Graham Klyne and Eric Burger provided extensive,
diligent reviews and suggestions.
13. REFERENCES
Normative:
[DISP] 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
[FEAT] Klyne, G., "Indicating Media Features
for MIME Content", RFC 2912, September
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.
[SYN] Klyne, G. "A Syntax for Describing Media
Feature Sets", RFC 25343, March 1999
14. 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
15. 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 the content form negotiation service
that conforms to the specification here, but permits
some simplifications. This single SMTP session does
not have the complexity of multiple, relaying sessions
and therefore does not have the requirement for
propagating permissions to intermediaries.
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 | | /\Receiving |
| \/ | | || |
| +---------+ | | +--------+ |
| | 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.
Therefore, Direct Mode email transmission can achieve
content capability and form matching by having:
* Originating systems that conform to this
specification 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.
| PAFTECH AB 2003-2026 | 2026-04-23 11:48:15 |