idnits 2.17.1 draft-varshavchik-verp-smtpext-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 126: '... by the MAIL FROM verb MUST contain at...' RFC 2119 keyword, line 130: '... message MUST contain at least...' RFC 2119 keyword, line 133: '... TO verbs MUST be compliant wit...' RFC 2119 keyword, line 134: '... [6]. That is, it MUST contain only letters, digits, hyphens,...' RFC 2119 keyword, line 141: '...ts, the VERP server MUST do one of the...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Jul 12, 1999) is 9055 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 1425 (ref. '1') (Obsoleted by RFC 1651) ** Obsolete normative reference: RFC 1894 (ref. '2') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (ref. '3') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 821 (ref. '4') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Varshavchik 2 Expires Jan 12, 2000 Double Precision, Inc. 3 Jul 12, 1999 5 Variable Envelope Return Path SMTP Extension 6 draft-varshavchik-verp-smtpext-00.txt 8 Status Of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This document describes an extension to the SMTP service [1], called 33 Variable Envelope Return Path (VERP). The VERP extension implements 34 a way of automatically identifying undeliverable mail recipients, 35 even when non-delivery reports originate from mail systems that do 36 not implement delivery status notifications as specified in [2] and 37 [3]. 39 2. Introduction 41 All E-mail software can expect to deal with undeliverable mail. [2] 42 and [3] implement a way for undeliverable mail to be handled in a 43 completely automatic fashion, without requiring manual intervention. 44 For example, mailing list managers can automatically identify 45 addresses that are no longer deliverable, and remove them from the 46 mailing list. 48 Although [2] and [3] are widely implemented, there are still a lot of 50 VERP SMTP Extension S. Varshavchik Jul 12, 2000 52 systems that do not use them. This translates into a non-trivial 53 amount of manual work, to identify undeliverable addresses and remove 54 them from the mailing list. Even when the percentage of 55 undeliverable addresses starts out rather small, over time they 56 accumulate to the point of requiring manual intervention. 58 VERPs represent an alternative way of handling non-delivery notices. 59 The advantage of VERPs is that they work every time, even when non- 60 delivery notices are not in the form specified by [2]. In a VERP, 61 the recipient address is encoded into a portion of the return path. 62 When undeliverable mail comes back, the mail software decodes the 63 return address and obtains the address responsible for the non- 64 delivery notice. 66 For example, mail sent by a mailing list manager to the address 67 carries a return address of . The mail system for domain.com knows 69 that all mail with the local address starting with "mlist-return-" 70 must go to the mailing list manager. The mailing list manager takes 71 the return address, retrieves the remaining portion of the local 72 address, "john=example.org", and determines that the undeliverable 73 address was . 75 This does not rely on RFC 1894, and will work for all non-delivery 76 notices. 78 Unfortunately, VERPs have a known drawback when used with large 79 mailing lists: an individual copy of each message must be sent to 80 every individual recipient. It is no longer possible to conserve 81 network resources by transmitting only one copy of each message, 82 addressed to every recipient in the same domain (or a couple of 83 messages where the number of recipients in the same domain is very 84 large). A separate message must be sent to every recipient when 85 VERPs are used, because the recipient's address must to be encoded as 86 a part of the return path. 88 This document specifies an SMTP service extension that enables mail 89 systems to exchange message with variable envelope return paths, 90 without transmitting one message per recipient. 92 3. Framework for the VERP SMTP transport extension 94 This SMTP transport extension [1] is laid out as follows. 96 (1) The name of the SMTP transport extension defined here is 97 Variable Envelope Return Path. 99 (2) The EHLO keyword associated with this extension is VERP. 101 VERP SMTP Extension S. Varshavchik Jul 12, 2000 103 (3) The VERP EHLO keyword takes no parameters. 105 (4) One optional ESMTP keyword VERP is associated with the MAIL 106 FROM command. This parameter takes no values. 108 (5) No additional ESMTP verbs are defined by this extension. 110 (6) The next section specifies how support for this extension 111 affects the behavior of a server and client SMTP. 113 4. The VERP SMTP extension 115 When a VERP keyword is present in the MAIL FROM command, [4], 116 additional restrictions are imposed on the RFC 822 address [5], 117 specified by that MAIL FROM command, and on all RFC 822 addresses in 118 the subsequent RCPT TO commands that refer to the same message (that 119 is, until the next DATA, RSET, or QUIT command). The term "VERP 120 message" refers to any E-mail message whose MAIL FROM command 121 includes the VERP keyword. The term "VERP-compliant server" refers 122 to any E-mail server that supports the Variable Envelope Return Path 123 SMTP extension. When a VERP keyword is present in the MAIL FROM 124 command: 126 (1) The address specified by the MAIL FROM verb MUST contain at 127 least one @ character. 129 (2) The address in every RCPT TO verb referring to the same 130 message MUST contain at least one @ character. 132 (3) The domain portion of the address in the MAIL FROM and RCPT 133 TO verbs MUST be compliant with the definition of in 134 [6]. That is, it MUST contain only letters, digits, hyphens, 135 and periods. The domain portion is the portion of the 136 address that follows the last @ character, 138 4.1 Delivery failures 140 When a VERP-compliant server is unable to deliver a VERP message to 141 one or more of its recipients, the VERP server MUST do one of the 142 following: 144 1) Return an RFC 1891 delivery status notification to the return 145 address, or: 147 2) Transmit a separate non-delivery notice for each failed 148 recipient. The return address for each non-delivery notice 149 MUST be the address that's formed by applying the procedure 150 described in section 7 of this document to the return address 152 VERP SMTP Extension S. Varshavchik Jul 12, 2000 154 of the message and the failed recipient's address. If more 155 than one recipient failed, a separate notice MUST be sent for 156 each undeliverable address. 158 5. Final delivery 160 A VERP-compliant server may have locally-defined conventions which 161 records the return address in each message, for informational 162 purposes. 164 If this is the case, the recorded return address MUST be formed by 165 applying the procedure described in section 7 of this document to the 166 return address and the recipient's address. 168 6. Relaying 170 When a VERP-compliant server determines that a recipient of a VERP 171 message is not a local mailbox, and the message must be relayed to 172 another server, the VERP-compliant server MUST: 174 (1) If the VERP-compliant server's local policies require the 175 return and/or recipient addresses to be rewritten, any 176 rewritten addresses MUST have at least one @ character. 178 (2) If the VERP-compliant server determines that the remote 179 server is also a VERP compliant server, the VERP keyword MUST 180 be included in the MAIL FROM command used to relay the VERP 181 message to the remote server. 183 (3) If the remote server is not a VERP compliant server, The VERP 184 compliant server SHOULD send a separate copy of the VERP 185 message for every recipient, and the return address of each 186 message MUST be formed by applying the procedure described in 187 section 7 of this document to the original return address, 188 and the address of each recipient. Alternatively, the 189 message SHOULD NOT be returned as undeliverable. If it is, 190 the rules defined in section 4.1 MUST be applied. 192 This also applies if the SMTP-compliant server determines 193 that the VERP message is to be forwarded via some other 194 protocol to a non-SMTP gateway, unless the non-SMTP protocol 195 has equivalent features that are completely identical in 196 function to Variable Envelope Return Path SMTP service 197 extension (including any translations of E-mail addresses to 198 and from the non-RFC822 format). 200 This SMTP service extensions allows E-mail software to send a single 201 VERP message to all addresses the same mail domain, as long as all 203 VERP SMTP Extension S. Varshavchik Jul 12, 2000 205 mail servers used to deliver the message support the Variable 206 Envelope Return Path SMTP extension. When a VERP message reaches a 207 non VERP-compliant server, a separate message with a variable 208 envelope return path is generated for each recipient. 210 7. Variable envelope return path encoding 212 This encoding method starts with one return address and one recipient 213 address. As mentioned previously, both addresses MUST be valid 214 RFC822 addresses, [5], and MUST contain at least one @ character. 215 The portion of each address following the last @ character MUST be 216 compliant with [6]. 218 Let "sdomain" represent the portion of the return address that 219 follows the last @ character. 221 Let "slocal" represent the portion of the return address that 222 precedes the last @ character. 224 Let "rdomain" represent the portion of the recipient address that 225 follows the last @ character. 227 Let "rlocal" represent the portion of the recipient address that 228 precedes the last @ character. 230 To encode the recipient address within the envelope sender address, 231 create an address of the following form: 233 slocal-encodedrlocal=rdomain@sdomain 235 Where "encodedrlocal" is formed by taking rlocal and encoding it as 236 follows: 238 1) Each @, :, %, !, and + character in rlocal is replaced by a 239 single '+' character followed by two uppercase hexadecimal 240 characters whose value is the ASCII code of the replaced 241 character. 243 2) All other characters are unchanged. Other characters MAY, 244 but SHOULD NOT be also encoded in the same fashion. 246 This can be represented using BNF as follows: 248 encodedverp: slocal "-" encodedrlocal "=" rdomain "@" sdomain 250 encodedrlocal: * (char-literal / char-encoded ) 252 char-literal: any character valid in an RFC822 address [5], 254 VERP SMTP Extension S. Varshavchik Jul 12, 2000 256 except @, :, %, !, and + 258 char-encoded: "+" hexdigit hexdigit 260 hexdigit: ("0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 261 "9" / "A" / "B" / "C" / "D" / "E" / "F" ) 263 8. Variable envelope return path decoding 265 Non-delivery notices for VERP messages will be sent to either the 266 original address, , or to the VERP-encoded address, 267 . 269 Messages sent to will be RFC 1891-compliant delivery 270 status notifications. These messages will be machine-readable, and 271 the mail software will be able to identify failed addresses from the 272 RFC 1891 delivery report. Non-delivery notices will also be sent to 273 the VERP-encoded address, and the mail software will be able to 274 reconstruct the failed address from the VERP-encoded address by 275 simply reversing the steps used in encoding: 277 1) Extracting encodedrlocal and rdomain from the recipient 278 address. There will be at least one = character in the 279 encoded portion of the return address. encodedrlocal is 280 everything up to the last = character. Everything following 281 the last = character is rdomain. 283 2) Replacing all occurrences of "+" followed by two hexadecimal 284 digits in encodedrlocal with the equivalent ASCII character. 286 3) Using the decoded rlocal, @, then rdomain. 288 9. Examples 290 Suppose that a VERP-compliant server named "example.com" receives a 291 message with the following SMTP conversation (for brevity, non- 292 relevant headers have been omitted): 294 250 example.com ESMTP 295 EHLO domain.com 296 250-example.com ESMTP 297 250-SIZE 298 250-DSN 299 250-VERP 300 250 HELP 301 MAIL FROM: VERP SIZE=100 302 250 Ok 303 RCPT TO: 305 VERP SMTP Extension S. Varshavchik Jul 12, 2000 307 250 Ok 308 RCPT TO: 309 250 Ok 310 RCPT TO: 311 250 Ok 312 RCPT TO: 313 250 Ok 314 RCPT TO: 315 250 Ok 316 DATA 317 250 Ok 318 From: "John" 319 Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) 320 Subject: Meeting canceled. 322 Today's 2pm meeting has been rescheduled for tomorrow, 9am, due 323 to a scheduling conflict. 324 . 326 The message is delivered to the local mailbox for . 327 The message looks like this: 329 Return-Path: 330 From: "John" 331 Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) 332 Subject: Meeting canceled. 334 Today's 2pm meeting has been rescheduled for tomorrow, 9am, due 335 to a scheduling conflict. 337 The VERP-compliant server at example.com connects to the mail server 338 for old.example.com. old.example.com does not support the Variable 339 Envelope Return Path extension. Therefore, old.example.com receives 340 two messages. The SMTP conversation for the first message is as 341 follows: 343 250 old.example.com ESMTP 344 EHLO example.com 345 250-old.example.com ESMTP 346 250-SIZE 347 250-DSN 348 250 HELP 349 MAIL FROM: 350 250 Ok 351 RCPT TO: 352 250 Ok 353 DATA 354 250 Ok 356 VERP SMTP Extension S. Varshavchik Jul 12, 2000 358 From: "John" 359 Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) 360 Subject: Meeting canceled. 362 Today's 2pm meeting has been rescheduled for tomorrow, 9am, due 363 to a scheduling conflict. 364 . 366 The SMTP conversation for the second message is as follows: 368 MAIL FROM: 369 250 Ok 370 RCPT TO: 371 250 Ok 372 DATA 373 250 Ok 374 From: "John" 375 Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) 376 Subject: Meeting canceled. 378 Today's 2pm meeting has been rescheduled for tomorrow, 9am, due 379 to a scheduling conflict. 380 . 382 example.com connects to new.example.com and determines that 383 new.example.com runs a modern ESMTP server that supports the VERP 384 keyword. The SMTP conversation then goes like this: 386 250 new.example.com ESMTP 387 EHLO example.com 388 250-new.example.com ESMTP 389 250-SIZE 390 250-DSN 391 250-VERP 392 250 HELP 393 MAIL FROM: VERP SIZE=100 394 250 Ok 395 RCPT TO: 396 250 Ok 397 RCPT TO: 398 250 Ok 399 DATA 400 250 Ok 401 From: "John" 402 Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST) 403 Subject: Meeting canceled. 405 Today's 2pm meeting has been rescheduled for tomorrow, 9am, due 407 VERP SMTP Extension S. Varshavchik Jul 12, 2000 409 to a scheduling conflict. 410 . 412 10. Security concerns 414 All the usual security considerations applicable to SMTP are also 415 applicable to this extension. Relay of VERP messages to non-VERP 416 servers requires a single message with many recipients to be exploded 417 into many messages with one recipient. In all cases, however, there 418 will never be any additional overhead beyond the resources that are 419 required when variable envelope return paths are manually implemented 420 by the mail sender, instead of using the VERP SMTP extension. 422 Mail systems which support the VERP extension SHOULD have adequate 423 security measures, including blocks against unauthorized access and 424 relaying. 426 VERP SMTP Extension S. Varshavchik Jul 12, 2000 428 11. References 430 [1] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. 431 "SMTP Service Extensions", RFC 1425, United Nations 432 University, Innosoft International, Inc., Dover Beach 433 Consulting, Inc., Network Management Associates, Inc., The 434 Branch Office, February 1993 436 [2] Moore, K., and G. Vaudreuil, "An Extensible Message Format 437 for Delivery Status Notifications", RFC 1894, University of 438 Tennessee, Octel Network Services, January 1996. 440 [3] Moore, K. "SMTP Service Extension for Delivery Status 441 Notifications", RFC 1891, University of Tennessee, January 442 1996. 444 [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 445 USC/Information Sciences Institute, August 1982. 447 [5] Crocker, D., "Standard for the Format of ARPA Internet Text 448 Messages", STD 11, RFC 822, UDEL, August 1982. 450 [6] Mockapetris, P., "Domain Names - Implementation and 451 Specification", RFC 1035, ISI, November 1987 453 12. Author's address 455 Sam Varshavchik 456 Double Precision, Inc. 457 PO Box 668 458 Greenwood Lake, NY 10925 459