Network Working Group A. Barbir
Internet-Draft Nortel Networks
Expires: August 13, 2005 M. Stecher
CyberGuard Corporation
February 9, 2005
OPES SMTP Use Cases
draft-ietf-opes-smtp-use-cases-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes OPES SMTP use cases and deployment scenarios.
Barbir & Stecher Expires August 13, 2005 [Page 1]
Internet-Draft OPES SMTP Use Cases February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Breif overview of SMTP Architecture . . . . . . . . . . . . . 5
3.1 Operation Flow of an OPES SMTP System . . . . . . . . . . 6
3.1.1 OPES SMTP Example . . . . . . . . . . . . . . . . . . 7
4. OPES SMTP based services . . . . . . . . . . . . . . . . . . . 9
5. Mail sender and recipients . . . . . . . . . . . . . . . . . . 12
6. Examples of SMTP bases OPES services . . . . . . . . . . . . . 13
6.1 SMTP command modification . . . . . . . . . . . . . . . . 13
6.2 SMTP command satisfaction . . . . . . . . . . . . . . . . 13
6.3 OPES mail delivery side effects . . . . . . . . . . . . . 14
7. Mail List Tracker . . . . . . . . . . . . . . . . . . . . . . 15
8. Future Sections . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 OPES SMTP deployment scenarios . . . . . . . . . . . . . . 17
8.2 IAB Considerations . . . . . . . . . . . . . . . . . . . . 17
8.2.1 Tracing considerations . . . . . . . . . . . . . . . . 17
8.2.2 Bypass considerations . . . . . . . . . . . . . . . . 17
8.2.3 Notification considerations . . . . . . . . . . . . . 17
8.3 Security Considerations . . . . . . . . . . . . . . . . . 17
8.4 IANA Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Normative References . . . . . . . . . . . . . . . . . . . 18
9.2 Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Barbir & Stecher Expires August 13, 2005 [Page 2]
Internet-Draft OPES SMTP Use Cases February 2005
1. Introduction
The Open Pluggable Edge Services (OPES)[1] architecture enables
cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze and possibly
transform application-level messages exchanged between the data
provider and the data consumer. The OPES processor can distribute
the responsibility of service execution by communicating and
collaborating with one or more remote callout servers.
The execution of such services is governed by a set of rules
installed on OPES processor. The rule evaluation can trigger the
execution of service applications local to the OPES processor or on a
remote callout server.
HTTP [10] based use cases for Open Puggable Edge Services (OPES) are
described in [4]. This work focus on OPES for SMTP [8] use cases,
whereby, additional use cases and enhancements to the types of OPES
services defined in [4] are provided.
In SMTP the OPES processor may be any agent participate in SMTP
exchanges, including MSA, MTA, MDA, and MUA. This document focues on
use cases in which the OPES processor is a mail transfer agent (MTA).
SMTP is a store and forward protocol. Current email filtering
systems either operate at SMTP time or they operate on messages after
reception either on the MTA's queue or by being handed from the MTA
to a mail filter and back again.
This work focuses on SMTP based services that want to modify command
values and those that want to block commands by defining an error
reply that the MTA should send in response to the reply it received.
OPES MTA will be involved in SMTP command modification and command
satisfaction, analog to request modification and request satisfaction
from HTTP[10].
The document is organized as follows: TBD.
Barbir & Stecher Expires August 13, 2005 [Page 3]
Internet-Draft OPES SMTP Use Cases February 2005
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [7]. When used with
the normative meanings, these keywords will be all uppercase.
Occurrences of these words in lowercase comprise normal prose usage,
with no normative implications.
Barbir & Stecher Expires August 13, 2005 [Page 4]
Internet-Draft OPES SMTP Use Cases February 2005
3. Breif overview of SMTP Architecture
In RFC 282, the SMTP design is given in Figure 1. In the figure,
When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client |Commands/Replies| Server |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
Figure 1: SMTP Design
In some cases, the domain name(s) transferred to, or determined by,
an SMTP client will identify the final destination(s) of the mail
message. In other cases, the domain name determined will identify an
intermediate destination through which all mail messages are to be
relayed.
An SMTP server may be either the ultimate destination or an
intermediate "relay" or "gateway" (that is, it may transport the
message further using some protocol other than SMTP). SMTP commands
are generated by the SMTP client and sent to the SMTP server. SMTP
replies are sent from the SMTP server to the SMTP client in response
to the commands. SMTP message transfer can occur in a single
connection between the original SMTP-sender and the final
SMTP-recipient, or can occur in a series of hops through intermediary
systems. SMTP clients and servesr exchange commands and replies and
eventually the mail message body.
The most important logical elements of the Internet mail system are:
1. Mail User Agent (MUA): This is the client program in which the
user sends and receives mail.
2. Mail Transfer Agent (MTA): A program which enables email
transfers from one machine to another. MTAs do not deliver mail
themselves. MTAs call a Mail Delivery Agent to physically
transport the messages.
3. Mail Submission Agent (MSA): This is the component of an MTA
which accepts new mail messages from an MUA, using SMTP.
4. Mail Delivery Agent (MDA): A program used by the MTA to deliver
messages into a user's mailbox or to transport mail to another
Barbir & Stecher Expires August 13, 2005 [Page 5]
Internet-Draft OPES SMTP Use Cases February 2005
MTA.
In this work the OPES processor may be any agent that is
participating in SMTP exchanges, including MSA, MTA, MDA, and MUA.
However, this document focues on use cases in which the OPES
processor is a mail transfer agent (MTA).
3.1 Operation Flow of an OPES SMTP System
In this work an MTA is the OPES processor device that sits in the
data stream of the SMTP protocol. The OPES processor gets enhanced
by an OCP client that allows it to vector out data to the callout
server. The filtering functionality is on the callout server.
A client (a mail user) starts with an email client program (MUA).
The user sends email to an outgoing email server. In the email
server there is an MSA (mail submission agent) that is waiting to
receive email from the user. The MSA uses an MTA (mail transfer
agent) within the same server to forward the user email to other
domains.(Communication between the MUA and MSA may be via SMTP or
something else such as MAPI).
The MTA in the user email server may directly contact the email
server of the recipient or may use other intermediate email gateways.
The sending email server, the destination email server and all
intermediate gateways MTAs communicate using SMTP.
In the destination email server a mail delivery agent (MDA) may
deliver the email to the recipient's mailbox. The email client
program of the recipient might use a different protocol (such as POP3
or IMAP) to access the mailbox and retrieve/read the messages.
Barbir & Stecher Expires August 13, 2005 [Page 6]
Internet-Draft OPES SMTP Use Cases February 2005
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T g-way T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
| | |
| OCP | OCP | OCP
| | |
+----------+ +-----------+ +----------+
| callout | | callout | | callout |
| server | | server | | server |
+----------+ +-----------+ +----------+
Figure 2: OPES SMTP Flow
From Figure 2, the MTA (the OPES processor) is either receiving or
sending an email (or both) within an email server/gateway. An OPES
processor might be the sender's SMTP server, the destination SMTP
server or any intermediate SMTP gateway. (Which building block
belongs to which authoritative domain is an important question but
different from deployment to deployment).
3.1.1 OPES SMTP Example
A typical (minimum) SMTP dialog between two OPES SMTP processors
(MTA) will consist of the following (S: means sender, R: means
recipient):
o R: 220 mail.example.com Sample ESMTP MAIL Service, Version:
5.0.2195.6713 ready at Thu, 20 Jan 2005 11:24:40 +0100
o S: HELO ThatsMe
o R: 250 mail.example.com Hello [192.168.0.138]
o S: MAIL FROM: steve@sender.com
o R: 250 2.1.0 steve@sender.com....Sender OK
o S: RCPT TO: paul@example.com
o R: 250 2.1.5 paul@example.com
o S: DATA
o R: 354 Start mail input; end with "CRLF"."CRLF"
o S: From: steve@sender.com
o S: To: sandra@example.com
o S: Subject: Test
o S:
o S: Hi, this is a test!
o S: .
o R: 250 2.6.0 "MAILYwekrt0Goqm4bVS00005b1f@mail.example.com" Queued
mail for delivery
o S: QUIT
o R: 221 2.0.0 mail.example.com Service closing transmission channel
Barbir & Stecher Expires August 13, 2005 [Page 7]
Internet-Draft OPES SMTP Use Cases February 2005
The sender is generating commands and the recipient is generating
replies. All Replies start with a status code and then some text.
At minimum 4 commands are needed to send an email. All commands and
replies to send a single email message together form "the dialog".
The mail message body is the data sent after the "DATA" command. To
an OPES processor it can be seen as command modification.
If a callout service wants to adapt the email message body, it is
mainly interested in this part of the dialog:
o From: steve@sender.com
o To: sandra@example.com
o Subject: Test
o Hi, this is a test!
The callout service may need to examine values of previous commands
of the same dialog. For example, callout service needs to examine
the value of the RCPT command (it is "paul@example.com") which is
different from the "sandra@example.com" that the email client
displays in the visible "To" field. That might be an important fact
for some filters such as Spam Filters.
Barbir & Stecher Expires August 13, 2005 [Page 8]
Internet-Draft OPES SMTP Use Cases February 2005
4. OPES SMTP based services
RFC 3752 [4] provided on overview of OPES HTTP based services. From
RFC 3752, in Figure 3, four service activation points for an OPES
processor are depicted. The data dispatcher examines OPES rules,
enforces policies, and invokes service applications (if applicable)
at each service activation point.
+------------------------------------------------+
| +-------------+-------------+ |
| | Service Application | |
| +---------------------------+ |
Responses | Data Dispatcher | Responses
<============4== +---------------------------+ <=3===========
Requests | HTTP | Requests
=============1=> +---------------------------+ ==2==========>
| OPES Processor |
+------------------------------------------------+
Figure 3: Service Activation Points
For SMTP OPES based services. There are four theoretical activation
points:
1. Receiving email: Perform an SMTP dialog with the peer MTA,
receiving email from it, usually storing the emails in a queue
and maybe sending them on later.
2. Stored email in queue: Operate on an email that has been received
earlier. At this stage there is no current SMTP dialog with the
peer.
3. Sending email: Perform an SMTP dialog with the peer MTA by
sending email to it.
4. Proxy (receive and forward): Having two SMTP dialogs at the same
time (mostly forwarding commands and replies).
In addition an OPES MTA can have the following modes of operations:
A: SMTP command modification: Here, SMTP commands are sent to the
callout server to be modified.
B: SMTP command satisfaction: Here, the callout server responds
back with a SMTP reply (usually an error message).
C: SMTP reply modification: The SMTP reply is modified by the
callout server
D: Email message body modification
Activation point 2 involves operating on stored emails. It only
Barbir & Stecher Expires August 13, 2005 [Page 9]
Internet-Draft OPES SMTP Use Cases February 2005
operates on the message body as there is no SMTP dialog going on.
Certainly an implementation can use an OCP client and pretend that
there is an SMTP dialog in order to get a callout server to work on a
stored email. This has more to do with a MIME profile for OCP rather
than with an SMTP profile. Hence, the more natural profile for this
option is an OCP/MIME as opposed to OCP/SMTP profile.
Some discussions on the mailing list did not see a use case for this
activation point. However, most use cases listed so far do either
work at activation points 1 or 3. There might even be specific
callout services that make much more sense when sending the email
(for example: add footer to the email that contains a current time
stamp, when a condition is satisfied, such as a stock price etc.).
Or there may be a corporate email gateway that uses SMTP outbound and
wants to do filtering there but emails are not delivered to that
device via SMTP but some other mail protocol, so that there is no
activation point 1 in the authoritative domain.Activation point 4
involves a proxy like functionality of the MTA. A sender MTA does a
dialog with the proxy and the proxy is doing a dialog with another
MTA at the same time. Forwarding the RCPT command to the next MTA
and sending back the response. This scenario involves response
modification, for example, if the next MTA returns an error (such as
address unknown). The response could be "modified", if the proxy
selects another address and tries that one again in a RCPT command to
the next proxy. On success it sends back the positive response. The
callout server is determining the other address, maybe even other
next MTA. So it tells the proxy MTA to send another command to the
same or a different next MTA.
Editor Note: Current discussions on the list have not nailed down the
relationship of this activation point to current accepted SMTP
deployments. As such, the current version of the work will not
support it.
Regarding modes of operation, option C SMTP reply modification
applies to scenarios that involve logging services and can be used in
activation point 4, when commands and replies are proxied. Option D,
can be seen as command modification and is basically covered in
option A.
In this work, an OPES SMTP MTA acts on two activation points within
the MTA: Receiving and sending mail messages using SMTP. When
receiving a mail message, the MTA is acting as a SMTP server and when
sending a message it is acting as a SMTP client. This situation is
depiiected in Figure 4.
Barbir & Stecher Expires August 13, 2005 [Page 10]
Internet-Draft OPES SMTP Use Cases February 2005
+----------------------------------------------+
| +-------------+-------------+ |
| | Service Application | |
| +---------------------------+ |
SMTP | Data Dispatcher | SMTP
dialog when +---------------------------+ dialog when
Receiving Mails | SMTP | Sending Mails
============1=> +---------------------------+ ==2==========>
| OPES Processor |
+----------------------------------------------+
Figure 4: OPES SMTP Service Activation Points
While we could see the SMTP commands and replies analogously to the
HTTP requests and responses and by that getting to the same four
service activation points as in RFC 3752, it is important to handle
the command and reply dialog that is necessary to transfer a mail
message as a unit within the OPES context and not as individual and
independend messages as HTTP messages are. One reason for this is
that a service that runs on mail message content (i.e. the data
transferred with a DATA command) may need to know the content of the
previous MAIL FROM and RCPT TO commands of the same dialog in order
to know the "real" recipients of the mail message and not to rely on
the information given in the mail message header (which is part of
the data in the DATA command).
Still there are usecases in which callout services want to adapt
single commands of the SMTP dialog so that we cannot restrict
OPES/SMTP to only handle the mail message content with some meta
information from the SMTP dialog and reduce the possible callout
protocol to a single request to the callout server and a single
response; OPES for SMTP means to find a callout protocol equation to
the SMTP dialog happening between SMTP client and server.
Barbir & Stecher Expires August 13, 2005 [Page 11]
Internet-Draft OPES SMTP Use Cases February 2005
5. Mail sender and recipients
OPES/HTTP only deals with a single client and single server between
which the HTTP message is exchanged. (In addition an OPES processor
may include a concept for OPES message caching for which it needs to
decide whether a response of the callout server for a special HTTP
message remains unchanged if the request is repeated for a different
user and/or a different time). In SMTP a mail message is originating
from a single sender but may be sent to multiple recipients. Message
adaptation of a mail message may produce different results for the
different recipients. OPES/SMTP has to anticipate this.
The commands and replies in the SMTP dialog are always just between
each hop. In SMTP a mail message is originating from a single sender
but may be sent to multiple recipients. Message adaptation of a mail
message may produce different results for the different recipients.
While we see the need to involve the callout server on a per-command
basis, the commands and replies of one dialog belong together and
services may have the need to refer to earlier commands of the same
dialog.
Barbir & Stecher Expires August 13, 2005 [Page 12]
Internet-Draft OPES SMTP Use Cases February 2005
6. Examples of SMTP bases OPES services
This section provides some examples of OPES based services.
6.1 SMTP command modification
Use cases of this type are very similar to the services listed in
section 2.2 of RFC 3752 "Services performed on (HTTP) responses".
They may or may not modify the an SMTP message content:
o Content adaptation: Changing the mail message content within a
callout server to transcode it into a format appropriate for the
device that will receive the mail message
o Language translation of the content
o
o Logging, monitoring and accounting as the known examples for
services that do not intend to modify the message content
In addition there are more services acting on message content that
may even be more typical for SMTP while they could also be used for
HTTP:
o Virus scanning (replacing infected attachments of a mail message)
o Applying other security policies such as stripping of unwanted
MIME sections (forbidden attachment types)
o Spam filtering (mark a message if it supposed to contain spam)
o Encrypt mail message
o Verify mail signatures
o Verify message format (e.g. correct illegal MIME formats)
o Convert attachments into HTTP links (stripping large attachments
from emails, putting them on a web server and replace the
attachment with a URL to that server.
The example of the Spam filter is typical for a service which may
need data of other SMTP commands of the mail dialog in order to
provide an accurate rating.
6.2 SMTP command satisfaction
o Logging or validating "MAIL FROM": These may services which intend
or not intend to change the command or reply to this command. A
callout service may just log the information (not change
something), it may change the command by rewriting the mail sender
or it may change/determine the reply by denying a sender address
that could not be validated.
o Similar use cases acting on other single commands such as "RCPT
TO"
o Services may also need to get access to data of previous SMTP
commands, for example a service acting on "RCPT TO" may want to
know about the data that has been sent with the "MAIL FROM" and/or
Barbir & Stecher Expires August 13, 2005 [Page 13]
Internet-Draft OPES SMTP Use Cases February 2005
"HELO" command.
6.3 OPES mail delivery side effects
These may be side effects on the current SMTP dialog or on other
operations that the MTA performes on the mail message or it may split
the mail message into multiple messages or create additional messages
o Reject a message whose content violates a possible trigger
condition
o Delay a message, put it in a special queue for further processing
or reroute it to other recipients.
o Out of office replies
o Generate additional notification messages (e.g. virus alerts)
There is a number of side effects that a callout service may want to
trigger that influences the next steps within the email server or
gateway. Not all of that is a pure MTA role but typical things that
an email intermediary can do, for example:
1. Delay the email, don't forward immediately
2. Send an additional notification
3. Exchange the recipients
4. Don't forward but store email in quarantine
5. Use another next hop MTA (routing)
None of the above can be done by only modifying the email message
body. For example, sending an additional notification can be
achieved by generating another OCP response. Similarly, exchanging
recipients can be achieved by exchanging the RCPT command value (but
that command has been handled already before; how to get back?).
Editor Note: Do we need some negotiations between OPES processor and
callout servers about which side effects are allowed/supported and a
way to trigger them through special parameters in the OCP response.
Barbir & Stecher Expires August 13, 2005 [Page 14]
Internet-Draft OPES SMTP Use Cases February 2005
7. Mail List Tracker
This section is a place holder for some important discussion points
from the list that we need to decide on as the draft progress.
1. There are some situations in which an SMTP server may wish to
call forward to another server in order to validate a user's
address. This call-forward function could perhaps be
implemented in the OPES service application.
2. OPES is supposed to enable new services. The call-forward
wouldn't have been a hack if it had been done as part of an OPES
service, using the same architectural model that we used for
HTTP.
3. Every request satisfaction could also be implemented as a
response modification by ignoring the original response.
4. The expectation of deliver or the reasons for rejection is
naturally expected by the user. This is legal precedence for
this covered by provisions in US ECPA governing "user
expectations."
5. Look at legal conflict with US EPCA delivery expectations of
accepted data. Once the message is accepted by SMTP, the
responsibility moves to the operator on how it is he/she wishes
to handle/process the stored message.
6. Even with a PROXY concept there is still a need to follow the
current SMTP design expectations. If the OPES device is
implemented at the DATA stage, this falls in line with the
"instant notification" concept satisfying the user expectation.
If the OPES device accepts the message, then it is now the SMTP
operator responsibility (ISP) on what he will do with the
message.
7. If an OPES service is applied POST SMTP, then how is this
reflected back into the SMTP process? Is it as a bounce? Any
errant drop of mail will be attributed to the system operator
(sysop) post filtering policy.
8. Responce Modification: Need to discuss how to cover it with
activation points. Take a closer look at Proxied activation
point.
9. Above is dependent on the OPES device and its required input
process parameters. In some cases only transport information is
required: (e.g. result = OPES_RCPT (IP, HELO/ECHO, MAILFROM,
RCPTTO)) or (result = OPES_DATA(IP,HELO/ECHO,MAILFROM, RCPTTO,
PAYLOAD)).
10. Is it worthwhile noting a particular kind of non-symmetry that
is common today. Most people run SMTP on their local machine in
order to send messages, but they do not run SMTP to receive
messages; that is done by a remote server, and the user runs a
different protocol (a Mail Retrieval Client?) to fetch the mail.
That means that and OPES server that is closest to the user will
Barbir & Stecher Expires August 13, 2005 [Page 15]
Internet-Draft OPES SMTP Use Cases February 2005
probably be acting as an SMTP relay, while that same server will
be an SMTP endpoint for messages destined to that user.
11. OPES MTA cascade on the mail path, as such the end to end
finishes at the last MTA.
12. All use cases deal with SMTP commands. Need to document exactly
what we mean by the value of a DATA command.
13. Revisit how queues are maintained (callout server versus OPES
MTA)
14. Timeout Prevention: Use of: 1yz Positive Preliminary reply
15. Do we need for the OPES specifications to provide an 2821 Update
provision to make timeouts work.
Barbir & Stecher Expires August 13, 2005 [Page 16]
Internet-Draft OPES SMTP Use Cases February 2005
8. Future Sections
8.1 OPES SMTP deployment scenarios
This section discusses OPES SMTP depolyment scenarios (eg. how it
relates to administrative domains, trust issues etc.)
8.2 IAB Considerations
This section TBD
8.2.1 Tracing considerations
TBD
8.2.2 Bypass considerations
TBD
8.2.3 Notification considerations
TBD
8.3 Security Considerations
This section TBD
8.4 IANA Considerations
This section TBD
Barbir & Stecher Expires August 13, 2005 [Page 17]
Internet-Draft OPES SMTP Use Cases February 2005
9. References
9.1 Normative References
[1] A. Barbir et. al, "An Architecture for Open Pluggable Edge
Services (OPES)", RFC 3835, August 2004.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[3] A. Barbir et. al, "Security Threats and Risks for OPES",
RFC 3837, August 2004.
[4] A. Barbir et. al, "Open Pluggable Edge Services (OPES) Use Cases
and Deployment Scenarios", RFC 3752, April 2004.
[5] A. Rousskov et. al, "HTTP adaptation with OPES",
draft-ietf-opes-http-02 , January 2004.
[6] Rousskov , A., "OPES Callout Protocol Core",
draft-ietf-opes-ocp-core-05 , May 2004.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
9.2 Informative References
[8] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management",
RFC 2821, November 2001.
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 3198, April
2001.
[10] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
Barbir & Stecher Expires August 13, 2005 [Page 18]
Internet-Draft OPES SMTP Use Cases February 2005
Authors' Addresses
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
Email: abbieb@nortelnetworks.com
Martin Stecher
CyberGuard Corporation
Vattmannstr. 3
Paderborn, DE 33100
Germany
Email: martin.stecher@webwasher.com
Barbir & Stecher Expires August 13, 2005 [Page 19]
Internet-Draft OPES SMTP Use Cases February 2005
Appendix A. Acknowledgements
Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel),
M. Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas
(Nokia)
Barbir & Stecher Expires August 13, 2005 [Page 20]
Internet-Draft OPES SMTP Use Cases February 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.
Barbir & Stecher Expires August 13, 2005 [Page 21]
