idnits 2.17.1 draft-newman-email-subaddr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Introduction 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 100: '... the local part of the address MUST be...' RFC 2119 keyword, line 105: '...ubaddress aware MUAs MUST NOT generate...' RFC 2119 keyword, line 107: '... delivery agents MAY refuse to apply s...' RFC 2119 keyword, line 160: '... primary address MUST be delivered to ...' RFC 2119 keyword, line 162: '... The subaddress MAY be used to route ...' (11 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 (July 1997) is 9782 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) == Missing Reference: 'KEYWORDS' is mentioned on line 48, but not defined == Unused Reference: 'IMAP4' is defined on line 221, but no explicit reference was found in the text -- No information found for draft-ietf-drums-abnf-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Internet Email Subaddressing Innosoft 4 Document: draft-newman-email-subaddr-00.txt July 1997 5 Expires in six months 7 Internet Email Subaddressing 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 It is often useful for a single user to have multiple email 31 addresses which can be used to assist categorizing incoming email. 32 One way of doing this is to divide the local-part of an email 33 address into a primary address and a subaddress. The primary 34 address is used to route the message within the specified domain 35 and the subaddress is used to route the message according to a 36 particular user's wishes. 38 This specification formalizes the de-facto standard for 39 subaddressing in use today and includes advice and requirements for 40 final delivery agents, MUAs and mail list servers which wish to 41 support subaddressing. 43 1. Conventions Used in this Document 45 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 46 in this document are to be interpreted as defined in "Key words for 47 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 49 The formal grammar in this document uses Augmented BNF [ABNF]. 51 2. Definitions 53 Final Delivery Agent 54 The final delivery agent is the agent started by the Final MTA 55 which interprets the local-part of the email address. 57 Final MTA 58 The final MTA is the MTA designated by the domain to the left 59 of the "@" in an email address. 61 Local-Part 62 The local-part of an email address is everything to the left 63 of the "@" in the address used for delivery and is formally 64 defined in [IMAIL]. It is also know as the "left hand side" 65 of an address. 67 Mail List Server 68 A Mail List Server takes messages directed to it, rewrites the 69 envelope addresses and redistributes the message to one or 70 more subscribers. 72 MTA A Mail Transport Agent (MTA) receives email from other MTAs or 73 MUAs and routes it towards the final MTA. 75 MUA A Mail User Agent (MUA) is used by a user to send and read 76 email. 78 Subaddress 79 A subaddress is information in addition to the address of a 80 primary mailbox which may be used for categorization by the 81 recipient. 83 3. Subaddress Syntax 85 A final delivery agent may divide the local-part into two pieces 86 separated by a "+". The primary address is to the left of the "+" 87 and the subaddress is to the right of the "+". A message with a 88 valid primary address is delivered to that primary address by 89 default, regardless of the contents of the subaddress. The 90 subaddress may be used by final delivery filtering (e.g. to deliver 91 messages with a particular subaddress into a special folder) or by 92 an MUA. 94 For example, an address could be 95 used to send email to relating to grey- 96 council business. Delenn can then direct her final delivery agent 97 to file messages with a "grey-council" subaddress into her "grey- 98 council" folder. 100 When generating a subaddress, the local part of the address MUST be 101 canonically quoted. A local part is canonically quoted if it is 102 legal according to both the formal grammer in [IMAIL] and the 103 formal grammar in [SMTP]. The following formal grammar restricts 104 in this fashion and distinguishes the primary address 105 from the subaddress. Subaddress aware MUAs MUST NOT generate 106 addresses which violate this syntax and subaddress aware final 107 delivery agents MAY refuse to apply subaddress interpretation to 108 addresses which violate this syntax. 110 local-part = local-quoted / local-unquoted 112 local-quoted = <"> primary-q ["+" subaddress-q] <"> 114 local-unquoted = [primary-c] ["+" [subaddress-c]] 116 primary = *(SAFEQ-CHAR / QUOTE-CHAR) 117 ;; This is the syntax for an unquoted primary 118 ;; address. If it fits canonical form (primary-c) 119 ;; it is used directly in a local-part. Otherwise 120 ;; QUOTE-CHARs are escaped to fit quoted form. 122 primary-c = primc-word *("." primc-word) 124 primary-q = *(SAFEQ-CHAR / quoted) 126 primc-word = 1*SAFE-CHAR 128 quoted = "\" QUOTE-CHAR 130 subaddress = *(SAFEQ-CHAR / QUOTE-CHAR / "+") 131 ;; This is the syntax for an unquoted subaddress. 132 ;; If it fits canonical form (subaddress-c) it is 133 ;; used directly in a local-part. Otherwise 134 ;; QUOTE-CHARs are escaped to fit quoted form. 136 subaddress-c = subc-word *("." subc-word) 138 subaddress-q = *(SAFEQ-CHAR / "+" / quoted) 140 subc-word = 1*(SAFE-CHAR / "+") 141 QUOTE-CHAR = <"> / "\" 143 SAFE-CHAR = %21 / %23..27 / %2A / %2D / %2F..39 / %3D / 144 %3F / %41..5A / %5E..7E 145 ;; All printable US-ASCII characters except 146 ;; space, plus "+" and as defined 147 ;; in [IMAIL] 149 SAFEQ-CHAR = %20..21 / %23..2A / %2C..5B / %5D..7E 150 ;; All printable US-ASCII characters except 151 ;; plus "+", quote <"> and backslash "\" 153 4. Subaddress Support Requirements 155 This section defines the requirements for subaddress aware final 156 delivery agents, gateway/firewalls, MUAs and mail list servers. 158 4.1. Final Delivery Agent Requirements 160 A message with a valid primary address MUST be delivered to that 161 primary address by default, regardless of the contents of the 162 subaddress. The subaddress MAY be used to route the message 163 according to rules specified by the owner of that primary address. 165 4.2. Gateway/Firewall Requirements 167 A subaddress aware gateway or firewall SHOULD preserve the 168 subaddress when rewriting an address. A subaddress aware gateway 169 MAY rewrite an address into canonical quoted form. 171 4.3. MUA Requirements 173 A subaddress aware MUA MUST allow the user to include a subaddress 174 in the From header when sending a message. A subaddress aware MUA 175 MUST generate addresses in canonically quoted form following the 176 syntax for local-part in this specification. A subaddress aware 177 MUA SHOULD allow the user to include a subaddress in the envelope 178 sender address (as used in the SMTP MAIL FROM command). A 179 subaddress aware MUA which validates local addresses MUST ignore 180 subaddresses for the purposes of such validation. 182 4.4. Mail List Server Requirements 184 A subaddress aware mail list server MUST allow users to subscribe 185 using a subaddress. If such a server restricts postings by their 186 envelope sender, sender or from address, it MUST ignore 187 subaddresses for the purposes of such restrictions. 189 5. Security Considerations 191 If a final delivery agent executes a command line containing the 192 delivery address and the subaddress contains meta-characters with 193 special meaning to the command line interpretor this could result 194 in a serious security violation. In order to avoid this problem, 195 the final delivery agent MUST verify the subaddress contains no 196 characters with special meaning to the command line interpretor, 197 not use a command line interpretor, or strip the subaddress from 198 the address prior to generating the command line when it contains 199 characters with special meaning. 201 If a final delivery agent were to automatically create a folder 202 based on the subaddress, this could result in a denial of service 203 problem as well as placing control of a user's folder namespace in 204 the hands of outsiders. In order to avoid this problem, final 205 delivery agents MUST NOT automatically create new folders based on 206 the subaddress without explicit permission from the owner of the 207 primary address. Final delivery agents SHOULD NOT automatically 208 file a message into a folder based on the subaddress without 209 explicit permission from the owner of the primary address. 211 6. References 213 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: 214 ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt 216 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 217 Messages", RFC 822, University of Delaware, August 1982. 219 221 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 222 4rev1", RFC 2060, University of Washington, December 1996. 224 226 [MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles 227 and Functions", RFC 2142, Internet Mail Consortium, May 1997. 229 231 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, 232 Information Sciences Institute, August 1982. 234 236 7. Author's Address 238 Chris Newman 239 Innosoft International, Inc. 240 1050 Lakes Drive 241 West Covina, CA 91790 USA 243 Email: chris.newman@innosoft.com 245 Appendix A. Subaddress Scenarios 247 This appendix includes examples of how subaddresses are used on the 248 Internet today. 250 A.1. Subscribe to Mailing List by Subaddress 252 Many users (including the author of this specification) subscribe 253 to mailing lists using a subaddress and use the final delivery 254 agent to file all messages from that mailing list into a different 255 incoming folder based on the subaddress. This sorts mailing list 256 traffic into appropriate folders with 100% accuracy and without 257 scanning the contents of the message headers. 259 A.2. User Controlled Distribution Lists 261 Some final delivery agents allow a user to set up a distribution 262 list and associate it with a particular subaddress. This permits 263 users to manage their own distribution lists without administrative 264 intervention. 266 A.3. Mailto URL Indicator 268 By including a different subaddress for each mailto URL on a web 269 page, a user can determine which mailto URL was selected for a 270 particular message. 272 A.4. Support for Special Addresses 274 A user may forward mail from special purpose addresses, such as 275 those described in [MBOX-NAMES] to a subaddress of their primary 276 account. This avoids the need to login as multiple users while 277 still keeping the mail separated. 279 A.5. Priority Categorization 281 A user may advertise different subaddresses to different audiences 282 and prioritize reading them appropriately. For example, one of the 283 current esteemed area directors uses an "iesg" subaddress to 284 prioritize IESG traffic separately from regular email.