idnits 2.17.1 draft-murchison-lmtp-ignorequota-02.txt: -(114): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 5 instances of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (10 June 2002) is 7990 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) ** Downref: Normative reference to an Informational RFC: RFC 2033 (ref. 'LMTP') ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2554 (ref. 'SMTPAUTH') (Obsoleted by RFC 4954) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft K. Murchison 3 Document: draft-murchison-lmtp-ignorequota-02.txt L. Greenfield 4 Expires December 15, 2002 10 June 2002 6 LMTP Service Extension for Ignoring Recipient Quotas 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. 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 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. 29 Abstract 31 This memo defines an extension to the LMTP service whereby a client 32 may ask the server to ignore a recipient's quotas when delivering a 33 message. 35 Conventions Used in the Document 37 In examples, "C:" and "S:" indicate lines sent by the client and 38 server respectively. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [KEYWORDS]. 44 0. Meta-information on this draft 46 This information is intended to facilitate discussion. It will be 47 removed when this document leaves the Internet-Draft stage. 49 0.1. Discussion 51 This draft is intended to be an extension to the Local Mail Transfer 52 Protocol, available from the RFC repository as 53 . A revised version of this 54 draft document will be submitted to the RFC editor as Informational 55 for the Internet Community. 57 This draft and the Local Mail Protocol Extension itself are being 58 discussed on the SMTP Extensions mailing list at . 59 Subscription requests can be sent to 60 (send an email message with the word "subscribe" in the body). More 61 information on the mailing list along with a WWW archive of back 62 messages is available at . 64 0.2. Noted Changes 66 0.2.1 since -01 68 Editorial changes (re-submission). 70 0.2.2 since -00 72 Editorial changes. 74 1. Introduction 76 In many cases, the [LMTP] protocol is used to transfer messages to a 77 delivery agent which might impose some limits on the usage of system 78 resources by individual recipients (e.g. disk space on a mailstore). 79 Sometimes it may be desirable for an LMTP client to inject a message 80 into the mailstore regardless of these quotas (e.g. an automated 81 process notifying users that they are over quota). 83 This memo uses the mechanism defined in [ESMTP] to define an 84 extension to the LMTP service whereby a client may ask a server to 85 ignore such quotas when delivering a message. 87 2. Framework for the Ignore Quota Extension 89 The following service extension is hereby defined: 91 (1) the name of the LMTP service extension is "Ignore Quota"; 93 (2) the LHLO keyword value associated with this extension is 94 "IGNOREQUOTA"; 96 (3) no parameters are allowed with this LHLO keyword value; 98 (4) one optional parameter using the keyword "IGNOREQUOTA" is added 99 to the RCPT TO command; 101 (5) the maximum length of a RCPT TO command line is increased by 12 102 characters by the possible addition of the IGNOREQUOTA keyword; 104 (6) no additional LMTP verbs are defined by this extension. 106 The remainder of this memo specifies how support for the extension 107 affects the behavior of an LMTP client and server. 109 3. The Ignore Quota service extension 111 When an LMTP client wishes to force delivery of a message regardless 112 of quotas, it first issues the LHLO command to the server. If the 113 LMTP server responds with code 250 to the LHLO command, and the 114 response includes the LHLO keyword IGNOREQUOTA, then the server sup� 115 ports the Ignore Quota extension and will accept the extended ver� 116 sion of the RCPT command. 118 The extended RCPT command is issued by an LMTP client when it wishes 119 to have the server ignore the recipient's quotas. The extended RCPT 120 command is identical to the RCPT command defined in [SMTP], except 121 that an IGNOREQUOTA parameter must appear after the address. 123 The complete syntax of this extended command is defined in [ESMTP], 124 with the esmtp-keyword of IGNOREQUOTA. 126 4. Usage Example 128 The following dialogue illustrates the use of the Ignore Quota ser� 129 vice extension: 131 S: 132 C: 133 S: 220 foo.oceana.com LMTP Cyrus v2.0.11 ready 134 C: LHLO oceana.com 135 S: 250-foo.oceana.com 136 S: 250-IGNOREQUOTA 137 S: 250-8BITMIME 138 S: 250-ENHANCEDSTATUSCODES 139 S: 250-AUTH DIGEST-MD5 CRAM-MD5 EXTERNAL 140 S: 250 PIPELINING 141 C: MAIL FROM: 142 S: 250 2.1.0 ok 143 C: RCPT TO: 144 S: 250 2.1.5 ok 145 C: DATA 146 S: 354 go ahead 147 ... 148 C: . 149 S: 452 4.2.2 Over quota 150 C: MAIL FROM: 151 S: 250 2.1.0 ok 152 C: RCPT TO: IGNOREQUOTA 153 S: 250 2.1.5 ok 154 C: DATA 155 S: 354 go ahead 156 ... 157 C: . 158 S: 250 2.1.5 Ok 159 C: QUIT 160 S: 221 2.0.0 bye 162 5. Security Considerations 164 The Ignore Quota extension described in this memo can conceivably be 165 used to force any or all users over their quotas and prevent further 166 messages from being delivered. For this reason, implementations 167 SHOULD try to limit the use of this extension to privileged or 168 trusted users. Possible means for doing so would be to either 169 authenticate and identify the user of the LMTP client by using the 170 mechanism defined in [SMTPAUTH] or restrict the use of the LMTP 171 client via permissions or access control lists. 173 6. IANA Considerations 175 The registration of the LMTP "IGNOREQUOTA" extension follows: 177 Service Extension: Ignore Quota 178 LHLO Keyword: IGNOREQUOTA 179 Parameters: none 180 Verb: none 181 Added Behavior: defined in this memo 183 7. References 185 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", Harvard University, RFC 2119, March 1997. 188 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 189 University, RFC 2033, October 1996. 191 [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", AT&T Lab� 192 oratories, RFC 2821, April 2001. 194 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 195 Crocker, "SMTP Service Extensions", MCI, Innosoft Interna� 196 tional, Inc., Dover Beach Consulting, Inc., Network Management 197 Associates, Inc., Brandenburg Consulting, RFC 1869, November 198 1995. 200 [SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", 201 Netscape Communications, RFC 2554, March 1999. 203 8. Author's Address 205 Kenneth Murchison 206 Oceana Matrix Ltd. 207 21 Princeton Place 208 Orchard Park, NY 14127 210 Phone: (716) 662-8973 211 EMail: ken@oceana.com 212 Lawrence E. Greenfield 213 Carnegie Mellon University 214 5000 Forbes Ave. 215 Pittsburgh, PA 15213 217 Phone: (412) 268-4646 218 EMail: leg+@andrew.cmu.edu