idnits 2.17.1 draft-ietf-opes-smtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1103. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1109. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. == There is 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 240: '...A callout server MUST ignore unknown "...' RFC 2119 keyword, line 242: '... Some commands defined in [RFC2821] MUST NOT be used as application...' RFC 2119 keyword, line 265: '...its SMTP peer it MUST terminate the co...' RFC 2119 keyword, line 266: '...e parts in OCP transaction MUST follow...' RFC 2119 keyword, line 268: '... 4.1.4 of [RFC2821]. An OCP agent SHOULD terminate OCP transactions...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2005) is 6768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 3897 -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) == Outdated reference: A later version (-06) exists of draft-ietf-opes-smtp-use-cases-03 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services M. Stecher 3 Internet-Draft CyberGuard 4 Expires: April 16, 2006 C. Perz 5 All About IT 6 October 13, 2005 8 SMTP adaptation with OPES 9 draft-ietf-opes-smtp-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Open Pluggable Edge Services (OPES) framework documents several 43 application-agnostic mechanisms such as OPES tracing, OPES bypass, 44 and OPES callout protocol. This document extends those generic 45 mechanisms for Simple Mail Transfer Protocol (SMTP) adaptation. 46 Together, application-agnostic OPES documents and this SMTP profile 47 constitute a complete specification for SMTP adaptation with OPES. 49 Table of Contents 51 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. OPES Document Map . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1 Application Message Parts . . . . . . . . . . . . . . . . 6 55 3.2 Application Profile Features . . . . . . . . . . . . . . . 7 56 3.2.1 Profile Parts . . . . . . . . . . . . . . . . . . . . 8 57 3.2.2 Profile Structure . . . . . . . . . . . . . . . . . . 8 58 3.2.3 Adaptive-Parts . . . . . . . . . . . . . . . . . . . . 9 59 3.2.4 Informative-Parts . . . . . . . . . . . . . . . . . . 9 60 3.2.5 Header-List . . . . . . . . . . . . . . . . . . . . . 10 61 3.2.6 Negotiation Examples . . . . . . . . . . . . . . . . . 11 62 3.3 DUM and DUY Messages . . . . . . . . . . . . . . . . . . . 12 63 3.3.1 AM-Part Parameter . . . . . . . . . . . . . . . . . . 13 64 3.3.2 Allow Parameter . . . . . . . . . . . . . . . . . . . 14 65 3.3.3 SMTP-Error Parameter . . . . . . . . . . . . . . . . . 15 66 3.3.4 Advice Parameter . . . . . . . . . . . . . . . . . . . 16 67 3.3.5 Add-Header Parameter . . . . . . . . . . . . . . . . . 16 68 3.4 SMTP Extension handling . . . . . . . . . . . . . . . . . 17 69 3.4.1 Negotiating SMTP Extensions . . . . . . . . . . . . . 18 70 3.4.2 Transfer of extension information . . . . . . . . . . 18 71 3.4.3 Extension meta information . . . . . . . . . . . . . . 19 72 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 4. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 4.1 Tracing Headers . . . . . . . . . . . . . . . . . . . . . 21 75 4.2 SMTP Trace Extension . . . . . . . . . . . . . . . . . . . 22 76 5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 79 8. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 81 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 83 9.1 Normative References . . . . . . . . . . . . . . . . . . . 30 84 9.2 Informative References . . . . . . . . . . . . . . . . . . 30 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 86 Intellectual Property and Copyright Statements . . . . . . . . 32 88 1. Scope 90 The Open Pluggable Edge Services (OPES) framework documents several 91 application-agnostic mechanisms such as OPES processor and endpoints 92 communications [RFC3897] or OPES callout protocol [RFC4037]. This 93 document extends those generic mechanisms for adaptation of a 94 specific application protocol, SMTP [RFC2821]. Together, 95 application-agnostic OPES documents and this SMTP profile constitute 96 a complete specification for SMTP adaptation with OPES. 98 The primary sections of this document specify SMTP-specific 99 extensions for the corresponding application-agnostic mechanisms 100 documented elsewhere. 102 2. OPES Document Map 104 This document belongs to a large set of OPES specifications produced 105 by the IETF OPES Working Group. Familiarity with the overall OPES 106 approach and typical scenarios is often essential when trying to 107 comprehend isolated OPES documents. This section provides an index 108 of OPES documents to assist the reader with finding "missing" 109 information. 111 o The document on "OPES Use Cases and Deployment Scenarios" 112 [RFC3752] describes a set of services and applications that are 113 considered in scope for OPES and have been used as a motivation 114 and guidance in designing the OPES architecture. 116 o Usecases specifically for SMTP that are motivation for the SMTP 117 adaptation described in this document have been lised in "OPES 118 SMTP Use Cases" [I-D.ietf-opes-smtp-use-cases]. 120 o The OPES architecture and common terminology are described in "An 121 Architecture for Open Pluggable Edge Services (OPES)" [RFC3835]. 123 o "Policy, Authorization and Enforcement Requirements of OPES" 124 [RFC3838] outlines requirements and assumptions on the policy 125 framework, without specifying concrete authorization and 126 enforcement methods. 128 o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk 129 analysis, without recommending specific solutions. 131 o "OPES Treatment of IAB Considerations" [RFC3914] addresses all 132 architecture-level considerations expressed by the IETF Internet 133 Architecture Board (IAB) when the OPES WG was chartered. 135 o At the core of the OPES architecture are the OPES processor and 136 the callout server, two network elements that communicate with 137 each other via an OPES Callout Protocol (OCP). The requirements 138 for such protocol are discussed in "Requirements for OPES Callout 139 Protocols" [RFC3836]. 141 o "OPES Callout Protocol Core" [RFC4037] specifies an application 142 agnostic protocol core to be used for the communication between 143 OPES processor and callout server. 145 o "OPES entities and end points communications" [RFC3897] specifies 146 generic tracing and bypass mechanisms for OPES. 148 o The OCP Core and Communications documents are independent from the 149 application protocol being adapted by OPES entities. Their 150 generic mechanisms have to be complemented by application-specific 151 profiles. This document, SMTP adaptation with OPES, is such an 152 application profile for SMTP. It specifies how application- 153 agnostic OPES mechanisms are to be used and augmented in order to 154 support adaptation of SMTP messages. 156 o Finally, "P: Message Processing Language" [I-D.ietf-opes-rules-p] 157 defines a language for specifying what OPES adaptations (e.g, 158 translation) must be applied to what application messages (e.g., 159 e-mail from bob@example.com). P language is meant for configuring 160 application proxies (OPES processors). 162 3. Callout Protocol 164 This section documents the SMTP profile for the OPES Callout Protocol 165 (OCP) Core [RFC4037]. Familiarity with OCP Core is required to 166 understand the SMTP profiles. This section uses OCP Core 167 conventions, terminology, and mechanisms. 169 The OPES processor communicates its desire to adapt SMTP messages via 170 a Negotiation Offer (NO) message with SMTP-specific feature 171 identifiers documented in Section 3.2. SMTP-specific OCP 172 optimization mechanisms can be negotiated at the same time. A 173 callout server that supports adaptation of SMTP messages has a chance 174 to negotiate what SMTP message parts will participate in adaptation, 175 including SMTP commands and email body elements as application 176 message parts documented in Section 3.1. 178 3.1 Application Message Parts 180 An SMTP message may have several well-known parts: SMTP commands such 181 as HELO, MAIL, RCPT and email content sent after the DATA command. 182 The email content has a header and a body; and the email body again 183 can be divided into several sections. 185 An SMTP OPES processor has to have information about at least some 186 SMTP message parts (of those SMTP commands it supports). It may or 187 may not be able to divide the email content into parts. A callout 188 server may want to ask the OPES processor to do email content 189 preprocessing for a more efficient OCP handling. The agents will 190 negotiate the capabilities of the OPES processor and the needs of the 191 callout server using the application message parts in additional 192 parameters that will be defined for the Negotiation Offer (NO) and 193 Negotiation Response (NR) messages in Section 3.2.1. 195 The following is the declaration of am-part (application message 196 part) type using OCP Core Protocol Element Type Declaration Mnemonic 197 (PETDM): 198 am-part: extends atom; 199 am-parts: extends list of am-part; 201 Figure 1 203 The following "am-part" atoms are valid values: 205 EHLO: The argument of the Extended HELLO command as defined in 206 section 4.1.1.1 of [RFC2821]. 208 HELO: The argument of the HELLO command as defined in section 4.1.1.1 209 of [RFC2821]. 211 MAIL: The argument of the MAIL command as defined in section 4.1.1.2 212 of [RFC2821]. 214 RCPT: The argument of the RECIPIENT command as defined in section 215 4.1.1.3 of [RFC2821]. 217 VRFY: The argument of the VERIFY command as defined in section 218 4.1.1.6 of [RFC2821]. 220 EXPN: The argument of the EXPAND command as defined in section 221 4.1.1.7 of [RFC2821]. 223 RAWDATA: The complete mail data which is sent AFTER the DATA command 224 (see section 4.1.1.4 of [RFC2821]). 226 ALLHEADERS: The header of the email data including the empty line at 227 the end as defined in section 2.1 of [RFC2822]. 229 SINGLEHEADERS: Some or all header fields of the email data, each to 230 be sent in a separate OCP message. 232 BODY: The body of the email data as defined in section 2.3 of 233 [RFC2822]. 235 SECTIONS: Sections of the email body (for example MIME sections), 236 each to be sent in a separate OCP message. 238 The list of calid "am-part" atoms can be extended, especially to 239 represent commands that have been defined in extension to [RFC2821]. 240 A callout server MUST ignore unknown "am-part" atoms. 242 Some commands defined in [RFC2821] MUST NOT be used as application 243 message parts for OCP. These include DATA, RSET and QUIT. 245 3.2 Application Profile Features 247 This document defines two SMTP profiles for OCP: sender and receiver 248 profiles. These two profiles are described below. Each profile has 249 a unique feature identifier: 251 profile ID: http://iana.org/opes/ocp/SMTP/sender 252 profile ID: http://iana.org/opes/ocp/SMTP/receiver 254 The sender profile is used by the OPES processor while or just before 255 he is sending a message to another peer using the SMTP protocol, the 256 receiver defines the opposite: the OPES processor is receiving or has 257 just received a message from another peer using the SMTP protocol. 259 The scope of a negotiated profile is the OCP connection (default) or 260 the service group specified via the SG parameter. 262 3.2.1 Profile Parts 264 If an SMTP OPES processor receives a valid RSET or QUIT command from 265 its SMTP peer it MUST terminate the corresponding OCP transaction. 266 The order of application message parts in OCP transaction MUST follow 267 the order of commands in the SMTP transaction as defined in section 268 4.1.4 of [RFC2821]. An OCP agent SHOULD terminate OCP transactions 269 with incorrect application message part orders. 271 Some application message parts are mutually exclusive within one OCP 272 transaction: RAWDATA and any message part of the following list are 273 mutually exclusive: ALLHEADERS, SINGLEHEADERS, BODY, SECTIONS. 274 ALLHEADERS and SINGLEHEADERS are mutually exclusive. BODY, SECTIONS 275 are mutually exclusive. 277 3.2.2 Profile Structure 279 An SMTP application profile feature extends semantics of the feature 280 type of OCP Core while adding the following named parameters to that 281 type: 283 o Adaptive-Parts (Section 3.2.3) 285 o Informative-Parts (Section 3.2.4) 287 o Header-List (Section 3.2.5) 289 The definition of the SMTP profile feature structure using PETDM 290 follows: 292 SMTP-Profile: extends Feature with { 293 [Adaptive-Parts: am-parts]; 294 [Informative-Parts: am-parts]; 295 [Header-List: headernames]; 296 }; 298 Figure 2 300 An SMTP profile structure can be used in feature lists of Negotiation 301 Offer (NO) messages and as anonymous parameter of an Negotiation 302 Response (NR) mesage. All profile parameters apply to any OCP 303 transaction within profile scope. 305 3.2.3 Adaptive-Parts 307 The list of application message parts negotiated as Adaptive-Parts 308 specify those parts that the OPES processor allows the callout server 309 to change and that the callout server expects to adapt while running 310 the specified callout service. 312 The OPES processor MUST NOT list application message parts as 313 Adaptive-Commands for which it is not willing or able to accept 314 changes or error responses from the callout server. 316 A callout server SHOULD only list those message parts in the 317 Adaptive-Parts parameter of the Negotiation Response (NR) message 318 that it may eventually change. Those message parts that the callout 319 server needs for information only SHOULD be moved to the Informative- 320 Parts list. 322 The callout server MUST NOT add a message part to the Adaptive-Parts 323 list of the Negotiation Response (NR) message if that part was not 324 contained in the Adaptive-Parts list of the Negotiation Offer (NO) 325 message. The OPES processor MUST close a connection if a message 326 part is returned in the Negotiation Response (NR) message that it 327 does not support. 329 The OPES processor is not bound to the mutual exclusive rule for 330 application message parts as defined in Section 3.2.1 and can list 331 any application message parts it supports. The callout server MUST 332 NOT list application message parts in the Negotiation Response (NR) 333 message that are mutually exclusive. 335 The Adaptive-Parts parameter can be omitted which then means an empty 336 list of am-part atoms. 338 3.2.4 Informative-Parts 340 In addition to the Adaptive-Parts the OCP agents can negotiate the 341 inclusion of auxiliary application message parts by using the 342 Informative-Parts parameter. Message parts of this list will not be 343 adaptable by the callout server but provide meta information that is 344 needed for the service. 346 All application message parts that the OPES processor has offered as 347 Adaptive-Parts can also be returned as Informative-Parts by the 348 callout server. The OPES processor SHOULD NOT list application 349 message parts as Informative-Parts again if the part was already 350 listed under Adaptive-Parts although this does not define a 351 semantical difference. A callout server MUST NOT list application 352 message parts as Informative-Parts if it already lists them as 353 Adaptive-Parts; the OPES processor MUST close the connection is such 354 a case. 356 The callout server MUST NOT add a message part to the Informative- 357 Parts list of the Negotiation Response (NR) message if that part was 358 neither contained in the Adaptive-Parts list nor in the Informative- 359 Parts list of the Negotiation Offer (NO) message. The OPES processor 360 MUST close a connection if a message part is returned in the 361 Negotiation Response (NR) message that it does not support. 363 The OPES processor is not bound to the mutual exclusive rule for 364 application message parts as defined in Section 3.2.1 and can list 365 any application message parts it supports. The callout server MUST 366 NOT list application message parts in the Negotiation Response (NR) 367 message that are mutually exclusive. 369 The Informative-Parts parameter can be omitted which then means an 370 empty list of am-part atoms. 372 3.2.5 Header-List 374 The callout server can use the Header-List parameter in an 375 Negotiation Response (NR) OCP message if it listed the SINGLEHEADERS 376 message part token in either Adaptive-Parts or Informative-Parts. 377 With this parameter it specifies which single headers it wants to 378 receive during the transactions. Before this the OPES processor has 379 indicated its ability to sent separated email headers by listing 380 SINGLEHEADERS in the Adaptive-Parts or Informative-Parts of the 381 Negotiation Offer (NO) message. 383 The following is the declaration of headernames (list of header 384 names) type using OCP Core Protocol Element Type Declaration Mnemonic 385 (PETDM); the type is used as a the value type for the Header-List 386 parameter: 387 headername: atom / "*"; 388 headernames: extends list of headername; 390 Figure 3 392 [Note: May not be a good idea to allow "*" as a token as this is not 393 a bare atom; may be better to defined headername as atom and use the 394 wildcard in the quoted form "1:*"] 395 The value of headername is the name of a case insensitive email 396 header that should be transmitted to the callout server. The 397 wildcard "*" requests all available headers. 399 The requested header lines are transmitted in separated OCP messages, 400 using one message for each header. Requestes headers are only sent 401 if they exist in the original message. 403 The callout server MUST use a Header-List parameter if it listed 404 SINGLEHEADERS as an Informative- or Adaptive-Part and it MUST NOT use 405 the Header-List parameter if SINGLEHEADERS is not listed as such a 406 part. 408 3.2.6 Negotiation Examples 410 In this example the OPES processor offers recipient information and 411 the message data as Adaptive-Parts, which means that it is willing to 412 accept changes to these items. As auxiliary information, it can send 413 IP, HELO and MAIL command arguments. The callout server replies that 414 it only needs DATA, MAIL and RCPT and it might only change the DATA 415 part of the message. 417 Example 1: P=OPES processor, S=Callout Server 418 P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" 419 Adaptive-Commands: (RCPT,DATA) 420 Informative-Commands: (IP,HELO,MAIL) 421 }) 422 SG: 25 423 ; 424 S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" 425 Adaptive-Commands: (DATA) 426 Informative-Commands: (MAIL,RCPT) 427 } 428 SG: 25 429 ; 431 Figure 4 433 In the second example the callout server accepts all items offered by 434 the OPES processor and requests some single headers from processed 435 messages. 437 Example 2: P=OPES processor, S=Callout Server 438 P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" 439 Adaptive-Commands: (MAIL,RCPT) 440 Informative-Commands: (IP,EHLO,SINGLEHEADERS) 441 }) 442 SG: 25 443 ; 444 S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" 445 Adaptive-Commands: (MAIL,RCPT) 446 Informative-Commands: (IP,EHLO,SINGLEHEADERS) 447 Header-List: (From,To,Reply-To,Received) 448 } 449 SG: 25 450 ; 452 Figure 5 454 3.3 DUM and DUY Messages 456 The SMTP application profiles extend semantics of the DUM and DUY 457 messages defined in OCP Core by adding the following named 458 parameters: 460 o AM-Part (Section 3.3.1) 462 o Allow (Section 3.3.2) 464 o SMTP-Error (Section 3.3.3) 466 o Advice (Section 3.3.4) 468 o Add-Header (Section 3.3.5) 470 The following parameters are defined for DUM messages: 472 AM-Part: am-part 473 Allow: supported-params 474 SMTP-Error: atom 475 Advice: advice 476 Add-Header: atom 478 Figure 6 480 The following parameters are defined for DUY messages: 482 Advice: advice 483 Add-Header: atom 485 Figure 7 487 3.3.1 AM-Part Parameter 489 An OCP agent MUST send an AM-Part parameter with every DUM message 490 that is a part of an OCP transaction with an SMTP profile. The AM- 491 Part parameter value is a single am-part token. As implied by the 492 syntax, a DUM message can only contain data of a single application 493 message part. 495 Only the following message parts can be fragmented into any number of 496 DUM messages with the same AM-Part parameter: RAWDATA, ALLHEADERS, 497 BODY, SECTIONS. All other application message parts MUST each be 498 sent in a single DUM message. 500 The following example shows four DUM messages containing an abridged 501 SMTP response transaction. The RAWDATA part is fragmented and sent 502 within two DUM messages. 504 DUM 72 1 0 505 Kept: 0 506 AM-Part: MAIL 508 19: 509 ; 510 DUM 72 1 19 511 Kept: 19 512 AM-Part: RCPT 514 18: 515 ; 516 DUM 72 1 37 517 Kept: 37 518 AM-Part: RAWDATA 520 49:From: steve@example.org 521 To: sandra@example.com 523 ; 524 DUM 72 1 86 525 Kept: 86 526 AM-Part: RAWDATA 528 41:Subject: Test 530 Hi, this is a test! 531 . 533 ; 535 Figure 8 537 3.3.2 Allow Parameter 539 The Allow parameter is used by the OPES processor to indicate to the 540 callout server which optional parameters are supported by the OPES 541 processor when receiving DUM and DUY messages from the callout 542 server. This information can be important for the callout server. 543 For example: A callout server may prefer to have the OPES processor 544 to send an SMTP error in response to email message data in order to 545 reject the message but if the OPES processor is not able to do this 546 (or not willing to do this) the callout server may want to exchange 547 the email body content by an error message. 549 The following is the declaration of supported-params type (value type 550 of the Allow Parameter) using OCP Core Protocol Element Type 551 Declaration Mnemonic (PETDM): 552 supported-param: extends atom; 553 supported-params: extends list of supported-param; 555 Figure 9 557 The following "supported-param" atoms are defined by this document: 559 SMTP-Error: The OPES processor will accept an SMTP error response for 560 this application message part. The callout server MAY use the 561 SMTP-Error parameter as defined in Section 3.3.3. 563 Advice: The OPES processor will accept an advice from the callout 564 server what to do with this message. The callout server MAY use 565 the Advice parameter as defined in Section 3.3.4. 567 Add-Header: The OPES processor will accept an Add-Header directive. 568 The callout server MAY use the Add-Header parameter as defined in 569 Section 3.3.5. 571 The list of possible values for the "supported-param" atom can be 572 extended, especially by new parameter names of DUM and DUY messages 573 that will be defined in extensions to this document. Therefore the 574 callout server MUST ignore unknown atoms in the supported-params 575 list. The "supported-params" list MAY be empty. 577 The Allow parameter MUST NOT be sent by the callout server. The OPES 578 processor SHOULD add an Allow parameter to a DUM message if it is 579 able and willing to accept some of the additional parameters in DUM 580 and DUY messages that the callout server sends in response to the DUM 581 message of the OPES processor carrying the Allow parameter (i.e. DUM 582 messages with the same AM-Part and DUY messages referencing the data 583 of DUM messages). The Allow parameter MAY be omitted which is 584 semantically equal to an empty "supported-params" list. The Allow 585 parameter can be used for Adaptive-Parts as well as for Informative- 586 Parts. 588 3.3.3 SMTP-Error Parameter 590 The SMTP-Error parameter can be used by the callout server if it 591 wants the OPES processor to reply with an SMTP error to the SMTP 592 command that is encapsulated in the DUM message that the callout 593 server received. 595 By changing the payload of a DUM message the callout server adapts 596 the corresponding SMTP argument or email data. When adding a SMTP- 597 Error parameter the callout server SHOULD send an empty payload. 599 The OPES processor MUST NOT send SMTP-Error parameters with DUM 600 messages, the callout server SHOULD NOT send SMTP-Error parameters 601 with a DUM message if SMTP-Error was not in the list of "supported- 602 params" in the Allow-Parameter of the DUM message it responds to. 603 The SMTP-Error parameter MUST NOT be sent in a DUY message. 605 The value atom of the SMTP-Error parameter is a quoted-value with an 606 SMTP reply as defined in s ection 4.2 of [RFC2821] but without the 607 final CRLF characters at the end of the (last) reply line. 609 Example: P=OPES processor, S=Callout Server 610 P: DUM 72 1 0 611 Kept: 0 612 AM-Part: RCPT 613 Allow: (SMTP-Error) 615 18: 616 ; 617 S: DUM 72 1 0 618 AM-Part: RCPT 619 SMTP-Error: "21:550 No such user here" 621 0: 622 ; 624 Figure 10 626 3.3.4 Advice Parameter 628 Advice can be s.th. like "Discard" or "Quarantine". More definitions 629 are needed here. 631 To be done 633 3.3.5 Add-Header Parameter 635 The Add-Header parameter can be used by the callout server to have 636 the OPES processor to add an additional header line to the email 637 data. This can be an interesting side effect especially if the 638 callout server does not intend to modify the email content 639 application parts for other purposes. 641 The OPES processor MUST NOT send Add-Header parameters with DUM 642 messages, the callout server SHOULD NOT send Add-Header parameters 643 with DUM or DUY messages if Add-Header was not in the list of 644 "supported-params" in the Allow-Parameter of the DUM message it 645 responds to. 647 The value atom of the Add-Header parameter is a quoted-value with an 648 SMTP header lines as defined in s ection 2.2 of [RFC2822] but without 649 the terminating CRLF characters. 651 Example: P=OPES processor, S=Callout Server 652 P: DUM 72 1 0 653 Kept: 0 654 AM-Part: RCPT 655 Allow: (SMTP-Error,Add-Header) 657 18: 658 ; 659 S: DUM 72 1 0 660 AM-Part: RCPT 661 Add-Header: "33:X-Original-User: paul@example.com" 663 21: 664 ; 666 Figure 11 668 3.4 SMTP Extension handling 670 Section 2.2 of [RFC2821] describes the Extension Model for SMTP, 671 "that permits the client and server to agree to utilize shared 672 functionality beyond the original SMTP requirements". Extensions can 673 add or replace SMTP keywords and may add additional parameters to the 674 SMTP MAIL and RCPT commands. 676 Further, extensions could create new meta information, that is not 677 part of the extension, but relevant for certain actions of a callout 678 server. Authentication within an SMTP session is an extension, but 679 the information wether the authentication process was successful or 680 not is in the domain of the MTA. 682 An MTA will use extensions during an SMTP session, regardless if a 683 callout server knows about them or not. But the callout server could 684 benefit from any data, that was exchanged using it. 686 Thus an OPES SMTP profile needs three features to deal with SMTP 687 extensions. 689 o The callout server must be able to tell the OPES processor, what 690 extensions it knows about (Section 3.4.1) 692 o The OPES processor needs a method how to submit the extension data 693 to the callout server (Section 3.4.2) 695 o Keywords for exchanging meta information must be defined 696 (Section 3.4.3) 698 3.4.1 Negotiating SMTP Extensions 700 The callout server will add a named parameter "Extensions" to the NR 701 message with a list of keywords of extensions it supports. It uses 702 the the EHLO response keyword value associated with the extension as 703 defined in the underlying RFC. 705 Example: Extensions are AUTH and SIZE 706 P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" 707 Adaptive-Commands: (RCPT,DATA) 708 Informative-Commands: (IP,HELO,MAIL) 709 }) 710 SG: 25 711 ; 712 S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" 713 Adaptive-Commands: (DATA) 714 Informative-Commands: (MAIL,RCPT) 715 Extensions: (AUTH,SIZE) 716 } 717 SG: 25 718 ; 720 Figure 12 722 3.4.2 Transfer of extension information 724 The OPES processor can then send the data in the same way to the 725 callout server as it would do to SMTP receivers that indicated their 726 extension support with the keywords in the EHLO response. 728 These can be parameters with the MAIL and RCPT command arguments or 729 additional commands (which have also been negotiated in the am-parts 730 lists of the NO/NR messages. 732 Example 1: SIZE is listed as supported extension 733 P: DUM 72 1 0 734 AM-Part: MAIL 735 Allow: (SMTP-Error,Advice) 736 18: SIZE=256 737 ; 739 Figure 13 741 Example 2: Fictive extension VIPEXT, 742 that defines the new keyword VIPNAME: 743 P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" 744 Adaptive-Commands: (RCPT,DATA) 745 Informative-Commands: (IP,HELO,MAIL,VIPNAME) 746 }) 747 SG: 25 748 ; 749 S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" 750 Adaptive-Commands: (DATA) 751 Informative-Commands: (MAIL,RCPT,VIPNAME) 752 Extensions: (AUTH,SIZE,VIPEXT) 753 } 754 SG: 25 755 ; 756 P: DUM 72 1 0 757 AM-Part: VIPNAME 758 Allow: (SMTP-Error,Advice) 760 10:"John Doe" 761 ; 763 Figure 14 765 3.4.3 Extension meta information 767 Addtional information as a result of using extensions between two 768 SMTP peers can be transferred by putting the AM-OPT parameter in a 769 DUM message. Any data an OPES processor knows about can be send in 770 the described way. The callout server SHOULD provide a mechanism to 771 map the processors keywords to its internal names. 773 P: DUM 33 27 774 AM-Part: MAIL 775 AM-OPT: ({authtype cram-md5},{authen true}) 777 53:sender@example.org SIZE=33423 AUTH=sender@example.org 778 ; 780 Figure 15 782 3.5 Examples 784 To be done. 786 4. Tracing 788 [RFC3897] defines application-agnostic tracing facilities in OPES. 789 Compliance with this specification requires compliance with 790 [RFC3897]. 792 4.1 Tracing Headers 794 When adapting SMTP, trace entries are supplied using header lines for 795 the message content. The following extension headers are defined to 796 carry trace entries. Their definitions are given using BNF notation; 797 the definition for "absoluteURI" is taken from [RFC2396]. 799 OPES-System = "OPES-System" ":" #trace-entry 800 OPES-Via = "OPES-Via" ":" #trace-entry 802 trace-entry = opes-agent-id *( ";" parameter ) 803 opes-agent-id = absoluteURI 805 Figure 16 807 An OPES System MUST add its trace entry to the OPES-System header. 808 Other OPES agents MUST use the OPES-Via header if they add their 809 tracing entries. All OPES agents MUST append their entries. 810 Informally, OPES-System is the only required OPES tracing header 811 while OPES-Via provides optional tracing details; both headers 812 reflect the order of trace entry additions. 814 An OPES System MUST NOT change OPES-System and OPES-VIA headers that 815 were previously added to the message header. OPES agents MUST 816 prepend OPES-System and OPES-VIA lines before all existing OPES- 817 System and OPES-VIA lines; they MUST NOT change the order of existing 818 lines or insert OPES-System and OPES-VIA lines in any other location. 819 If an OPES System is using both headers, it MUST add identical trace 820 entries except it MAY omit some or all trace-entry parameters from 821 the the OPES-Via header. Informally, the OPES System entries in the 822 OPES-Via header are used to delimit and group OPES-Via entries from 823 different OPES Systems without having a priory knowledge about OPES 824 System identifiers. 826 For example, here is an email message header after OPES adaptations 827 have been applied by two OPES processors, the first executing 10 OPES 828 services: 830 Received: from gateway.example.com ([192.0.2.138]) 831 by mail.example.com with testserver; 832 Mon, 10 Oct 2005 05:37:19 +0200 833 Received: from mail2.example.org [192.0.2.99] 834 by gateway.example.com id 33W9WIMC; 835 Mon, 10 Oct 2005 05:35:55 +0200 836 OPES-System: http://mail.example.com/opes?id=33W9WIMC 837 OPES-System: http://gateway.example.com/opes?session=33W9WIMC 838 OPES-Via: http://gateway.example.com/opes?session=33W9WIMC, 839 http://www.opes-services-4u.com/cat/?sid=123, 840 http://www.opes-services-4u.com/cat/?sid=124, 841 http://www.opes-services-4u.com/cat/?sid=125 ; mode=A 842 Subject: Test 843 From: "Steve" 844 To: "Sandra" 846 Figure 17 848 In the above example, the first OPES processor has not included its 849 trace entry or its trace entry was replaced by an OPES system trace 850 entry. Only 3 out of 10 services are traced. The remaining services 851 did not include their entries or their entries were removed by OPES 852 system or processor. The last traced service included a "mode" 853 parameter. The second OPES system has added its trace line before 854 the other header lines. Various identifiers in trace entries will 855 probably have no meaning to the recipient of the message, but may be 856 decoded by OPES System software. 858 OPES entities MAY place optional tracing entries in the message 859 content. 861 4.2 SMTP Trace Extension 863 An OPES processor MUST support the SMTP Service Extension for OPES 864 Trace and Bypass [to be done in external document; referenced from 865 here]. 867 To request notitifications about actions taken by OPES intermediates 868 while a message is relayed to its recipients, the sender of the 869 message adds the parameter "opestrace" to the MAIL FROM SMTP command. 871 The requested information is sent as a separate message and is 872 generated by each OPES system in the chain. The message MUST contain 873 all message headers, including the trace headers. It MUST NOT 874 contain any parts of the body of the original message. 876 [Comment to discuss on email list: Note that DSN (RFC1891) has not 877 been chosen as a method for sending trace information back to the 878 sender as that would offer an attacker to also send the email content 879 body with potential malicious content to a faked sender address. 880 Another candidate to evaluate is Message Tracking (RFC3885); maybe 881 this can be used rather than defining yet another method.] 883 5. Bypass 885 An OPES processor MUST support the SMTP Service Extension for OPES 886 Trace and Bypass [to be done in external document; referenced from 887 here] which allows for OPES system bypass as defined in [RFC3897]. 889 As SMTP does not include client requests an OPES bypass for SMTP is 890 triggered by asking the email message sender to initiate the bypass 891 on behalf of the recipient. 893 [Extension be done in external document; referenced from here. Draft 894 idea: New keyword to add to EHLO responses is "OPES", allows two new 895 extensions for the MAIL FROM command argument: (1) "opestrace" to 896 send trace information to the sender of the message and (2) 897 "opesbypass=( "*" | 1#bypass-entry )" for a list of OPES agent IDs to 898 bypass.] 900 The decision, if a bypass request is fulfilled must be taken by the 901 OPES processors in a chain and is their responsibility, because it is 902 possible, that executing a bypass request results in an undelivarable 903 message. If one OPES processor cannot fulfill the request, non-OPES 904 content is not available. 906 Especially for client centric OPES adaptations, other bypass methods 907 may be added that allow direct bypass requests from the recipients to 908 the OPES systems; that needs to be implemented outside of the normal 909 SMTP message flow (as SMTP traffic is not request/response) and is 910 therefore out of the scope of this document. 912 [Comment to discuss on email list: The whole bypass idea is an issue 913 for protocols that do not have client requests. Is a general out-of- 914 band solution required?] 916 6. IAB Considerations 918 OPES treatment of IETF Internet Architecture Board (IAB) 919 considerations [RFC3238] are documented in "OPES Treatment of IAB 920 Considerations" [RFC3914]. 922 Section 5.3 of [RFC3914] talks about trace information in application 923 message requests and that "some application protocols may not have 924 explicit requests". This is fact for SMTP and therefore the MUST 925 requirement for a new SMTP extension has been added for OPES 926 processors for SMTP (Section 4.2); non-OPES SMTP servers are also 927 encouraged to implement that extension. If some SMTP relays on the 928 way of the email from or to the OPES processors do not support the 929 opestrace extension, the trace notifications may not be delivered. 930 This lack of trace notifications is not a problem that has been 931 introduced by OPES but a general SMTP issue. In such a case the 932 email sender can still contact the recipients and ask to provide 933 email headers of the message in question or similar messages in order 934 to get trace information of the OPES systems involved. 936 OPES bypass will also fail if some SMTP relays on the way of the 937 email do not supports the OPES SMTP extension. The sender will 938 detect whether an SMTP server supports this extension by parsing the 939 EHLO response. With information from the trace notification the 940 sender can try to contact the first OPES processor which MUST support 941 the bypass extension according to Section 5. 943 7. Security Considerations 945 Application-independent security considerations are documented in 946 application-agnostic OPES specifications [RFC3837]. 948 Requests to bypass OPES agents (Section 5) are sent by the email 949 message sender on request of the recipient. A malicious sender could 950 try to activate the bypass of OPES security services; it is important 951 that implementations of the bypass feature include a policy that 952 defines which OPES agents can be bypassed and which cannot. 954 8. Compliance 956 Compliance with OPES mechanisms is defined in corresponding 957 application-agnostic specifications. SMTP profiles for these 958 mechanisms use corresponding compliance definitions from these 959 specifications, as if each profile was incorporated into the 960 application-agnostic specification it profiles. 962 Appendix A. Acknowledgments 963 Appendix B. Change Log 965 Internal WG revision control ID: $Id: smtp.xml,v 1.6 2005/10/13 15: 966 18:54 martin Exp $ 968 2005/10/13 970 * Filled Header-List section. 972 * Added negotiation examples 974 * Filled Extension sections 976 2005/10/12 978 * Clemens' corrections and additions to Tracing and Bypass. 980 * Added hint to evaluate Message Tracking (RFC3885) 982 2005/10/11 984 * Removed DSN requirements, added new requirement for Trace/ 985 Bypass SMTP extension. 987 2005/10/10 989 * Tracing section and additional to IAB considerations. 991 * Corrections provided by Clemens. 993 2005/09/29 995 * Added DUM/DUY sections with parameters. 997 * Started SMTP Extension Handling section. 999 * Updated RFC numbers in document map and References section. 1001 2005/09/23 1003 * Initial revision. 1005 9. References 1007 9.1 Normative References 1009 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1010 April 2001. 1012 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1013 April 2001. 1015 [RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities 1016 and End Points Communication", RFC 3897, September 2004. 1018 [RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout 1019 Protocol (OCP) Core", RFC 4037, March 2005. 1021 9.2 Informative References 1023 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1024 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1025 August 1998. 1027 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 1028 Considerations for Open Pluggable Edge Services", 1029 RFC 3238, January 2002. 1031 [RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., 1032 and R. Penno, "Open Pluggable Edge Services (OPES) Use 1033 Cases and Deployment Scenarios", RFC 3752, April 2004. 1035 [RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. 1036 Orman, "An Architecture for Open Pluggable Edge Services 1037 (OPES)", RFC 3835, August 2004. 1039 [RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. 1040 Terzis, "Requirements for Open Pluggable Edge Services 1041 (OPES) Callout Protocols", RFC 3836, August 2004. 1043 [RFC3837] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. 1044 Orman, "Security Threats and Risks for Open Pluggable Edge 1045 Services (OPES)", RFC 3837, August 2004. 1047 [RFC3838] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, 1048 "Policy, Authorization, and Enforcement Requirements of 1049 the Open Pluggable Edge Services (OPES)", RFC 3838, 1050 August 2004. 1052 [RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services 1053 (OPES) Treatment of IAB Considerations", RFC 3914, 1054 October 2004. 1056 [I-D.ietf-opes-smtp-use-cases] 1057 Barbir, A. and M. Stecher, "OPES SMTP Use Cases", 1058 draft-ietf-opes-smtp-use-cases-03 (work in progress), 1059 July 2005. 1061 [I-D.ietf-opes-rules-p] 1062 Rousskov, A., "P: Message Processing Language", 1063 draft-ietf-opes-rules-p-02 (work in progress), 1064 October 2003. 1066 Authors' Addresses 1068 Martin Stecher 1069 CyberGuard Corporation 1070 Webwasher Division 1071 Vattmannstr. 3 1072 33100 Paderborn 1073 Germany 1075 Email: martin.stecher@webwasher.com 1076 URI: http://www.cyberguard.com/ 1078 Clemens Perz 1079 All About It Systems S.A. 1080 16, rue du Parc 1081 L-6684 Mertert 1082 Luxembourg 1084 Email: cperz@allaboutit.lu 1085 URI: http://www.allaboutit.lu/ 1087 Intellectual Property Statement 1089 The IETF takes no position regarding the validity or scope of any 1090 Intellectual Property Rights or other rights that might be claimed to 1091 pertain to the implementation or use of the technology described in 1092 this document or the extent to which any license under such rights 1093 might or might not be available; nor does it represent that it has 1094 made any independent effort to identify any such rights. Information 1095 on the procedures with respect to rights in RFC documents can be 1096 found in BCP 78 and BCP 79. 1098 Copies of IPR disclosures made to the IETF Secretariat and any 1099 assurances of licenses to be made available, or the result of an 1100 attempt made to obtain a general license or permission for the use of 1101 such proprietary rights by implementers or users of this 1102 specification can be obtained from the IETF on-line IPR repository at 1103 http://www.ietf.org/ipr. 1105 The IETF invites any interested party to bring to its attention any 1106 copyrights, patents or patent applications, or other proprietary 1107 rights that may cover technology that may be required to implement 1108 this standard. Please address the information to the IETF at 1109 ietf-ipr@ietf.org. 1111 Disclaimer of Validity 1113 This document and the information contained herein are provided on an 1114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1116 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1117 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1118 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1121 Copyright Statement 1123 Copyright (C) The Internet Society (2005). This document is subject 1124 to the rights, licenses and restrictions contained in BCP 78, and 1125 except as set forth therein, the authors retain all their rights. 1127 Acknowledgment 1129 Funding for the RFC Editor function is currently provided by the 1130 Internet Society.