idnits 2.17.1 draft-crocker-stdaddr-02.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-25) 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 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. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 313 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 162: '...there MUST be the administrative mailb...' RFC 2119 keyword, line 174: '...(-REQUEST) MAILBOX NAMES ARE REQUIRED,...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1033-RFC1035' is mentioned on line 145, but not defined == Missing Reference: 'RFC 2068' is mentioned on line 148, but not defined ** Obsolete undefined reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Unknown state RFC: RFC 976 ** Obsolete normative reference: RFC 977 (Obsoleted by RFC 3977) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 -- Duplicate reference: RFC1035, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 1654 (Obsoleted by RFC 1771) ** Obsolete normative reference: RFC 1655 (Obsoleted by RFC 1772) ** Obsolete normative reference: RFC 1656 (Obsoleted by RFC 1773) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP' Summary: 19 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Crocker 2 INTERNET-DRAFT Internet Mail Consortium 3 January, 1997 4 Expire in six months 6 MAILBOX NAMES FOR 7 COMMON SERVICES, ROLES AND FUNCTIONS 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 13 areas, and its working groups. Note that other groups may also 14 distribute 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- 19 Drafts as reference material or to cite them other than as ``work 20 in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.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 This specification enumerates and describes Internet mail 31 addresses (mailbox name @ host reference) to be used when 32 contacting personnel at an organization. Mailbox names are 33 provided for both operations and business functions. Additional 34 mailbox names and aliases are not prohibited, but organizations 35 which support email exchanges with the Internet are encouraged to 36 support AT LEAST each mailbox name for which the associated 37 function exists within the organization. 39 1. RATIONALE AND SCOPE 41 Various Internet documents have specified mailbox names to be 42 used when reaching the operators of the new service; for example, 43 [RFC822 6.3, C.6] requires the presence of a 44 mailbox name on all hosts that have an SMTP server. Other 45 protocols have defacto standards for well known mailbox names, 46 such as for NNTP (see [RFC977]), and 47 for HTTP (see [HTTP]). Defacto standards also 48 exist for well known mailbox names which have nothing to do with 49 a particular protocol, e.g., and . 51 The purpose of this draft is to aggregate and specify the basic 52 set of mailbox names which organizations need to support. Most 53 organizations do not need to support the full set of mailbox 54 names defined here, since not every organization will implement 55 the all of the associated services. However, if a given service 56 is offerred, then the associated mailbox name(es) must be 57 supported, resulting in delivery to a recipient appropriate for 58 the referenced service or role. 60 If a host is not configured to accept mail directly, but it 61 implements a service for which this specification defines a 62 mailbox name, that host must have an MX RR set (see [RFC974]) and 63 the mail exchangers specified by this RR set must recognize the 64 referenced host's domain name as "local" for the purpose of 65 accepting mail bound for the defined mailbox name. Note that 66 this is true even if the advertised domain name is not the same 67 as the host's domain name; for example, if an NNTP server's host 68 name is DATA.RAMONA.VIX.COM yet it advertises the domain name 69 VIX.COM in its ``Path:'' headers, then mail must be deliverable 70 to both and , even 71 though these addresses might be delivered to different final 72 destinations. 74 The scope of a well known mailbox name is its domain name. 75 Servers accepting mail on behalf of a domain must accept and 76 correctly process mailbox names for that domain, even if the 77 server, itself, does not support the associated service. So, for 78 example, if an NNTP server advertises the organization's top 79 level domain in ``Path:'' headers (see [RFC977]) the mail 80 exchangers for that top level domain must accept mail to 81 even if the mail exchanger hosts do not, 82 themselves, serve the NNTP protocol. 84 2. INVARIANTS 86 For well known names that are not related to specific protocols, 87 only the organization's top level domain name are required to be 88 valid. For example, if an Internet service provider's domain 89 name is COMPANY.COM, then the address must be 90 valid and supported, even though the customers whose activity 91 generates complaints use hosts with more specific domain names 92 like SHELL1.COMPANY.COM. Note, however, that it is valid and 93 encouraged to support mailbox names for sub-domains, as 94 appropriate. 96 Mailbox names must be recognized independent of character case. 97 For example, POSTMASTER, postmaster, Postmaster, PostMaster, and 98 even PoStMaStEr are to be treated the same, with delivery to the 99 same mailbox. 101 Implementations of these well known names need to take account of 102 the expectations of the senders who will use them. Sending back 103 an automatic mail acknowledgement is usually helpful (though we 104 suggest caution against the possibility of "duelling mail robots" 105 and the resulting mail loops). 107 3. BUSINESS-RELATED MAILBOX NAMES 109 These names are related to an organization's line-of-business 110 activities. The INFO name is often tied to an autoresponder, 111 with a range of standard files available. 113 MAILBOX AREA USAGE 114 ----------- ---------------- --------------------------- 115 INFO Marketing Packaged information about the 116 organization, products, and/or 117 services, as appropriate 118 MARKETING Marketing Product marketing and 119 marketing communications 120 SALES Sales Product purchase information 121 SUPPORT Customer Service Problems with product or 122 service 124 4. NETWORK OPERATIONS MAILBOX NAMES 126 Operations addresses are intended to provide recourse for 127 customers, providers and others who are experiencing difficulties 128 with the organization's Internet service. 130 MAILBOX AREA USAGE 131 ----------- ---------------- --------------------------- 132 ABUSE Customer Relations Inappropriate public behaviour 133 NOC Network Operations Network infrastructure 134 SECURITY Network Security Security bulletins or queries 136 5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES 138 For major Internet protocol services, there is a mailbox defined 139 for receiving queries and reports. (Synonyms are included, here, 140 due to their extensive installed base.) 142 MAILBOX SERVICE SPECIFICATIONS 143 ----------- ---------------- --------------------------- 144 POSTMASTER SMTP [RFC821], [RFC822] 145 HOSTMASTER DNS [RFC1033-RFC1035] 146 USENET NNTP [RFC977] 147 NEWS NNTP Synonym for USENET 148 WEBMASTER HTTP [RFC 2068] 149 WWW HTTP Synonym for WEBMASTER 150 UUCP UUCP [RFC976] 151 FTP FTP [RFC959] 153 6. MAILING LIST ADMINISTRATION MAILBOX 155 Mailing lists have an administrative mailbox name to which 156 add/drop requests and other meta-queries can be sent. 158 For a mailing list whose submission mailbox name is: 160 162 there MUST be the administrative mailbox name: 164 166 Distribution List management software, such as MajorDomo and 167 Listserv, also have a single mailbox name associated with the 168 software on that system -- usually the name of the software -- 169 rather than a particular list on that system. Use of such 170 mailbox names requires participants to know the type of list 171 software employed at the site. This is problematic. 172 Consequently: 174 LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED, 175 INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE 176 MAILBOX NAMES. 178 7. DOMAIN NAME SERVICE ADMINISTRATION MAILBOX 180 In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of 181 Authority record (SOA RR) has a field for specifying the mailbox 182 name of the zone's administrator. 184 This field must be a simple word without metacharacters (such as 185 ``%'' or ``!'' or ``::''), and a mail alias should be used on the 186 relevant mail exchanger hosts to direct zone administration mail 187 to the appropriate mailbox. 189 For simplicity and regularity, it is strongly recommended that 190 the well known mailbox name HOSTMASTER always be used 191 . 193 8. AUTONOMOUS SYSTEM MAILBOX 195 Several Internet registries implement mailing lists for 196 Autonomous System contacts. So, for example, mail sent to 197 will at the time of this writing reach the 198 technical contact for Autonomous System 3557 in the BGP4 (see 199 [RFC1654], [RFC1655] and [RFC1656]). 201 Not all Autonomous Systems are registered with all registries, 202 however, and so undeliverable mailbox names under this scheme 203 should be treated as an inconvenience rather than as an error or 204 a standards violation. 206 9. SECURITY CONSIDERATIONS 208 Denial of service attacks (flooding a mailbox with junk) will be 209 easier after this document becomes a standard, since more systems 210 will support the same set of mailbox names. 212 10. REFERENCES 214 [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, 215 Information Sciences Institute, 08/01/1982 217 [RFC822] D. Crocker, "Standard for the format of ARPA Internet 218 text messages", RFC 822, University of Delaware, 08/13/1982. 220 [RFC959] J. Postel (et al), "File Transfer Protocol (FTP)", RFC 221 959, Information Sciences Institute, October 1985. 223 [RFC974] C. Partridge, "Mail routing and the domain system", RFC 224 974, CSNET CIC BBN Laboratories Inc, 01/01/1986. 226 [RFC976] M. Horton, "UUCP mail interchange format standard", RFC 227 976, Bell Laboratories, 02/01/1986. 229 [RFC977] B. Kantor (et al), "Network News Transfer Protocol: A 230 Proposed Standard for the Stream-Based Transmission of News", RFC 231 977, University of California, February 1986. 233 [RFC1033] M. Lottor, "Domain administrators operations guide", 234 RFC 1033, SRI International, 11/01/1987. 236 [RFC1034] P. Mockapetris, "Domain names - concepts and 237 facilities", RFC 1035, USC/Information Sciences Institute, 238 11/01/1987. 240 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 241 Specification,'' RFC 1035, USC/Information Sciences Institute, 242 November 1987. 244 [RFC1654] Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP- 245 4)", RFC 1654, T.J. Watson Research Center, IBM Corp., 246 07/21/1994. 248 [RFC1655] Y. Rekhter (et al), "Application of the Border Gateway 249 Protocol in the Internet", RFC 1655, T.J. Watson Research Center, 250 IBM Corp., 07/21/1994. 252 [RFC1656] P. Traina, "BGP-4 Protocol Document Roadmap and 253 Implementation Experience", RFC 1656, cisco Systems, July 1994. 255 [HTTP] T. Berners-Lee (et al), "Hypertext Transfer Protocol -- 256 HTTP/1.0", , February 19, 1996. 258 11. ACKNOWLEDGEMENTS 260 This specification derived from an earlier draft written by Paul 261 Vixie. Thanks to Stan Barber, Michael Dillon, James Aldridge, J. 262 D. Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal 263 McBurnett, and Ed Morin for their comments on that draft. 265 12. AUTHOR'S ADDRESS 267 Dave Crocker 268 Internet Mail Consortium 269 127 Segre Ave. 270 Santa Cruz, CA 272 +1 408 246 8253 273