[draft-ietf-opes-smtp-use-cases-01]
"Abbie Barbir" <[email protected]> Thu, 13 Jan 2005 08:54:43 -0500
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <87AC5F88F03E6249AEA68D40BD3E00BE02C977B5@zcarhxm2.corp.nortel.com> |
All, attached is the first version of the draft-ietf-opes-smtp-use-cases-01. This is the time to get engaed and provide feedback on the draft. Let us do that for the next week and then we can update it and send it to the ietf list as a WG draft. Thanks Abbie Barbir Nortel Networks
draft-ietf-opes-smtp-use-cases-01.txt
(text/plain, 22.8 KB)
Network Working Group A. Barbir
Internet-Draft Nortel Networks
Expires: July 13, 2005 M. Stecher
CyberGuard Corporation
January 12, 2005
OPES SMTP Use Cases
draft-ietf-opes-smtp-use-cases-01
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.
This Internet-Draft will expire on July 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes OPES SMTP use cases and deployment scenarios.
Barbir & Stecher Expires July 13, 2005 [Page 1]
Internet-Draft OPES SMTP Use Cases January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Breif overview of SMTP Architecture . . . . . . . . . . . . . 5
4. OPES SMTP deployment scenarios . . . . . . . . . . . . . . . . 7
5. OPES SMTP based services . . . . . . . . . . . . . . . . . . . 8
6. Mail sender and recipients . . . . . . . . . . . . . . . . . . 10
7. Types of SMTP bases OPES services . . . . . . . . . . . . . . 11
7.1 Services that exclusively act on the mail message
content . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 Services that log or modify SMTP commands/replies . . . . 11
7.3 Services that trigger side effects on the mail delivery . 12
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Tracing considerations . . . . . . . . . . . . . . . . . . 13
8.2 Bypass considerations . . . . . . . . . . . . . . . . . . 13
8.3 Notification considerations . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
11.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Barbir & Stecher Expires July 13, 2005 [Page 2]
Internet-Draft OPES SMTP Use Cases January 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.
RFC 3752 describes use cases for Open Puggable Edge Services (OPES)
with a focus on HTTP messages. This work focus on OPES for SMTP use
cases, whereby, additional use caseses and enhancements to the types
of OPES services defined in RFC 3752 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).
The document is organized as follows: Section 2 discusses the various
types of SMTP based OPES services. Section 3 introduces SMTP OPES
deployment scenarios. Section 4 discusses failure cases and service
notification. Section 5 discusses security considerations.
Barbir & Stecher Expires July 13, 2005 [Page 3]
Internet-Draft OPES SMTP Use Cases January 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 [5]. 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 July 13, 2005 [Page 4]
Internet-Draft OPES SMTP Use Cases January 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:
o Mail User Agent (MUA): This is the client program in which the
user sends and receives mail.
o 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.
o Mail Submission Agent (MSA): This is the component of an MTA which
accepts new mail messages from an MUA, using SMTP.
o 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 July 13, 2005 [Page 5]
Internet-Draft OPES SMTP Use Cases January 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).
Barbir & Stecher Expires July 13, 2005 [Page 6]
Internet-Draft OPES SMTP Use Cases January 2005
4. OPES SMTP deployment scenarios
This section discusses OPES SMTP depolyment scenarios (eg. how it
relates to administrative domains, trust issues etc.)
Barbir & Stecher Expires July 13, 2005 [Page 7]
Internet-Draft OPES SMTP Use Cases January 2005
5. OPES SMTP based services
RFC 3752 provided on overview of OPES HTTP based services. From RFC
3752, in Figure 2, 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 2: Service Activation Points
In contrast to the four different service activation points that have
been defined above an OPES SMTP MTA only 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 3.
+----------------------------------------------+
| +-------------+-------------+ |
| | Service Application | |
| +---------------------------+ |
SMTP | Data Dispatcher | SMTP
dialog when +---------------------------+ dialog when
Receiving Mails | SMTP | Sending Mails
============1=> +---------------------------+ ==2==========>
| OPES Processor |
+----------------------------------------------+
Figure 3: 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
Barbir & Stecher Expires July 13, 2005 [Page 8]
Internet-Draft OPES SMTP Use Cases January 2005
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 July 13, 2005 [Page 9]
Internet-Draft OPES SMTP Use Cases January 2005
6. 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.
Barbir & Stecher Expires July 13, 2005 [Page 10]
Internet-Draft OPES SMTP Use Cases January 2005
7. Types of SMTP bases OPES services
There are three types of OPES services for SMTP.
7.1 Services that exclusively act on the mail message content
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.
7.2 Services that log or modify SMTP commands/replies
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 July 13, 2005 [Page 11]
Internet-Draft OPES SMTP Use Cases January 2005
"HELO" command.
7.3 Services that trigger side effects on the mail delivery
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 - Additional notification messages (e.g. virus alerts)
Barbir & Stecher Expires July 13, 2005 [Page 12]
Internet-Draft OPES SMTP Use Cases January 2005
8. IAB Considerations
This section TBD
8.1 Tracing considerations
TBD
8.2 Bypass considerations
TBD
8.3 Notification considerations
TBD
Barbir & Stecher Expires July 13, 2005 [Page 13]
Internet-Draft OPES SMTP Use Cases January 2005
9. Security Considerations
This section TBD
Barbir & Stecher Expires July 13, 2005 [Page 14]
Internet-Draft OPES SMTP Use Cases January 2005
10. IANA Considerations
This section TBD
Barbir & Stecher Expires July 13, 2005 [Page 15]
Internet-Draft OPES SMTP Use Cases January 2005
11. References
11.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] Barbir et. al, A., "Security Threats and Risks for OPES", RFC
3837, August 2004.
[4] Barbir et. al, A., "Security Threats and Risks for OPES", RFC
3752, April 2004.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
11.2 Informative References
[6] 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 3198,
November 2001.
[7] 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.
Authors' Addresses
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
EMail: [email protected]
Barbir & Stecher Expires July 13, 2005 [Page 16]
Internet-Draft OPES SMTP Use Cases January 2005
Martin Stecher
CyberGuard Corporation
Vattmannstr. 3
Paderborn, DE 33100
Germany
EMail: [email protected]
Barbir & Stecher Expires July 13, 2005 [Page 17]
Internet-Draft OPES SMTP Use Cases January 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 July 13, 2005 [Page 18]
Internet-Draft OPES SMTP Use Cases January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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 assignees.
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
Barbir & Stecher Expires July 13, 2005 [Page 19]
Internet-Draft OPES SMTP Use Cases January 2005
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Barbir & Stecher Expires July 13, 2005 [Page 20]