doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4902.txt b/doc/rfc/rfc4902.txt
new file mode 100644
index 0000000..8e66845
--- /dev/null
+++ b/doc/rfc/rfc4902.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         M. Stecher
+Request for Comments: 4902                              Secure Computing
+Category: Informational                                         May 2007
+
+
+                   Integrity, Privacy, and Security
+            in Open Pluggable Edge Services (OPES) for SMTP
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   The Open Pluggable Edge Services (OPES) framework is application
+   agnostic.  Application-specific adaptations extend that framework.
+   Previous work has focused on HTTP and work for SMTP is in progress.
+   These protocols differ fundamentally in the way data flows, and it
+   turns out that existing OPES requirements and IAB considerations for
+   OPES need to be reviewed with regards to how well they fit for SMTP
+   adaptation.  This document analyzes aspects about the integrity of
+   SMTP and mail message adaptation by OPES systems and about privacy
+   and security issues when the OPES framework is adapted to SMTP.  It
+   also lists requirements that must be considered when creating the
+   "SMTP adaptation with OPES" document.
+
+   The intent of this document is to capture this information before the
+   current OPES working group shuts down.  This is to provide input for
+   subsequent working groups or individual contributors that may pick up
+   the OPES/SMTP work at a later date.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stecher                      Informational                      [Page 1]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Differences between Unidirectional and
+           Bidirectional Application Protocols ........................3
+      1.2. Non-Standardized SMTP Adaptations at SMTP Gateways .........3
+      1.3. Non-OPES Issues of SMTP ....................................4
+      1.4. Opportunities of OPES/SMTP to Address Some Issues ..........4
+      1.5. Limitations of OPES in Regards to Fixing SMTP Issues .......4
+   2. Terminology .....................................................5
+   3. Integrity, Privacy, and Security Considerations .................5
+      3.1. Tracing Information in OPES/SMTP ...........................5
+      3.2. Bypass in OPES/SMTP ........................................6
+      3.3. Compatibility with Cryptographic Protection Mechanisms .....7
+   4. Protocol Requirements for OPES/SMTP .............................8
+   5. IAB Considerations for OPES/SMTP ................................9
+      5.1. IAB Consideration (2.1) One-Party Consent ..................9
+      5.2. IAB Consideration (2.2) IP-Layer Communications ............9
+      5.3. IAB Consideration (3.1) Notification .......................9
+      5.4. IAB Consideration (3.2) Notification ......................10
+      5.5. IAB Consideration (3.3) Non-Blocking ......................10
+      5.6. IAB Consideration Application Layer Addresses (4.x) .......10
+      5.7. IAB Consideration (5.1) Privacy ...........................10
+      5.8. IAB Consideration Encryption ..............................11
+   6. Security Considerations ........................................11
+   7. References .....................................................11
+      7.1. Normative References ......................................11
+      7.2. Informative References ....................................11
+   Appendix A. Acknowledgements ......................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stecher                      Informational                      [Page 2]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+1.  Introduction
+
+   Because OPES is a protocol that is built over application layer
+   transports, its security may depend on the specifics of the
+   transport.  OPES designs are guided by the IAB considerations for
+   OPES document [2], and those considerations are revisited here in the
+   context of the SMTP protocol.
+
+   Section 3 of the OPES SMTP use cases document [6] maps some email and
+   SMTP elements to OPES names that are used in this document.
+
+1.1.  Differences between Unidirectional and Bidirectional Application
+      Protocols
+
+   The IAB listed considerations for Open Pluggable Edge Services (OPES)
+   in [2] and OPES treatment of those considerations has been discussed
+   in [3].  Both documents make use of HTTP as an example for the
+   underlying protocol in OPES flows, and focus on web protocols that
+   have requests and responses in the classic form (client sends a
+   request to a server that replies with a response of the same protocol
+   within a single protocol transaction).
+
+   RFC 3914 [3] already indicates that other protocols may not fit in
+   this context, for example in Section 5.3, "Moreover, some application
+   protocols may not have explicit responses...".
+
+   When using SMTP there are still client and server applications, and
+   requests and responses handled within SMTP, but email messages are
+   sent by the data provider to the recipients (data consumers) without
+   a previous request.  At that abstraction layer, email delivery via
+   SMTP is a unidirectional process and different from the previously
+   handled web protocols such as HTTP.  For example, bypass has been
+   defined for OPES, so far, by the data consumer requesting an OPES
+   bypass by adding information to the application protocol request; the
+   OPES system can then react on the bypass request in both the
+   application request and response.  For SMTP, the data consumer (email
+   recipient) cannot request in-band that the OPES bypass handling of
+   his/her messages.
+
+   The IAB considerations need to be revisited and special requirements
+   may be needed for OPES handling of SMTP.
+
+1.2.  Non-Standardized SMTP Adaptations at SMTP Gateways
+
+   A large number of email filters are deployed at SMTP gateways today.
+   In fact, all use cases listed in "OPES SMTP Use Cases" [6] are
+   already deployed, often in non-standardized ways.  This opens a
+   number of integrity, privacy, and security concerns that are not
+
+
+
+Stecher                      Informational                      [Page 3]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   addressed, and SMTP itself does not provide effective measures to
+   detect and defend against compromised implementations.
+
+   OPES will most likely not be able to solve these issues completely,
+   but at least should be able to improve the situation to some extent.
+
+1.3.  Non-OPES Issues of SMTP
+
+   The SMTP specifications [4] require that NDRs (Non-Delivery Reports)
+   be sent to the originator of an undeliverable mail that has been
+   accepted by an SMTP server.  But it has become common practice for
+   some sorts of mail (spam, worms) to be silently dropped without
+   sending an NDR, a violation of the MUST statement of SMTP (see
+   Section 3.7 of [4]).  While the user of a web protocol notices if a
+   resource cannot be fetched, neither the email sender nor email
+   recipient may notice that an email was not delivered.  These kind of
+   issues already exist and are not introduced by OPES.
+
+1.4.  Opportunities of OPES/SMTP to Address Some Issues
+
+   Adding SMTP adaptations with OPES allows us to define a standardized
+   way for SMTP gateway filtering, to offload filtering services to
+   callout servers and address a number of the integrity, privacy, and
+   security issues.  OPES offers methods to add OPES tracing information
+   and to request a bypass of filtering, and by that can make email
+   gateway filtering a more reliable and standardized function.  But
+   OPES won't make email delivery via SMTP a reliable communication.
+
+1.5.  Limitations of OPES in Regards to Fixing SMTP Issues
+
+   The biggest concerns when adding OPES services to a network flow are
+   that compromised, misconfigured, or faulty OPES systems may change
+   messages in a way that the consumer can no longer read them or that
+   messages are no longer delivered at all.
+
+   Defining a standard way to mark mails that have been handled by OPES
+   systems is fairly simple and does not require new techniques by SMTP
+   gateways; they already today MUST leave tracing information by adding
+   "Received" headers to mails.  Therefore, recipients receiving broken
+   mail have a fair chance of finding the compromised OPES system by
+   using the trace information.  There is still no guarantee, as the
+   email may have been broken in a way that makes even the tracing
+   information unreadable.  But the chance will be even better than with
+   other protocols such as HTTP, because most email clients allow the
+   user to display mail headers, while many browsers have no mechanism
+   to show the HTTP headers that might include tracing info.
+
+
+
+
+
+Stecher                      Informational                      [Page 4]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   Email that cannot be delivered, because a compromised OPES system
+   prevented the delivery of legitimate mail, MUST result in a an NDR to
+   be sent to the originator of the mail according to the SMTP
+   specifications [4].  OPES should not be forced to fix the issue that
+   NDRs are not reliable over SMTP.
+
+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 [1].  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.
+
+3.  Integrity, Privacy, and Security Considerations
+
+3.1.  Tracing Information in OPES/SMTP
+
+   Tracing OPES operations is an important requirement for OPES systems.
+   Tracing information added to email should follow a similar syntax and
+   structure to that defined for OPES/HTTP in HTTP Adaptation with Open
+   Pluggable Edge Services [5], and with the same guidelines as the SMTP
+   specifications [4] defined for the "Received" headers.  (We do not
+   specify here whether "Received" headers would be used to carry the
+   OPES information, or new trace headers should be defined, such as
+   OPES-System and OPES-Via.)
+
+   OPES/SMTP specifications defining tracing requirements MUST be
+   compliant with the general OPES tracing requirements defined in OPES
+   Entities & End Points Communication [12], but MAY further restrict
+   those.  For example, they might require the following: that the OPES
+   processor must add tracing information for the OPES system before
+   calling the first callout server; that it has to augment the tracing
+   information with additional data if necessary after the message
+   returns from each service it is calling; and that it must ensure that
+   the tracing information has not been deleted by an OPES service
+   before it forwards the SMTP message.
+
+   Trace information can then be seen by mail recipients when the mail
+   message reaches the recipient.
+
+   Mail that cannot be delivered or that is blocked by the OPES service
+   will either be rejected or cannot be delivered after it has been
+   accepted by an SMTP server.  In the latter case, SMTP specifications
+   [4] require that an NDR MUST be sent to the originator; OPES further
+   requires that an NDR generated due to OPES processing MUST also
+   contain information about the OPES system so that the sender gets
+
+
+
+Stecher                      Informational                      [Page 5]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   informed.  If an email is rejected at the SMTP protocol level due to
+   OPES processing, an OPES system MUST also include trace data in the
+   SMTP response so that the originator can find out why and where the
+   mail was rejected.
+
+3.2.  Bypass in OPES/SMTP
+
+   If a mail message was rejected or could not be delivered (and an NDR
+   was sent), the originator of the message may want to bypass the OPES
+   system that blocked the message.
+
+   If the recipient of a message receives a mail with OPES trace
+   information, he may want to receive a non-OPES version of the
+   message.  Although there is no direct in-band request from the
+   recipient back to the OPES system, the recipient can contact the
+   sender and ask her to send the message again and to add a bypass
+   request for the OPES system.  Not all OPES systems will be allowed to
+   fulfill a bypass request according to their policy.  For example,
+   malware scanners should not be bypassed.  But other OPES services are
+   good candidates for bypass requests, such as language translation of
+   the email message.  Translation could be bypassed after the recipient
+   has noticed that the translated result does not meet his/her
+   expectations and that the original message would be preferred.
+
+   An OPES system MAY also define out-of-band methods to request a
+   bypass, for example, a web interface or an email message sent to the
+   server that results in the creation of a white list entry for the
+   sender/recipient pair.  Examples for these out-of-band methods are
+   email systems that keep a copy of the original email in a quarantine
+   queue and only send the recipient a block notification, plus either a
+   direct link or a digest notification, with the ability to retrieve
+   the original message from quarantine.  These out-of-band methods are
+   typically offered by spam filters today.
+
+   OPES MUST implement methods to request a bypass, but there cannot be
+   a guarantee that the bypass request will be approved.  The security
+   needs of the receiver or the receiver's network may demand that
+   certain filters must not be bypassed (such as virus scanners).  In
+   general, the receiver should be able to configure a client centric
+   OPES system, i.e. the receiver should be able to indicate if he/she
+   wants to receive a non-OPES version if it is available.
+
+   Bypass requests could be added to the mail message or within the SMTP
+   dialog.  Bypass request data added to the mail message cannot bypass
+   OPES services that operate on other SMTP dialog commands, which are
+   sent before the mail message has been received (such as RCPT
+   commands).
+
+
+
+
+Stecher                      Informational                      [Page 6]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   Bypass request data sent using an ESMTP extension as part of the SMTP
+   dialog may not reach the OPES system if intermediate SMTP relays do
+   not support those bypass request commands and don't forward that
+   information.
+
+3.3.  Compatibility with Cryptographic Protection Mechanisms
+
+   Cryptography can be used to assure message privacy, to authenticate
+   the originator of messages, and to detect message modification.
+   There are standard methods for achieving some or all these
+   protections for generic messages ([9], [10], [11]), and these can be
+   used to protect SMTP data without changing the SMTP protocol.
+
+   The content of encrypted mail messages cannot be inspected by OPES
+   systems because only the intended recipient has the information
+   necessary for decryption.  The IAB and others have suggested that
+   users might want to share that information with OPES systems, thus
+   permitting decryption by intermediates.  For most cryptographic
+   systems that are compatible with email, this would require end users
+   to share their most valuable keys, in essence their "identities",
+   with OPES machines.  Some key management systems, particularly those
+   which have centralized administrative control of keys, might have
+   trust models in which such sharing would be sensible and secure.
+
+   After decrypting the message, an OPES box that modified the content
+   would be faced with the task of re-encrypting it in order to maintain
+   some semblance of "end-to-end" privacy.
+
+   If OPES/SMTP had a way to interact with end users on a per-message
+   basis, it might be possible to communicate cryptographic key
+   information from individual messages to end users, have them compute
+   the message encrypting key for particular message, and to send that
+   back to the OPES box.  This would perhaps ameliorate the need to
+   share a user's "master" message decrypting key with the OPES box.
+   This kind of communication has not been defined for OPES.
+
+   Message protection systems generally include some message integrity
+   mechanisms by which a recipient can check for a message modification
+   that may have occurred after the sender released the message.  This
+   protection can be applied to encrypted or plaintext messages and can
+   be accomplished through either symmetric or asymmetric cryptography.
+   In the case of symmetric cryptography, the key sharing problem is
+   exactly similar to the encryption case discussed previously.  If the
+   OPES box modified the content, then the message integrity (or
+   authentication) code would have to be recalculated and included with
+   the modified message.
+
+
+
+
+
+Stecher                      Informational                      [Page 7]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   For asymmetric cryptography the situation is more complicated.  The
+   message integrity is tied to the sender's public key, and although
+   anyone who can get the sender's public key can also check for a
+   message modification, no one but the sender can compute the sender's
+   signature on a modified message.  Thus, an OPES system could not
+   modify messages and have them appear to come from the purported
+   sender.  The notion of sharing the sender's signing key with the OPES
+   system is unpalatable because few trust models would be compatible
+   with sharing digital identities across organization boundaries.
+   However, if the OPES system doing the modification were under the
+   control of the sender's local administration, the sharing might be
+   sensible (as discussed for decryption, above).
+
+   OPES/SMTP systems could present modified content showing the modified
+   regions in a form that permits the authentication of the original
+   message and authentication of the OPES modifications (assuming the
+   OPES box had a digital signature identity and key).  One method for
+   doing this is outlined in [13], but to our knowledge this method is
+   not in any standard.
+
+   There are security risks associated with sharing cryptographic keys
+   that must be addressed by implementers.  Because this is not a simple
+   task, it is not a requirement for OPES/SMTP.
+
+4.  Protocol Requirements for OPES/SMTP
+
+   In addition to other documents listing requirements for OPES, the
+   discussion in this document implies specific requirements for
+   designing and implementing SMTP adaptations with OPES:
+
+   o  OPES Systems MUST add tracing headers to mail messages
+
+   o  If an email message that has been accepted by an OPES system
+      cannot be delivered, the non-delivery report MUST include trace
+      information of the OPES system.
+
+   o  The OPES/SMTP specifications MUST define a bypass request option
+      that can be included in mail messages.
+
+   o  The OPES/SMTP specifications MUST define a bypass request option
+      as an extension for SMTP dialogs.
+
+
+
+
+
+
+
+
+
+
+Stecher                      Informational                      [Page 8]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+5.  IAB Considerations for OPES/SMTP
+
+   This section lists the IAB considerations for OPES [2] and summarizes
+   how OPES/SMTP addresses them.
+
+5.1.  IAB Consideration (2.1) One-Party Consent
+
+   The IAB recommends that all OPES services be explicitly authorized by
+   one of the application-layer end-hosts (that is, either the data
+   consumer application or the data provider application).  For OPES/
+   SMTP, this means consent of either the email message sender or the
+   recipient.
+
+   The application agnostic architecture of OPES [7] requires that "OPES
+   processors MUST be consented to by either the data consumer or data
+   provider application" (OPES processor is the email gateway for OPES/
+   SMTP).  This cannot prevent the consent-less introduction of OPES
+   processors by noncompliant OPES entities.
+
+5.2.  IAB Consideration (2.2) IP-Layer Communications
+
+   The IAB recommends that OPES processors must be explicitly addressed
+   at the IP layer by the end user (data consumer application).
+
+   This requirement has been addressed by the architecture requirements
+   in Section 2.1 of [7] and has been further clarified in Section 2.2
+   of [3].
+
+5.3.  IAB Consideration (3.1) Notification
+
+   "The overall OPES framework needs to assist content providers in
+   detecting and responding to client-centric actions by OPES
+   intermediaries that are deemed inappropriate by the content provider"
+   [2].
+
+   For OPES/SMTP this translates into assistance for the email message
+   sender to detect and respond to recipient-centric actions that are
+   deemed inappropriate by the sender.
+
+   This has been addressed in Section 3.1 and by the second tracing
+   requirements in Section 4.  As discussed in Section 1.3, OPES/SMTP
+   cannot fix cases where NDRs are not sent or get blocked before
+   reaching the sender of the original message.
+
+
+
+
+
+
+
+
+Stecher                      Informational                      [Page 9]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+5.4.  IAB Consideration (3.2) Notification
+
+   "The overall OPES framework should assist end users in detecting the
+   behavior of OPES intermediaries, potentially allowing them to
+   identify imperfect or compromised intermediaries" [2].
+
+   This is addressed in Section 3.1 and by the first tracing requirement
+   in Section 4.  It must be noted that some email systems do not make
+   the email headers available to the end user, although the headers
+   belong to the payload that is transferred via SMTP.  Building an OPES
+   architecture with those email systems should be avoided or requires
+   that the tracing information be made available to the end users in a
+   different way.
+
+5.5.  IAB Consideration (3.3) Non-Blocking
+
+   "If there exists a "non-OPES" version of content available from the
+   content provider, the OPES architecture must not prevent users from
+   retrieving this "non-OPES" version from the content provider" [2].
+
+   For OPES/SMTP, this has been discussed in Section 3.2 and is
+   addressed by the two bypass requirements of Section 4.
+
+5.6.  IAB Consideration Application Layer Addresses (4.x)
+
+   While "most application layer addressing revolves around URIs"
+   (section 8 of [2]), SMTP uses email addresses, for which the
+   considerations only apply to some degree.
+
+   The SMTP use cases document [6] includes a use case for Mail
+   Rerouting and Address Rewriting.  Alias and email list address
+   resolution are standard functions of an email gateway described in
+   [4].
+
+   Translating the reference validity consideration regarding inter- and
+   intra-document reference validity to SMTP, OPES services mapping
+   internal to external email addresses MUST ensure the proper mapping
+   of addresses in all affected email headers.
+
+5.7.  IAB Consideration (5.1) Privacy
+
+   This consideration recommends that the overall OPES framework must
+   provide for mechanisms for end users to determine the privacy
+   policies that were used by OPES intermediaries.
+
+   The application agnostic part for OPES has been discussed in Section
+   10 of [3].  Email-specific trace information that will be added to
+   OPES/SMTP according to the requirements in Section 4 may raise
+
+
+
+Stecher                      Informational                     [Page 10]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   additional privacy issues that MUST be added to the privacy policy
+   description of the OPES system.
+
+5.8.  IAB Consideration Encryption
+
+   "If OPES was compatible with end-to-end encryption, this would
+   effectively ensure that OPES boxes would be restricted to ones that
+   are known, trusted, explicitly addressed at the IP layer, and
+   authorized (by the provision of decryption keys) by at least one of
+   the ends" [2].
+
+   This has been discussed in Section 3.3.
+
+6.  Security Considerations
+
+   The document itself discusses security considerations of OPES/SMTP.
+   General security threats of OPES are described in Security Threats
+   for OPES [8]
+
+   Section 3.3 ("Compatibility with Cryptographic Protection
+   Mechanisms") mentions that an OPES system could eventually deal with
+   cryptographic keys.  This raises security issues (such as
+   availability and storage of cryptographic keys) that must be
+   addressed by the implementer.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Floyd, S. and L. Daigle, "IAB Architectural and Policy
+         Considerations for Open Pluggable Edge Services", RFC 3238,
+         January 2002.
+
+   [3]   Barbir, A. and A. Rousskov, "Open Pluggable Edge Services
+         (OPES) Treatment of IAB Considerations", RFC 3914, October
+         2004.
+
+7.2.  Informative References
+
+   [4]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+         2001.
+
+   [5]   Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
+         Pluggable Edge Services (OPES)", RFC 4236, November 2005.
+
+
+
+
+Stecher                      Informational                     [Page 11]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+   [6]   Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES)
+         SMTP Use Cases", RFC 4496, May 2006.
+
+   [7]   Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
+         Architecture for Open Pluggable Edge Services (OPES)", RFC
+         3835, August 2004.
+
+   [8]   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.
+
+   [9]   Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
+         Security with OpenPGP", RFC 3156, August 2001.
+
+   [10]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
+         July 2004.
+
+   [11]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
+         Language) XML-Signature Syntax and Processing", RFC 3275, March
+         2002.
+
+   [12]  Barbir, A., "Open Pluggable Edge Services (OPES) Entities and
+         End Points Communication", RFC 3897, September 2004.
+
+   [13]  Orman, H., "Data Integrity for Mildly Active Content",
+         Proceedings of the Third Annual International Workshop on
+         Active Middleware Services, p.73, August 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stecher                      Informational                     [Page 12]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+Appendix A.  Acknowledgements
+
+   Many thanks to everybody who provided input and feedback for this
+   document.  Very special thanks to Hilarie Orman for her input and
+   suggestions, especially for the content of Section 3.3
+   ("Compatibility with Cryptographic Protection Mechanisms").
+
+Author's Address
+
+   Martin Stecher
+   Secure Computing Corporation
+   Vattmannstr. 3
+   33100 Paderborn
+   Germany
+
+   EMail: martin.stecher@webwasher.com
+   URI:   http://www.securecomputing.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stecher                      Informational                     [Page 13]
+
+RFC 4902                   OPES/SMTP Security                   May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Stecher                      Informational                     [Page 14]
+