idnits 2.17.1 draft-newman-email-subaddr-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 16, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-09 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft Isode Limited 4 Intended status: Informational November 16, 2007 5 Expires: May 19, 2008 7 Internet Email Subaddressing 8 draft-newman-email-subaddr-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 It is often useful for a single user to have multiple email addresses 42 which can be used to assist categorizing incoming email. One way of 43 doing this is to divide the local-part of an email address into user 44 and detail parts. The user part is used to route the message within 45 the specified domain and the detail part is used to route the message 46 according to a particular user's wishes. 48 This specification formalizes the de-facto standard for subaddressing 49 in use today and includes advice and requirements for final delivery 50 agents, MUAs and mail list servers which wish to support 51 subaddressing. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Subaddressing Syntax . . . . . . . . . . . . . . . . . . . . . 4 59 4. Subaddress Support Requirements . . . . . . . . . . . . . . . 7 60 4.1. Final Delivery Agent Requirements . . . . . . . . . . . . 7 61 4.2. Gateway/Firewall Requirements . . . . . . . . . . . . . . 7 62 4.3. MUA Requirements . . . . . . . . . . . . . . . . . . . . . 7 63 4.4. Mailing List Server Requirements . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Appendix A. Subaddressing Scenarios . . . . . . . . . . . . . . . 9 70 A.1. Subscribe to Mailing List by Detailed Address . . . . . . 9 71 A.2. User Controlled Distribution Lists . . . . . . . . . . . . 9 72 A.3. Mailto URL Indicator . . . . . . . . . . . . . . . . . . . 10 73 A.4. Support for Special Addresses . . . . . . . . . . . . . . 10 74 A.5. Priority Categorization . . . . . . . . . . . . . . . . . 10 75 A.6. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 10 76 Appendix B. Open Issues and Discussion . . . . . . . . . . . . . 10 77 B.1. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Intellectual Property and Copyright Statements . . . . . . . . . . 12 81 1. Introduction 83 Subaddressing is a common technique for providing users with multiple 84 addresses which can be used for filtering incoming email. A key 85 feature is that no administrative action is required to provision or 86 enable a particular detail part; instead, as long as the domain's 87 mail system is subaddress-aware, the user may use arbitrary detail 88 parts. 90 Although commonly deployed, subaddressing has had minimal formal 91 documentation; this document attempts to define subaddressing, and 92 also define what it means to be subaddress-aware. 94 In general, deployed forms of subaddressing divide the local-part of 95 an email address into two strings, seperated by a delimiter 96 character. This is most commonly a plus sign, "+". 98 This document does not document all forms of subaddressing, merely 99 the most common form, also known as "plus-addressing". Other forms 100 are also deployed, sometimes using a minus sign, and in some rare 101 cases using encoding rules rather than simple catenation. 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORDS]. 109 The formal grammar in this document uses Augmented BNF [ABNF]. 111 2. Definitions 113 Final Delivery Agent 114 The final delivery agent is the agent started by the Final MTA 115 which interprets the local-part of the email address. 117 Final MTA 118 The final MTA is the MTA designated by the domain to the left of 119 the "@" in an email address. 121 Local-Part 122 The local-part of an email address is everything to the left of 123 the "@" in the address used for delivery and is formally defined 124 in [IMAIL]. It is also know as the "left hand side" of an 125 address. 127 Mail List Server 128 A Mail List Server takes messages directed to it, rewrites the 129 envelope addresses and redistributes the message to one or more 130 subscribers. 132 MTA 133 A Mail Transport Agent (MTA) receives email from other MTAs or 134 MUAs and routes it towards the final MTA. 136 MUA 137 A Mail User Agent (MUA) is used by a user to send and read email. 139 Detail Part 140 A detail part is information in addition to the address of a 141 primary mailbox which may be used for categorization by the 142 recipient. It is also known as a subaddress. 144 User Part 145 A user part is that portion of the local part which indicates the 146 primary mailbox. In a mail system which is not subaddress-aware, 147 the user part is equal to the local part. 149 Detailed Address 150 An email address which has a detail part. 152 Primary Address 153 An email address which has no detail part, or the corresponding 154 address to a detailed address with the detail part removed. 156 3. Subaddressing Syntax 158 A subaddress-aware final delivery agent divides the local-part into 159 two pieces separated by a "+". The user part is to the left of the 160 "+" and the detail part is to the right of the "+". A message with a 161 valid user part is delivered to the primary address by default, 162 regardless of the contents of the detail part. The detail part MAY 163 be used by final delivery filtering (e.g. to deliver messages with a 164 particular detail part into a special mailbox) or by an MUA. 166 For example, the detailed address 167 might be used to send 168 email to relating to grey-council 169 business. Delenn can then direct her final delivery agent to file 170 messages with a "grey-council" subaddress into her "grey-council" 171 mailbox, perhaps with the [SIEVE-SUBADDRESS] extension. 173 When generating a detailed address, the local part of the address 174 MUST be canonically quoted. A local part is canonically quoted if it 175 is legal according to both the formal grammer in [IMAIL] and the 176 formal grammar in [SMTP]. The following formal grammar restricts 177 in this fashion and distinguishes the user part from the 178 detail part. Subaddress-aware MUAs MUST NOT generate addresses which 179 violate this syntax and subaddress-aware final delivery agents MAY 180 refuse to apply subaddress interpretation to addresses which violate 181 this syntax. 183 local-part = local-quoted / local-unquoted 185 local-quoted = DQUOTE user-part-q ["+" detail-q] DQUOTE 187 local-unquoted = [user-part-c] ["+" [detail-c]] 189 user-part = *(SAFEQ-CHAR / QUOTE-CHAR) 190 ;; This is the syntax for an unquoted user-part 191 ;; address. If it fits canonical form (user-part-c) 192 ;; it is used directly in a local-part. Otherwise 193 ;; QUOTE-CHARs are escaped to fit quoted form. 195 user-part-c = userc-word *("." userc-word) 197 user-part-q = *(SAFEQ-CHAR / quoted) 199 userc-word = 1*SAFE-CHAR 201 quoted = "\" QUOTE-CHAR 203 detail-part = *(SAFEQ-CHAR / QUOTE-CHAR / "+") 204 ;; This is the syntax for an unquoted subaddress. 205 ;; If it fits canonical form (subaddress-c) it is 206 ;; used directly in a local-part. Otherwise 207 ;; QUOTE-CHARs are escaped to fit quoted form. 209 detail-c = detailc-word *("." detailc-word) 211 detail-q = *(SAFEQ-CHAR / "+" / quoted) 213 detailc-word = 1*(SAFE-CHAR / "+") 215 QUOTE-CHAR = DQUOTE / "\" 217 SAFE-CHAR = %x21 / %x23-27 / %x2A / %x2D / %x2F-39 / %x3D / 218 %x3F / %x41-5A / %x5E-7E 219 ;; All printable US-ASCII characters except 220 ;; space, plus "+" and as defined 221 ;; in [IMAIL] 223 SAFEQ-CHAR = %x20-21 / %x23-2A / %x2C-5B / %x5D-7E 224 ;; All printable US-ASCII characters except 225 ;; plus, quote and backslash. 227 4. Subaddress Support Requirements 229 This section defines the requirements for subaddress aware final 230 delivery agents, gateway/firewalls, MUAs and mail list servers. 232 4.1. Final Delivery Agent Requirements 234 By default, delivery to a detailed address MUST be identical to 235 delivery to the primary address. Configuration MAY be used to 236 override behaviour for specific detailed addresses. 238 If [SIEVE] is supported by the delivery agent, then 239 [SIEVE-SUBADDRESS] MUST be supported. 241 4.2. Gateway/Firewall Requirements 243 A subaddress-aware gateway or firewall SHOULD preserve the detail 244 part when rewriting an address. A subaddress aware gateway MAY 245 rewrite an address into canonical quoted form. 247 4.3. MUA Requirements 249 A subaddress-aware MUA MUST allow the user to include a detail part 250 in the From header when sending a message. A subaddress-aware MUA 251 MUST generate addresses in canonically quoted form following the 252 syntax for local-part in this specification. A subaddress-aware MUA 253 SHOULD allow the user to user a detailed address as the envelope 254 sender address (as used in the SMTP MAIL FROM command). A 255 subaddress-aware MUA which validates local addresses MUST ignore 256 detail parts for the purposes of such validation. 258 4.4. Mailing List Server Requirements 260 A subaddress-aware mailing list server MUST allow users to subscribe 261 using a detailed address. If such a server restricts postings by 262 their envelope sender, Sender or From address, it MUST be able to be 263 configured, by the subscriber, to ignore detail parts for the 264 purposes of such restrictions. 266 Mailing list servers SHOULD provide a per-user configuration setting 267 to allow for alternate delimiters, such as "-". 269 5. Security Considerations 271 If a final delivery agent executes a command line containing the 272 delivery address and the detail part contains meta-characters with 273 special meaning to the command line interpretor this could result in 274 a serious security violation. In order to avoid this problem, the 275 final delivery agent MUST verify the detail part contains no 276 characters with special meaning to the command line interpretor, not 277 use a command line interpretor, or strip the detail part from the 278 address prior to generating the command line when it contains 279 characters with special meaning. 281 If a final delivery agent were to automatically create a mailbox 282 based on the detail part, this could result in a denial of service 283 problem as well as placing control of a user's mailbox namespace in 284 the hands of outsiders. In order to avoid this problem, final 285 delivery agents MUST NOT automatically create new mailboxes based on 286 the detail part without explicit permission from the owner of the 287 primary address. Final delivery agents SHOULD NOT automatically file 288 a message into a mailbox based on the subaddress without explicit 289 configuration from the owner of the primary address. 291 Detailed addresses themselves may be used as a weak form of 292 authorization token, for example in the scenario given in 293 Appendix A.6. In such cases, acquisition of the token by a third 294 party may aid in fraud. Therefore such subaddresses MUST be random, 295 and MUST NOT be disclosed. 297 6. Acknowledgements 299 This draft is a direct ancestor of a 1997 draft by Chris Newman. 300 Some usages documented herein may reflect this long heritage, however 301 it has been updated with current usages, including the use of 302 subaddressing as an anti-phishing technique described by John Klensin 303 on the IETF mailing list. No existing usages had fallen out of 304 fashion in the intervening decade. 306 Discussions within the SIEVE working group also influenced the 307 changes to the draft - in particular, the terminology has been 308 changed to match that of [SIEVE-SUBADDRESS]. 310 7. References 312 7.1. Normative References 314 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 315 Specifications: ABNF", RFC 4234, October 2005. 317 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, 318 April 2001. 320 [KEYWORDS] 321 Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 325 Language", draft-ietf-sieve-3028bis-13 (work in progress), 326 October 2007. 328 [SIEVE-SUBADDRESS] 329 Murchison, K., "Sieve Email Filtering -- Subaddress 330 Extension", draft-ietf-sieve-rfc3598bis-05 (work in 331 progress), June 2006. 333 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 334 April 2001. 336 7.2. Informative References 338 [MAIL-ARCH] 339 Crocker, D., "Internet Mail Architecture", 340 draft-crocker-email-arch-09 (work in progress), May 2007. 342 [MBOX-NAMES] 343 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 344 FUNCTIONS", RFC 2142, May 1997. 346 [MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 347 Mapping between X.400 and RFC 822/MIME", RFC 2156, 348 January 1998. 350 Appendix A. Subaddressing Scenarios 352 This appendix includes examples of how subaddressing used on the 353 Internet today. 355 A.1. Subscribe to Mailing List by Detailed Address 357 Many users subscribe to mailing lists using a detailed address and 358 use the final delivery agent to file all messages from that mailing 359 list into a different incoming mailbox based on the detail part. 360 This sorts mailing list traffic into appropriate mailboxes with 100% 361 accuracy and without scanning the contents of the message headers. 363 A.2. User Controlled Distribution Lists 365 Some final delivery agents allow a user to set up a distribution list 366 and associate it with a particular detailed address. This permits 367 users to manage their own distribution lists without administrative 368 intervention. 370 A.3. Mailto URL Indicator 372 By including a different detail part for each mailto URL on a web 373 page, a user can determine which mailto URL was selected for a 374 particular message. 376 A.4. Support for Special Addresses 378 A user may forward mail from special purpose addresses, such as those 379 described in [MBOX-NAMES] to a subaddress of their primary account. 380 This avoids the need to login as multiple users while still keeping 381 the mail separated. 383 A.5. Priority Categorization 385 A user may advertise different detailed addresses to different 386 audiences and prioritize reading them appropriately. For example, 387 one of the current esteemed area directors uses an "ietf" detail part 388 to prioritize IETF traffic separately from regular email. 390 A.6. Anti-Phishing 392 If a user provides their bank with a unique detailed address, then 393 any messages arriving either to the primary address or to a different 394 detailed address are more easily detirmined to be fraudulent, and can 395 be easily filtered out. 397 This effectively uses the detailed address as a weak authorization 398 token, so it is advisable to choose a random or unusual detail part. 400 Appendix B. Open Issues and Discussion 402 This section will hopefully be empty prior to publication as an RFC. 404 The author is aware of two main areas of contention which stalled the 405 original document. Firstly, the choice of subaddress delimiter 406 character is not universal, nor even the choice of having one at all. 407 Unfortunately, a choice must be made for interoperability, therefore 408 the plus character remains specified by this document, being the most 409 common case. 411 Secondly, the recommendation in Section 4.4 effectively means that 412 mailing list management software is encouraged into interpreting the 413 local-part of addresses in foreign domains. This recommendation has 414 been reduced in this version - to requiring that the ability be 415 present, and possible to configure by the subscriber. It is the 416 author's assertion that modern mailing list management software is 417 typically able to be configured by the subscriber in many ways 418 already, so this ought to settle contention. 420 B.1. To-do 422 This is likely to break [MIXER] - either a solution or advice will be 423 needed here. 425 Need to switch to and use terminology within [MAIL-ARCH], rather than 426 defining potentially clashing terminology. 428 Author's Address 430 Dave Cridland 431 Isode Limited 432 5 Castle Business Village 433 36, Station Road 434 Hampton, Middlesex TW12 2BX 435 GB 437 Email: dave.cridland@isode.com 439 Full Copyright Statement 441 Copyright (C) The IETF Trust (2007). 443 This document is subject to the rights, licenses and restrictions 444 contained in BCP 78, and except as set forth therein, the authors 445 retain all their rights. 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 450 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 451 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 452 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Intellectual Property 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 Acknowledgment 481 Funding for the RFC Editor function is provided by the IETF 482 Administrative Support Activity (IASA).