Internet DRAFT - draft-ietf-opes-smtp
draft-ietf-opes-smtp
Open Pluggable Edge Services M. Stecher
Internet-Draft CyberGuard
Expires: April 16, 2006 C. Perz
All About IT
October 13, 2005
SMTP adaptation with OPES
draft-ietf-opes-smtp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms such as OPES tracing, OPES bypass,
and OPES callout protocol. This document extends those generic
mechanisms for Simple Mail Transfer Protocol (SMTP) adaptation.
Together, application-agnostic OPES documents and this SMTP profile
constitute a complete specification for SMTP adaptation with OPES.
Stecher & Perz Expires April 16, 2006 [Page 1]
Internet-Draft SMTP adaptation with OPES October 2005
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES Document Map . . . . . . . . . . . . . . . . . . . . . . 4
3. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Application Message Parts . . . . . . . . . . . . . . . . 6
3.2 Application Profile Features . . . . . . . . . . . . . . . 7
3.2.1 Profile Parts . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Profile Structure . . . . . . . . . . . . . . . . . . 8
3.2.3 Adaptive-Parts . . . . . . . . . . . . . . . . . . . . 9
3.2.4 Informative-Parts . . . . . . . . . . . . . . . . . . 9
3.2.5 Header-List . . . . . . . . . . . . . . . . . . . . . 10
3.2.6 Negotiation Examples . . . . . . . . . . . . . . . . . 11
3.3 DUM and DUY Messages . . . . . . . . . . . . . . . . . . . 12
3.3.1 AM-Part Parameter . . . . . . . . . . . . . . . . . . 13
3.3.2 Allow Parameter . . . . . . . . . . . . . . . . . . . 14
3.3.3 SMTP-Error Parameter . . . . . . . . . . . . . . . . . 15
3.3.4 Advice Parameter . . . . . . . . . . . . . . . . . . . 16
3.3.5 Add-Header Parameter . . . . . . . . . . . . . . . . . 16
3.4 SMTP Extension handling . . . . . . . . . . . . . . . . . 17
3.4.1 Negotiating SMTP Extensions . . . . . . . . . . . . . 18
3.4.2 Transfer of extension information . . . . . . . . . . 18
3.4.3 Extension meta information . . . . . . . . . . . . . . 19
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Tracing Headers . . . . . . . . . . . . . . . . . . . . . 21
4.2 SMTP Trace Extension . . . . . . . . . . . . . . . . . . . 22
5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1 Normative References . . . . . . . . . . . . . . . . . . . 30
9.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
Stecher & Perz Expires April 16, 2006 [Page 2]
Internet-Draft SMTP adaptation with OPES October 2005
1. Scope
The Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms such as OPES processor and endpoints
communications [RFC3897] or OPES callout protocol [RFC4037]. This
document extends those generic mechanisms for adaptation of a
specific application protocol, SMTP [RFC2821]. Together,
application-agnostic OPES documents and this SMTP profile constitute
a complete specification for SMTP adaptation with OPES.
The primary sections of this document specify SMTP-specific
extensions for the corresponding application-agnostic mechanisms
documented elsewhere.
Stecher & Perz Expires April 16, 2006 [Page 3]
Internet-Draft SMTP adaptation with OPES October 2005
2. OPES Document Map
This document belongs to a large set of OPES specifications produced
by the IETF OPES Working Group. Familiarity with the overall OPES
approach and typical scenarios is often essential when trying to
comprehend isolated OPES documents. This section provides an index
of OPES documents to assist the reader with finding "missing"
information.
o The document on "OPES Use Cases and Deployment Scenarios"
[RFC3752] describes a set of services and applications that are
considered in scope for OPES and have been used as a motivation
and guidance in designing the OPES architecture.
o Usecases specifically for SMTP that are motivation for the SMTP
adaptation described in this document have been lised in "OPES
SMTP Use Cases" [I-D.ietf-opes-smtp-use-cases].
o The OPES architecture and common terminology are described in "An
Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o "Policy, Authorization and Enforcement Requirements of OPES"
[RFC3838] outlines requirements and assumptions on the policy
framework, without specifying concrete authorization and
enforcement methods.
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk
analysis, without recommending specific solutions.
o "OPES Treatment of IAB Considerations" [RFC3914] addresses all
architecture-level considerations expressed by the IETF Internet
Architecture Board (IAB) when the OPES WG was chartered.
o At the core of the OPES architecture are the OPES processor and
the callout server, two network elements that communicate with
each other via an OPES Callout Protocol (OCP). The requirements
for such protocol are discussed in "Requirements for OPES Callout
Protocols" [RFC3836].
o "OPES Callout Protocol Core" [RFC4037] specifies an application
agnostic protocol core to be used for the communication between
OPES processor and callout server.
o "OPES entities and end points communications" [RFC3897] specifies
generic tracing and bypass mechanisms for OPES.
o The OCP Core and Communications documents are independent from the
application protocol being adapted by OPES entities. Their
Stecher & Perz Expires April 16, 2006 [Page 4]
Internet-Draft SMTP adaptation with OPES October 2005
generic mechanisms have to be complemented by application-specific
profiles. This document, SMTP adaptation with OPES, is such an
application profile for SMTP. It specifies how application-
agnostic OPES mechanisms are to be used and augmented in order to
support adaptation of SMTP messages.
o Finally, "P: Message Processing Language" [I-D.ietf-opes-rules-p]
defines a language for specifying what OPES adaptations (e.g,
translation) must be applied to what application messages (e.g.,
e-mail from bob@example.com). P language is meant for configuring
application proxies (OPES processors).
Stecher & Perz Expires April 16, 2006 [Page 5]
Internet-Draft SMTP adaptation with OPES October 2005
3. Callout Protocol
This section documents the SMTP profile for the OPES Callout Protocol
(OCP) Core [RFC4037]. Familiarity with OCP Core is required to
understand the SMTP profiles. This section uses OCP Core
conventions, terminology, and mechanisms.
The OPES processor communicates its desire to adapt SMTP messages via
a Negotiation Offer (NO) message with SMTP-specific feature
identifiers documented in Section 3.2. SMTP-specific OCP
optimization mechanisms can be negotiated at the same time. A
callout server that supports adaptation of SMTP messages has a chance
to negotiate what SMTP message parts will participate in adaptation,
including SMTP commands and email body elements as application
message parts documented in Section 3.1.
3.1 Application Message Parts
An SMTP message may have several well-known parts: SMTP commands such
as HELO, MAIL, RCPT and email content sent after the DATA command.
The email content has a header and a body; and the email body again
can be divided into several sections.
An SMTP OPES processor has to have information about at least some
SMTP message parts (of those SMTP commands it supports). It may or
may not be able to divide the email content into parts. A callout
server may want to ask the OPES processor to do email content
preprocessing for a more efficient OCP handling. The agents will
negotiate the capabilities of the OPES processor and the needs of the
callout server using the application message parts in additional
parameters that will be defined for the Negotiation Offer (NO) and
Negotiation Response (NR) messages in Section 3.2.1.
The following is the declaration of am-part (application message
part) type using OCP Core Protocol Element Type Declaration Mnemonic
(PETDM):
am-part: extends atom;
am-parts: extends list of am-part;
Figure 1
The following "am-part" atoms are valid values:
EHLO: The argument of the Extended HELLO command as defined in
section 4.1.1.1 of [RFC2821].
Stecher & Perz Expires April 16, 2006 [Page 6]
Internet-Draft SMTP adaptation with OPES October 2005
HELO: The argument of the HELLO command as defined in section 4.1.1.1
of [RFC2821].
MAIL: The argument of the MAIL command as defined in section 4.1.1.2
of [RFC2821].
RCPT: The argument of the RECIPIENT command as defined in section
4.1.1.3 of [RFC2821].
VRFY: The argument of the VERIFY command as defined in section
4.1.1.6 of [RFC2821].
EXPN: The argument of the EXPAND command as defined in section
4.1.1.7 of [RFC2821].
RAWDATA: The complete mail data which is sent AFTER the DATA command
(see section 4.1.1.4 of [RFC2821]).
ALLHEADERS: The header of the email data including the empty line at
the end as defined in section 2.1 of [RFC2822].
SINGLEHEADERS: Some or all header fields of the email data, each to
be sent in a separate OCP message.
BODY: The body of the email data as defined in section 2.3 of
[RFC2822].
SECTIONS: Sections of the email body (for example MIME sections),
each to be sent in a separate OCP message.
The list of calid "am-part" atoms can be extended, especially to
represent commands that have been defined in extension to [RFC2821].
A callout server MUST ignore unknown "am-part" atoms.
Some commands defined in [RFC2821] MUST NOT be used as application
message parts for OCP. These include DATA, RSET and QUIT.
3.2 Application Profile Features
This document defines two SMTP profiles for OCP: sender and receiver
profiles. These two profiles are described below. Each profile has
a unique feature identifier:
profile ID: http://iana.org/opes/ocp/SMTP/sender
Stecher & Perz Expires April 16, 2006 [Page 7]
Internet-Draft SMTP adaptation with OPES October 2005
profile ID: http://iana.org/opes/ocp/SMTP/receiver
The sender profile is used by the OPES processor while or just before
he is sending a message to another peer using the SMTP protocol, the
receiver defines the opposite: the OPES processor is receiving or has
just received a message from another peer using the SMTP protocol.
The scope of a negotiated profile is the OCP connection (default) or
the service group specified via the SG parameter.
3.2.1 Profile Parts
If an SMTP OPES processor receives a valid RSET or QUIT command from
its SMTP peer it MUST terminate the corresponding OCP transaction.
The order of application message parts in OCP transaction MUST follow
the order of commands in the SMTP transaction as defined in section
4.1.4 of [RFC2821]. An OCP agent SHOULD terminate OCP transactions
with incorrect application message part orders.
Some application message parts are mutually exclusive within one OCP
transaction: RAWDATA and any message part of the following list are
mutually exclusive: ALLHEADERS, SINGLEHEADERS, BODY, SECTIONS.
ALLHEADERS and SINGLEHEADERS are mutually exclusive. BODY, SECTIONS
are mutually exclusive.
3.2.2 Profile Structure
An SMTP application profile feature extends semantics of the feature
type of OCP Core while adding the following named parameters to that
type:
o Adaptive-Parts (Section 3.2.3)
o Informative-Parts (Section 3.2.4)
o Header-List (Section 3.2.5)
The definition of the SMTP profile feature structure using PETDM
follows:
SMTP-Profile: extends Feature with {
[Adaptive-Parts: am-parts];
[Informative-Parts: am-parts];
[Header-List: headernames];
};
Figure 2
Stecher & Perz Expires April 16, 2006 [Page 8]
Internet-Draft SMTP adaptation with OPES October 2005
An SMTP profile structure can be used in feature lists of Negotiation
Offer (NO) messages and as anonymous parameter of an Negotiation
Response (NR) mesage. All profile parameters apply to any OCP
transaction within profile scope.
3.2.3 Adaptive-Parts
The list of application message parts negotiated as Adaptive-Parts
specify those parts that the OPES processor allows the callout server
to change and that the callout server expects to adapt while running
the specified callout service.
The OPES processor MUST NOT list application message parts as
Adaptive-Commands for which it is not willing or able to accept
changes or error responses from the callout server.
A callout server SHOULD only list those message parts in the
Adaptive-Parts parameter of the Negotiation Response (NR) message
that it may eventually change. Those message parts that the callout
server needs for information only SHOULD be moved to the Informative-
Parts list.
The callout server MUST NOT add a message part to the Adaptive-Parts
list of the Negotiation Response (NR) message if that part was not
contained in the Adaptive-Parts list of the Negotiation Offer (NO)
message. The OPES processor MUST close a connection if a message
part is returned in the Negotiation Response (NR) message that it
does not support.
The OPES processor is not bound to the mutual exclusive rule for
application message parts as defined in Section 3.2.1 and can list
any application message parts it supports. The callout server MUST
NOT list application message parts in the Negotiation Response (NR)
message that are mutually exclusive.
The Adaptive-Parts parameter can be omitted which then means an empty
list of am-part atoms.
3.2.4 Informative-Parts
In addition to the Adaptive-Parts the OCP agents can negotiate the
inclusion of auxiliary application message parts by using the
Informative-Parts parameter. Message parts of this list will not be
adaptable by the callout server but provide meta information that is
needed for the service.
All application message parts that the OPES processor has offered as
Adaptive-Parts can also be returned as Informative-Parts by the
Stecher & Perz Expires April 16, 2006 [Page 9]
Internet-Draft SMTP adaptation with OPES October 2005
callout server. The OPES processor SHOULD NOT list application
message parts as Informative-Parts again if the part was already
listed under Adaptive-Parts although this does not define a
semantical difference. A callout server MUST NOT list application
message parts as Informative-Parts if it already lists them as
Adaptive-Parts; the OPES processor MUST close the connection is such
a case.
The callout server MUST NOT add a message part to the Informative-
Parts list of the Negotiation Response (NR) message if that part was
neither contained in the Adaptive-Parts list nor in the Informative-
Parts list of the Negotiation Offer (NO) message. The OPES processor
MUST close a connection if a message part is returned in the
Negotiation Response (NR) message that it does not support.
The OPES processor is not bound to the mutual exclusive rule for
application message parts as defined in Section 3.2.1 and can list
any application message parts it supports. The callout server MUST
NOT list application message parts in the Negotiation Response (NR)
message that are mutually exclusive.
The Informative-Parts parameter can be omitted which then means an
empty list of am-part atoms.
3.2.5 Header-List
The callout server can use the Header-List parameter in an
Negotiation Response (NR) OCP message if it listed the SINGLEHEADERS
message part token in either Adaptive-Parts or Informative-Parts.
With this parameter it specifies which single headers it wants to
receive during the transactions. Before this the OPES processor has
indicated its ability to sent separated email headers by listing
SINGLEHEADERS in the Adaptive-Parts or Informative-Parts of the
Negotiation Offer (NO) message.
The following is the declaration of headernames (list of header
names) type using OCP Core Protocol Element Type Declaration Mnemonic
(PETDM); the type is used as a the value type for the Header-List
parameter:
headername: atom / "*";
headernames: extends list of headername;
Figure 3
[Note: May not be a good idea to allow "*" as a token as this is not
a bare atom; may be better to defined headername as atom and use the
wildcard in the quoted form "1:*"]
Stecher & Perz Expires April 16, 2006 [Page 10]
Internet-Draft SMTP adaptation with OPES October 2005
The value of headername is the name of a case insensitive email
header that should be transmitted to the callout server. The
wildcard "*" requests all available headers.
The requested header lines are transmitted in separated OCP messages,
using one message for each header. Requestes headers are only sent
if they exist in the original message.
The callout server MUST use a Header-List parameter if it listed
SINGLEHEADERS as an Informative- or Adaptive-Part and it MUST NOT use
the Header-List parameter if SINGLEHEADERS is not listed as such a
part.
3.2.6 Negotiation Examples
In this example the OPES processor offers recipient information and
the message data as Adaptive-Parts, which means that it is willing to
accept changes to these items. As auxiliary information, it can send
IP, HELO and MAIL command arguments. The callout server replies that
it only needs DATA, MAIL and RCPT and it might only change the DATA
part of the message.
Example 1: P=OPES processor, S=Callout Server
P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (RCPT,DATA)
Informative-Commands: (IP,HELO,MAIL)
})
SG: 25
;
S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (DATA)
Informative-Commands: (MAIL,RCPT)
}
SG: 25
;
Figure 4
In the second example the callout server accepts all items offered by
the OPES processor and requests some single headers from processed
messages.
Stecher & Perz Expires April 16, 2006 [Page 11]
Internet-Draft SMTP adaptation with OPES October 2005
Example 2: P=OPES processor, S=Callout Server
P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (MAIL,RCPT)
Informative-Commands: (IP,EHLO,SINGLEHEADERS)
})
SG: 25
;
S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (MAIL,RCPT)
Informative-Commands: (IP,EHLO,SINGLEHEADERS)
Header-List: (From,To,Reply-To,Received)
}
SG: 25
;
Figure 5
3.3 DUM and DUY Messages
The SMTP application profiles extend semantics of the DUM and DUY
messages defined in OCP Core by adding the following named
parameters:
o AM-Part (Section 3.3.1)
o Allow (Section 3.3.2)
o SMTP-Error (Section 3.3.3)
o Advice (Section 3.3.4)
o Add-Header (Section 3.3.5)
The following parameters are defined for DUM messages:
AM-Part: am-part
Allow: supported-params
SMTP-Error: atom
Advice: advice
Add-Header: atom
Figure 6
The following parameters are defined for DUY messages:
Stecher & Perz Expires April 16, 2006 [Page 12]
Internet-Draft SMTP adaptation with OPES October 2005
Advice: advice
Add-Header: atom
Figure 7
3.3.1 AM-Part Parameter
An OCP agent MUST send an AM-Part parameter with every DUM message
that is a part of an OCP transaction with an SMTP profile. The AM-
Part parameter value is a single am-part token. As implied by the
syntax, a DUM message can only contain data of a single application
message part.
Only the following message parts can be fragmented into any number of
DUM messages with the same AM-Part parameter: RAWDATA, ALLHEADERS,
BODY, SECTIONS. All other application message parts MUST each be
sent in a single DUM message.
The following example shows four DUM messages containing an abridged
SMTP response transaction. The RAWDATA part is fragmented and sent
within two DUM messages.
Stecher & Perz Expires April 16, 2006 [Page 13]
Internet-Draft SMTP adaptation with OPES October 2005
DUM 72 1 0
Kept: 0
AM-Part: MAIL
19:<steve@example.org>
;
DUM 72 1 19
Kept: 19
AM-Part: RCPT
18:<paul@example.com>
;
DUM 72 1 37
Kept: 37
AM-Part: RAWDATA
49:From: steve@example.org
To: sandra@example.com
;
DUM 72 1 86
Kept: 86
AM-Part: RAWDATA
41:Subject: Test
Hi, this is a test!
.
;
Figure 8
3.3.2 Allow Parameter
The Allow parameter is used by the OPES processor to indicate to the
callout server which optional parameters are supported by the OPES
processor when receiving DUM and DUY messages from the callout
server. This information can be important for the callout server.
For example: A callout server may prefer to have the OPES processor
to send an SMTP error in response to email message data in order to
reject the message but if the OPES processor is not able to do this
(or not willing to do this) the callout server may want to exchange
the email body content by an error message.
The following is the declaration of supported-params type (value type
of the Allow Parameter) using OCP Core Protocol Element Type
Stecher & Perz Expires April 16, 2006 [Page 14]
Internet-Draft SMTP adaptation with OPES October 2005
Declaration Mnemonic (PETDM):
supported-param: extends atom;
supported-params: extends list of supported-param;
Figure 9
The following "supported-param" atoms are defined by this document:
SMTP-Error: The OPES processor will accept an SMTP error response for
this application message part. The callout server MAY use the
SMTP-Error parameter as defined in Section 3.3.3.
Advice: The OPES processor will accept an advice from the callout
server what to do with this message. The callout server MAY use
the Advice parameter as defined in Section 3.3.4.
Add-Header: The OPES processor will accept an Add-Header directive.
The callout server MAY use the Add-Header parameter as defined in
Section 3.3.5.
The list of possible values for the "supported-param" atom can be
extended, especially by new parameter names of DUM and DUY messages
that will be defined in extensions to this document. Therefore the
callout server MUST ignore unknown atoms in the supported-params
list. The "supported-params" list MAY be empty.
The Allow parameter MUST NOT be sent by the callout server. The OPES
processor SHOULD add an Allow parameter to a DUM message if it is
able and willing to accept some of the additional parameters in DUM
and DUY messages that the callout server sends in response to the DUM
message of the OPES processor carrying the Allow parameter (i.e. DUM
messages with the same AM-Part and DUY messages referencing the data
of DUM messages). The Allow parameter MAY be omitted which is
semantically equal to an empty "supported-params" list. The Allow
parameter can be used for Adaptive-Parts as well as for Informative-
Parts.
3.3.3 SMTP-Error Parameter
The SMTP-Error parameter can be used by the callout server if it
wants the OPES processor to reply with an SMTP error to the SMTP
command that is encapsulated in the DUM message that the callout
server received.
By changing the payload of a DUM message the callout server adapts
the corresponding SMTP argument or email data. When adding a SMTP-
Error parameter the callout server SHOULD send an empty payload.
Stecher & Perz Expires April 16, 2006 [Page 15]
Internet-Draft SMTP adaptation with OPES October 2005
The OPES processor MUST NOT send SMTP-Error parameters with DUM
messages, the callout server SHOULD NOT send SMTP-Error parameters
with a DUM message if SMTP-Error was not in the list of "supported-
params" in the Allow-Parameter of the DUM message it responds to.
The SMTP-Error parameter MUST NOT be sent in a DUY message.
The value atom of the SMTP-Error parameter is a quoted-value with an
SMTP reply as defined in s ection 4.2 of [RFC2821] but without the
final CRLF characters at the end of the (last) reply line.
Example: P=OPES processor, S=Callout Server
P: DUM 72 1 0
Kept: 0
AM-Part: RCPT
Allow: (SMTP-Error)
18:<paul@example.com>
;
S: DUM 72 1 0
AM-Part: RCPT
SMTP-Error: "21:550 No such user here"
0:
;
Figure 10
3.3.4 Advice Parameter
Advice can be s.th. like "Discard" or "Quarantine". More definitions
are needed here.
To be done
3.3.5 Add-Header Parameter
The Add-Header parameter can be used by the callout server to have
the OPES processor to add an additional header line to the email
data. This can be an interesting side effect especially if the
callout server does not intend to modify the email content
application parts for other purposes.
The OPES processor MUST NOT send Add-Header parameters with DUM
messages, the callout server SHOULD NOT send Add-Header parameters
with DUM or DUY messages if Add-Header was not in the list of
"supported-params" in the Allow-Parameter of the DUM message it
Stecher & Perz Expires April 16, 2006 [Page 16]
Internet-Draft SMTP adaptation with OPES October 2005
responds to.
The value atom of the Add-Header parameter is a quoted-value with an
SMTP header lines as defined in s ection 2.2 of [RFC2822] but without
the terminating CRLF characters.
Example: P=OPES processor, S=Callout Server
P: DUM 72 1 0
Kept: 0
AM-Part: RCPT
Allow: (SMTP-Error,Add-Header)
18:<paul@example.com>
;
S: DUM 72 1 0
AM-Part: RCPT
Add-Header: "33:X-Original-User: paul@example.com"
21:<newuser@example.com>
;
Figure 11
3.4 SMTP Extension handling
Section 2.2 of [RFC2821] describes the Extension Model for SMTP,
"that permits the client and server to agree to utilize shared
functionality beyond the original SMTP requirements". Extensions can
add or replace SMTP keywords and may add additional parameters to the
SMTP MAIL and RCPT commands.
Further, extensions could create new meta information, that is not
part of the extension, but relevant for certain actions of a callout
server. Authentication within an SMTP session is an extension, but
the information wether the authentication process was successful or
not is in the domain of the MTA.
An MTA will use extensions during an SMTP session, regardless if a
callout server knows about them or not. But the callout server could
benefit from any data, that was exchanged using it.
Thus an OPES SMTP profile needs three features to deal with SMTP
extensions.
Stecher & Perz Expires April 16, 2006 [Page 17]
Internet-Draft SMTP adaptation with OPES October 2005
o The callout server must be able to tell the OPES processor, what
extensions it knows about (Section 3.4.1)
o The OPES processor needs a method how to submit the extension data
to the callout server (Section 3.4.2)
o Keywords for exchanging meta information must be defined
(Section 3.4.3)
3.4.1 Negotiating SMTP Extensions
The callout server will add a named parameter "Extensions" to the NR
message with a list of keywords of extensions it supports. It uses
the the EHLO response keyword value associated with the extension as
defined in the underlying RFC.
Example: Extensions are AUTH and SIZE
P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (RCPT,DATA)
Informative-Commands: (IP,HELO,MAIL)
})
SG: 25
;
S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (DATA)
Informative-Commands: (MAIL,RCPT)
Extensions: (AUTH,SIZE)
}
SG: 25
;
Figure 12
3.4.2 Transfer of extension information
The OPES processor can then send the data in the same way to the
callout server as it would do to SMTP receivers that indicated their
extension support with the keywords in the EHLO response.
These can be parameters with the MAIL and RCPT command arguments or
additional commands (which have also been negotiated in the am-parts
lists of the NO/NR messages.
Stecher & Perz Expires April 16, 2006 [Page 18]
Internet-Draft SMTP adaptation with OPES October 2005
Example 1: SIZE is listed as supported extension
P: DUM 72 1 0
AM-Part: MAIL
Allow: (SMTP-Error,Advice)
18:<paul@example.com> SIZE=256
;
Figure 13
Example 2: Fictive extension VIPEXT,
that defines the new keyword VIPNAME:
P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (RCPT,DATA)
Informative-Commands: (IP,HELO,MAIL,VIPNAME)
})
SG: 25
;
S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver"
Adaptive-Commands: (DATA)
Informative-Commands: (MAIL,RCPT,VIPNAME)
Extensions: (AUTH,SIZE,VIPEXT)
}
SG: 25
;
P: DUM 72 1 0
AM-Part: VIPNAME
Allow: (SMTP-Error,Advice)
10:"John Doe"
;
Figure 14
3.4.3 Extension meta information
Addtional information as a result of using extensions between two
SMTP peers can be transferred by putting the AM-OPT parameter in a
DUM message. Any data an OPES processor knows about can be send in
the described way. The callout server SHOULD provide a mechanism to
map the processors keywords to its internal names.
Stecher & Perz Expires April 16, 2006 [Page 19]
Internet-Draft SMTP adaptation with OPES October 2005
P: DUM 33 27
AM-Part: MAIL
AM-OPT: ({authtype cram-md5},{authen true})
53:sender@example.org SIZE=33423 AUTH=sender@example.org
;
Figure 15
3.5 Examples
To be done.
Stecher & Perz Expires April 16, 2006 [Page 20]
Internet-Draft SMTP adaptation with OPES October 2005
4. Tracing
[RFC3897] defines application-agnostic tracing facilities in OPES.
Compliance with this specification requires compliance with
[RFC3897].
4.1 Tracing Headers
When adapting SMTP, trace entries are supplied using header lines for
the message content. The following extension headers are defined to
carry trace entries. Their definitions are given using BNF notation;
the definition for "absoluteURI" is taken from [RFC2396].
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
Figure 16
An OPES System MUST add its trace entry to the OPES-System header.
Other OPES agents MUST use the OPES-Via header if they add their
tracing entries. All OPES agents MUST append their entries.
Informally, OPES-System is the only required OPES tracing header
while OPES-Via provides optional tracing details; both headers
reflect the order of trace entry additions.
An OPES System MUST NOT change OPES-System and OPES-VIA headers that
were previously added to the message header. OPES agents MUST
prepend OPES-System and OPES-VIA lines before all existing OPES-
System and OPES-VIA lines; they MUST NOT change the order of existing
lines or insert OPES-System and OPES-VIA lines in any other location.
If an OPES System is using both headers, it MUST add identical trace
entries except it MAY omit some or all trace-entry parameters from
the the OPES-Via header. Informally, the OPES System entries in the
OPES-Via header are used to delimit and group OPES-Via entries from
different OPES Systems without having a priory knowledge about OPES
System identifiers.
For example, here is an email message header after OPES adaptations
have been applied by two OPES processors, the first executing 10 OPES
services:
Stecher & Perz Expires April 16, 2006 [Page 21]
Internet-Draft SMTP adaptation with OPES October 2005
Received: from gateway.example.com ([192.0.2.138])
by mail.example.com with testserver;
Mon, 10 Oct 2005 05:37:19 +0200
Received: from mail2.example.org [192.0.2.99]
by gateway.example.com id 33W9WIMC;
Mon, 10 Oct 2005 05:35:55 +0200
OPES-System: http://mail.example.com/opes?id=33W9WIMC
OPES-System: http://gateway.example.com/opes?session=33W9WIMC
OPES-Via: http://gateway.example.com/opes?session=33W9WIMC,
http://www.opes-services-4u.com/cat/?sid=123,
http://www.opes-services-4u.com/cat/?sid=124,
http://www.opes-services-4u.com/cat/?sid=125 ; mode=A
Subject: Test
From: "Steve" <steve@example.org>
To: "Sandra" <sandra@example.com>
Figure 17
In the above example, the first OPES processor has not included its
trace entry or its trace entry was replaced by an OPES system trace
entry. Only 3 out of 10 services are traced. The remaining services
did not include their entries or their entries were removed by OPES
system or processor. The last traced service included a "mode"
parameter. The second OPES system has added its trace line before
the other header lines. Various identifiers in trace entries will
probably have no meaning to the recipient of the message, but may be
decoded by OPES System software.
OPES entities MAY place optional tracing entries in the message
content.
4.2 SMTP Trace Extension
An OPES processor MUST support the SMTP Service Extension for OPES
Trace and Bypass [to be done in external document; referenced from
here].
To request notitifications about actions taken by OPES intermediates
while a message is relayed to its recipients, the sender of the
message adds the parameter "opestrace" to the MAIL FROM SMTP command.
The requested information is sent as a separate message and is
generated by each OPES system in the chain. The message MUST contain
all message headers, including the trace headers. It MUST NOT
contain any parts of the body of the original message.
[Comment to discuss on email list: Note that DSN (RFC1891) has not
been chosen as a method for sending trace information back to the
Stecher & Perz Expires April 16, 2006 [Page 22]
Internet-Draft SMTP adaptation with OPES October 2005
sender as that would offer an attacker to also send the email content
body with potential malicious content to a faked sender address.
Another candidate to evaluate is Message Tracking (RFC3885); maybe
this can be used rather than defining yet another method.]
Stecher & Perz Expires April 16, 2006 [Page 23]
Internet-Draft SMTP adaptation with OPES October 2005
5. Bypass
An OPES processor MUST support the SMTP Service Extension for OPES
Trace and Bypass [to be done in external document; referenced from
here] which allows for OPES system bypass as defined in [RFC3897].
As SMTP does not include client requests an OPES bypass for SMTP is
triggered by asking the email message sender to initiate the bypass
on behalf of the recipient.
[Extension be done in external document; referenced from here. Draft
idea: New keyword to add to EHLO responses is "OPES", allows two new
extensions for the MAIL FROM command argument: (1) "opestrace" to
send trace information to the sender of the message and (2)
"opesbypass=( "*" | 1#bypass-entry )" for a list of OPES agent IDs to
bypass.]
The decision, if a bypass request is fulfilled must be taken by the
OPES processors in a chain and is their responsibility, because it is
possible, that executing a bypass request results in an undelivarable
message. If one OPES processor cannot fulfill the request, non-OPES
content is not available.
Especially for client centric OPES adaptations, other bypass methods
may be added that allow direct bypass requests from the recipients to
the OPES systems; that needs to be implemented outside of the normal
SMTP message flow (as SMTP traffic is not request/response) and is
therefore out of the scope of this document.
[Comment to discuss on email list: The whole bypass idea is an issue
for protocols that do not have client requests. Is a general out-of-
band solution required?]
Stecher & Perz Expires April 16, 2006 [Page 24]
Internet-Draft SMTP adaptation with OPES October 2005
6. IAB Considerations
OPES treatment of IETF Internet Architecture Board (IAB)
considerations [RFC3238] are documented in "OPES Treatment of IAB
Considerations" [RFC3914].
Section 5.3 of [RFC3914] talks about trace information in application
message requests and that "some application protocols may not have
explicit requests". This is fact for SMTP and therefore the MUST
requirement for a new SMTP extension has been added for OPES
processors for SMTP (Section 4.2); non-OPES SMTP servers are also
encouraged to implement that extension. If some SMTP relays on the
way of the email from or to the OPES processors do not support the
opestrace extension, the trace notifications may not be delivered.
This lack of trace notifications is not a problem that has been
introduced by OPES but a general SMTP issue. In such a case the
email sender can still contact the recipients and ask to provide
email headers of the message in question or similar messages in order
to get trace information of the OPES systems involved.
OPES bypass will also fail if some SMTP relays on the way of the
email do not supports the OPES SMTP extension. The sender will
detect whether an SMTP server supports this extension by parsing the
EHLO response. With information from the trace notification the
sender can try to contact the first OPES processor which MUST support
the bypass extension according to Section 5.
Stecher & Perz Expires April 16, 2006 [Page 25]
Internet-Draft SMTP adaptation with OPES October 2005
7. Security Considerations
Application-independent security considerations are documented in
application-agnostic OPES specifications [RFC3837].
Requests to bypass OPES agents (Section 5) are sent by the email
message sender on request of the recipient. A malicious sender could
try to activate the bypass of OPES security services; it is important
that implementations of the bypass feature include a policy that
defines which OPES agents can be bypassed and which cannot.
Stecher & Perz Expires April 16, 2006 [Page 26]
Internet-Draft SMTP adaptation with OPES October 2005
8. Compliance
Compliance with OPES mechanisms is defined in corresponding
application-agnostic specifications. SMTP profiles for these
mechanisms use corresponding compliance definitions from these
specifications, as if each profile was incorporated into the
application-agnostic specification it profiles.
Stecher & Perz Expires April 16, 2006 [Page 27]
Internet-Draft SMTP adaptation with OPES October 2005
Appendix A. Acknowledgments
Stecher & Perz Expires April 16, 2006 [Page 28]
Internet-Draft SMTP adaptation with OPES October 2005
Appendix B. Change Log
Internal WG revision control ID: $Id: smtp.xml,v 1.6 2005/10/13 15:
18:54 martin Exp $
2005/10/13
* Filled Header-List section.
* Added negotiation examples
* Filled Extension sections
2005/10/12
* Clemens' corrections and additions to Tracing and Bypass.
* Added hint to evaluate Message Tracking (RFC3885)
2005/10/11
* Removed DSN requirements, added new requirement for Trace/
Bypass SMTP extension.
2005/10/10
* Tracing section and additional to IAB considerations.
* Corrections provided by Clemens.
2005/09/29
* Added DUM/DUY sections with parameters.
* Started SMTP Extension Handling section.
* Updated RFC numbers in document map and References section.
2005/09/23
* Initial revision.
Stecher & Perz Expires April 16, 2006 [Page 29]
Internet-Draft SMTP adaptation with OPES October 2005
9. References
9.1 Normative References
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities
and End Points Communication", RFC 3897, September 2004.
[RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout
Protocol (OCP) Core", RFC 4037, March 2005.
9.2 Informative References
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services",
RFC 3238, January 2002.
[RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H.,
and R. Penno, "Open Pluggable Edge Services (OPES) Use
Cases and Deployment Scenarios", RFC 3752, April 2004.
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H.
Orman, "An Architecture for Open Pluggable Edge Services
(OPES)", RFC 3835, August 2004.
[RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A.
Terzis, "Requirements for Open Pluggable Edge Services
(OPES) Callout Protocols", RFC 3836, August 2004.
[RFC3837] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004.
[RFC3838] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
"Policy, Authorization, and Enforcement Requirements of
the Open Pluggable Edge Services (OPES)", RFC 3838,
August 2004.
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services
Stecher & Perz Expires April 16, 2006 [Page 30]
Internet-Draft SMTP adaptation with OPES October 2005
(OPES) Treatment of IAB Considerations", RFC 3914,
October 2004.
[I-D.ietf-opes-smtp-use-cases]
Barbir, A. and M. Stecher, "OPES SMTP Use Cases",
draft-ietf-opes-smtp-use-cases-03 (work in progress),
July 2005.
[I-D.ietf-opes-rules-p]
Rousskov, A., "P: Message Processing Language",
draft-ietf-opes-rules-p-02 (work in progress),
October 2003.
Authors' Addresses
Martin Stecher
CyberGuard Corporation
Webwasher Division
Vattmannstr. 3
33100 Paderborn
Germany
Email: martin.stecher@webwasher.com
URI: http://www.cyberguard.com/
Clemens Perz
All About It Systems S.A.
16, rue du Parc
L-6684 Mertert
Luxembourg
Email: cperz@allaboutit.lu
URI: http://www.allaboutit.lu/
Stecher & Perz Expires April 16, 2006 [Page 31]
Internet-Draft SMTP adaptation with OPES October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stecher & Perz Expires April 16, 2006 [Page 32]
