idnits 2.17.1 draft-hoffman-legis-smtp-banner-01.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 153 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There are 33 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-hoffman-legis-smtp-banner-01.txt Internet Mail Consortium 3 September 10, 1998 John Levine 4 Expires in six months IECC 6 Anti-UBE and Anti-UCE Keywords in SMTP Banners 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its areas, and its working 12 groups. Note that other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months and 16 may be updated, replaced, or obsoleted by other documents at any time. It 17 is inappropriate to use Internet-Drafts as reference material or to cite 18 them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 23 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West 24 Coast). 26 1. Introduction 28 Legislators writing laws that would limit or prohibit the sending of 29 unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have 30 begun to include rules that require mail servers to include particular 31 wording in the SMTP banner. To date, this wording has had two distinct 32 purposes: to warn senders that they may not send UBE or UCE to that SMTP 33 host, and to state the physical location of the host so that the sender may 34 know which laws apply. 36 This document is meant to help clarify how such legislation might be 37 worded, and to help increase interoperability of various laws. It is not 38 meant to be a standard of any kind, but is meant only for its informational 39 value. 41 2. The SMTP Banner 43 SMTP, as defined in [RFC821], is a client-server protocol that runs over 44 TCP/IP. When the SMTP client connects to the SMTP server, the server TCP 45 immediately emits a banner, also called an "opening message" or "connection 46 greeting". The contents of this banner must be in the ASCII character 47 set, and the banner must be no longer than 512 characters, including the 48 response code, separator, and at the end of the banner. 50 The banner normally contains software and version information, and often 51 contains other useful debugging information. Most SMTP server products 52 allow the system administrator to specify the contents of the banner. The 53 banner must start with a three-digit status code followed by a space, but 54 the rest of banner is not specified by any existing standard. 56 3. Rationale for Using the SMTP Banner for Anti-UBE and Anti-UCE Messages 58 There has been some debate about whether or not the SMTP banner is the best 59 place to put notices to UBE senders. 61 The arguments in favor of using the SMTP banner include: 63 - A potential UBE sender uses almost no resources on the part of the SMTP 64 server to find out that UBE is not allowed. 66 - It is very easy to describe in legislation, and thus is most likely to be 67 upheld in courts if challenged. 69 - An SMTP client who wants to send UBE does not need to identify itself 70 before determining if the SMTP server will accept such mail. 72 - It is easy for a mail system administrator to configure and check the 73 SMTP banner. 75 - Existing banners are typically much shorter than 512 characters, so the 76 addition of a short phrase is unlikely to violate any standard limits. 78 The arguments against using the SMTP banner include: 80 - This overloads the semantics of the banner contents. 82 - This could instead be done with an ESMTP extension. 84 4. Suggested Wording for Legislation Restricting UBE and UCE 86 Legislation that requires wording in the SMTP banner to indicate that UBE 87 or UCE is not allowed or is restricted on the server should include the 88 exact phrase used. That phrase should be short, succinct, and must not be 89 required to be in a particular position in the SMTP banner. We recommend 90 the phrase "NO UBE" or "NO UCE", in all uppercase characters. Legislation 91 mandating either phrase should specify that the phrase must be preceded by 92 a non-alphanumeric character, and followed by non-alphanumeric character or 93 the end of the banner. 95 Note that such a phrase will be human-readable, but it is also easily 96 machine-readable if the exact phrase is specified in the legislation. Using 97 such a machine-readable phrase makes it easier for potential UBE senders to 98 avoid problems by having a program check whether or not the mail server 99 accepts UBE before sending the mail. Although the banner phrase should be 100 in uppercase characters, clients should recognize the phrase in any 101 combination of upper- and lowercase characters. 103 It should also be noted that most languages around the world require 104 characters outside the ASCII character set, but these characters must not 105 be used in an SMTP banner. In such cases, the legislation might choose a 106 phrase for the SMTP banner which does not make sense in the native language 107 of the area in question but is unlikely to appear in a banner for other 108 reasons. 110 5. Suggested wording for Legislation Stating Server Location 112 Legislation that requires a server administrator to state the location of 113 the server should use standardized abbreviations for countries and local 114 states or provinces. These locations should be easy to pick out from other 115 information in the SMTP banner. 117 Legislation that requires that the server identify the country that it is 118 in should use "C=" followed by the official two-letter country code defined 119 in [ISO3166]. Legislation that requires the server identify the state or 120 province that it is in should use "L=" followed by an officially-accepted 121 abbreviation (if any) for the state or province name. For instance, in the 122 state of California, such legislation might require the phrase "C=US L=CA" 123 to be included in the banner. (The "C" for country and "L" for location 124 come from the widely-used X.500 directory standard.) 126 6. Security Considerations 128 Forcing a mail server to state its location can possibly cause an attacker 129 to gain valuable information about the server or its characteristics. 131 7. References 133 [RFC821] RFC 821, Simple Mail Transport Protocol. 135 [ISO3166] ISO 3166:1988, Codes for the representation of names of 136 countries. 138 8. Authors' Addresses 140 Paul Hoffman 141 Internet Mail Consortium 142 127 Segre Place 143 Santa Cruz, CA 95060 144 (831) 426-9827 145 phoffman@imc.org 147 John Levine 148 IECC 149 PO Box 727 150 Trumansburg, NY 14886 151 johnl@iecc.com