INTERNET DRAFT Advanced Integrators, LC B. Gingery Category: Internet Draft November 2001 Expires: 20 June 2002 ESMTP Service Extension for Filtering Gateways draft-bgingery-esmtp-adat-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This document requests consideration for adoption as an extension to internet standards after an appropriate com- ment period, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Dis- tribution of this memo is unlimited. Comments may be addressed to the author, who also requests copies of discussions about this proposed exten- sion, including access to IETF/IESG workgroup discussions of this extension. and may be referred to as draft-bgingery-esmtp- adat-00.txt Abstract This document describes a needed extenson to the STD-10 SMTP (Simple Mail Transport Protocol) service so that an ESMTP server and client mqy delay specific recipient acceptance until after content can be examined by the filtering gateway. It adds one return code (355) and three verbs (ADAT, DRCP and ERCP) to the ESMTP protocol as defined in RFC2821. It affects state processing of ESMTP negotiations. It diverges from some MUST NOT activities required by RFC2821, to recognize an addition- ally needed functionality which is being widely performed in defiance of existing standards. As such, it helps restore needed hardiness to the world wide SMTP delivery systems. It overloads the 454 return code as well as adding a 355 (send recipients). Table of Contents 1. Introduction 1.1 Terminology 1.2 Applicability 2. Added Verbs and Return Codes 2.1 ADAT and 355 code 2.2 . end-of-data 2.3 DRCP 2.4 ERCP 2.5 RSET before ERCP 2.6 454 code 2.7 Recap of ADAT based verbs 3. Typical sessions 3.1 Successful Single Recipient 3.2 Unsuccessful Single Recipient 3.3 Protectively Filtered - Site Prohibited 3.4 Content-Filtered for Specified Recipients 4. Send/Response map 5. Domain indication of ADAT support 6. Source Route Filters and other Filters 7. Manditory Discliamers 8. Security Considerations 9. Author Contact A. References 1. Introduction STD-10 ESMTP [See also RFC-2821] servers and clients have a variant conversation within their handling of messages. While these are strictly defined within a given session, there are widely varying support for both basic and extended protocols and facilities. Current requirements for filtering for individual sites and even recipients reduces the benefits of pre-qualifying recipients before passing the payload data for any given message. Prior to implementation of this service extension, the only poten- tials for content-based rejection of multi-recipient deliveries includes breaking of some tracking and debug- ging provisions of previous standards and extensions. SEND, SAML and SOML recipient specifications are falling out of favor, (See Section F.6 of RFC2821) so this pro- vides an alternative traditional MAIL/RCPT transactions, and makes no pretense of integrating with the active delivery methods which are now deprecated, and largely replaced by Instant Messaging protocols. Some gateways may wish to accept this subset into instant messaging client-server conversations, as an Instant-Message to E- Mail (or E-Mail to Instant Message) filtering gateway. Such functions are outside the definition of this docu- ment, but it is strongly recommended that such addresses be managed by addressee address rather than by protocol extension. Currently RFC2821 (April 2001) which is on a standards track to replace RFC-821 as STD-10, section 4.4 forbids relay servers from inspecting content. However, this is routinely done in spam and virus filtering services, to the confusion of the overall SMTP based world-wide mail processing network. Because recipients are routinely qualified by the receiving server BEFORE content is checked, several adaptations are becoming common: 1. Ignore status indications, returning an acceptance even for messages which will be discarded according to delivery rules, as a site policy. 2. Report delivery status via secondary status E- Mails, using the <> null administrative return address. This results in a sometimes abused facility when envelope sender addresses are forged. 3. Recipients are already provisionally pre-approved, then the entire delivery fails, even if local rules on the receiving end would allow delivery to SOME recipi- ents. 4. Recipients are already provisionally pre-approved. Then, after transfer of content, it is discovered that local delivery is prohibited by local recipient rules for some recipients. This lack of delivery is then ignored (as in case 1 above) or reported using the abusable null return address. 1.1 Terminology The key words "MUST", "MUST NOT", REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be inter- preted as described in RFC-2991. 1.2 Applicability This extension has potential use both for clients and servers operating in MCA (Mail Client Agent requesting injection), MSA (Mail Submission Agent - receiving injec- tions), and MTA (Mail Transport Agent - accepting for transport and disposition) roles. Use of the ADAT/DRCP/ERCP protocol extension by a client indicates that it assumes responsibility for notifying its clients (if any) of the delayed disposition of mes- sages. Advertisement of the ADAT protocol extension by servers indicates that they accept responsibility for any forwarding (relaying) and conversion required for passing messages to subsequent services, whether they are ESMTP or not, and whether or not they accept this ADAT exten- sion. In addition, dsn (Delivery Status Notification) enhancements to the basic protocols become relevant in any software which acts as a filter, even where confusion has prevented its use in previous implementations. Servers implementing this extension SHOULD also implement dsn [RFC1891]. The ESMTP with ADAT processing design allows for exten- sions to the basic SMTP model: +----------+ +------+ | | | User |<-->| | +------+ | Client- |<---------+ Commands/Replies +------+ | SMTP | | SMTP, ESMTP | File |<-->| | | or ESMTP/ADAT |System| | | v +------+ +----------+ +----------+ Local | Filtering| +-----------+ +----------+ | Gateway |<--->| File | | Recipient| | | | System | | Gateway | | | +-----------+ | or |<----| | +-----------+ | Mailbox | | |<--->| Other | | Server | | | | Mail | +----------+ | | | System | +----------+ +-----------+ The filtering gateway may act as an SMTP/ESMTP client with the Recipient Gateway, or have combined functional- ity to translate to other (non-SMTP/non-ESMTP) mail sys- tems, or even have local delivery agents to a local filesystem. 2. Added Verbs and Return Codes Three verbs, and two return codes provide precise back- ward compatibility through non-interference, while also looking forward to better delivery status reporting. AADDAATT functionally replaces the normal DDAATTAA verb, hence must not be pipelined. DDRRCCPP functionally replaces the RRCCPPTT To: verb, and EERRCCPP provides a needed end-of-recipi- ents indication. 355 (data received, send recipients) and 454 (undeliverable but not my failure) add to the existing ESMTP standards. 2.1 ADAT The ADAT verb MAY be advertised in ESMTP command exten- sion advertisements only after this definition had received a period of public comment. In initial testing, it MUST utilize the X- prefix, as defined in RFC2821. Throughout the rest of this document read X-ADAT whereever ADAT is used. The ADAT verb when sent by client to server MAY include an intended number of recip- ients. If the server is not prepared to accept that many recipients it SHOULD return a 452 Too many recipients. The 250-ADAT verb advertisement indicates that the receiving server is willing to delay recipient processing until after content is received. Use of the ADAT verb by the connected client indicates that the recipient(s) for an upcoming message content will be delayed until after the receiving server has had an opportunity to receive the data. In all other respects, the ADAT verb is iden- tical to the traditional DATA verb [RFC2821 S 4.1.1.4]. The optional count parameter for ADAT may be omitted by the client, and is advisory-only. The server MAY return a 553 or 453 with comparable d.s.n to indicate that it will not accept data destined in one batch for that num- ber of recipients. A client MUST NOT send the ADAT verb to a server in a basic SMTP connection which was initiated with a HELO instead of EHLO. A client MUST NOT send the ADAT verb to a server which has not advertised the capability and acceptance in its 250- commandlist advertisment response to the EHLO. A client MUST NOT send the ADAT verb before a normal MAIL verb has been accepted. A server which advertises for ADAT MUST return a 503 Com- mand Sequence error for any of the following conditions: * ADAT before EHLO * ADAT before MAIL for this transaction * ADAT after RCPT unless RCPT was part of previous transaction * ADAT after DRCP unless ERCP ended that transaction. When a 553 (or 453) with x.5.3 d.s.n is returned, the client MAY respecify with a subset of the intended recip- ients, or MAY respecify omitting the recipient count advisory. In the case of a 453 4.5.3, the client may decide to put off sending the batch, as it will not know whether or not that number of recipients may be accepted at another less busy time. 2.2 . end-of-data As in DATA verb based transfers, the server MAY flag integrity errors, which the client MUST accept as an indication of a failure of the transfer. Server MAY indicate a 554 5.7.7 Message Integrity Failure or server failure message at end-of-data. Client MUST accept such indicators on a by recipient basis, as well as at this point, and SHOULD issue an RSET if a 554 5.7.7 Integrity Failure is received at end-of-data. Server MAY NOT return a 453 4.5.3 nor 5xx 5.5.3 at end- of-data. The x.6.x dsn codes have the same meaning following an ADAT body transfer as they would following a DATA body transfer. 2.3 DRCP The DRCP (Delayed Recipient) verb functions in post-data (ADAT) message negotiations in an identical function to the RCPT TO functions in the traditional (DATA based) message negotiations. It takes the same DSN optional parameters, and may respond with the same error rejec- tions. In places where DRCP are used in this document read X-DRCP if X-ADAT was used in the session, unless otherwise stated. Clients using X-ADAT MUST use X-DRCP for specifying recipients for the message. Clients using ADAT MUST use DRCP for specifying recipients. Servers MAY accept ERCP and X-ERCP interchangably, and during an iterem conver- sion period, advertise both ADAT and X-ADAT. Clients MUST NOT send DRCP before ADAT has been accepted with a 354 return, the actual message has been sent, and the . end-of-data has been accepted with a 355 2.7.0 Provisionally Accepted message. Once the 250 is returned for a DRCP Server MUST either accept responsability for delivery of accepted recipi- ents, or cancel all of them at the ERCP with a 4xx or 5xx return. After any recipient the server may return a 453 (with dsn 4.5.3) Too Many Recipients response, even if it has ignored a pre-ADAT advisory. Client SHOULD requeue recipints for which a 453 is returned. The server MAY also return a 550 (with dsn 5.5.3). Client SHOULD NOT requeue such recipients, and submission agents may choose to RSET the entire batch and return the appropriate error to the sender. When data is converted for a given recipient, that d.s.n SHOULD be used with the 250 acceptance code. 2.4 ERCP The ERCP (End of Recipients) verb functions in post-data (ADAT) message negotiations in much the same way that the . is used in prequalified recipient pro- cessing. In compliance with RFC2821, only the X-ERCP may be used until the experimental period for this protocol extension is completed. Clients sending X-ADAT MUST use X-ERCP. Clients sending ADAT MUST send ERCP. Servers MAY accept ERCP and X-ERCP interchangeably. Server MAY return a successful recipient count in the 250 response. This is recommended, but the tracking of recip- ients to whom it is accepted and those for whom the mes- sage is rejected is the responsibility of the client choosing to utilize this protocol, and MUST be done dur- ing the DRCP negotiation phase. The recipient count reported by the server is the number of DRCP specifica- tions accepted, and is MUST NOT be decresed because of locally-discarded-by-rule and MUST NOT be increased for alias nor list expansions. The client MAY return administrative notifications for mismatches between the accepted DRCP count and the ERCP count (if any) which it receives. The client SHOULD send the number of successful DRCP recipients it is logging as a parameter to the ERCP command. Client MUST NOT interpret a 250 return to the ERCP to be anything other than an acknowledgement of the end of recipients. Server MUST NOT return recipient-dependent status that applies only to some DRCP specified recipi- ents in response to the ERCP. Server MUST NOT return a 452 response to the ERCP, and SHOULD only return a 421 in case of catastrophic failure. The server MUST return a 451 even when variations in fil- ter processing causes an out-of-storage condition. Once ADAT and DRCP are accepted, the server has accepted the message for that delivery, unless the entire batch is rejected. 2.5 RSET before ERCP A RSET before ERCP resets the connection to the pre-EHLO or post-EHLO state. This is ambiguous in other docu- ments, so remains ambiguous here as well. A client send- ing a RSET before ERCP MUST presume that the message related to that ERCP has not been sent to any recipients and a server receiving an RSET before ERCP MUST NOT deliver the message to any DRCP specified recipients except as follows: The server MAY perform administrative or debugging activities including delivery of the message for oversight purposes (e.g. Postmaster Copy function) even if that recipient was a listed DRCP recipient. In that case the server SHOULD flag the message as specially delivered, to avoid confusion. Because ADAT processing produces a significantly higher server load for busy servers, at least potentially, the client MUST be prepared to accept unexpected 421 returns, but also refusal of connections or refusal of services, if it does significant probing of services by sending ADAT based E-Mails followed by RSET or repeated ADAT based E-Mails where there are NO acceptible DRCP recipi- ents. 2.6 The 454 "Not my fault" temporary failure code Consistently, SMTP has been defined as seen by a human client imitating a submission clientware program. Clas- sically, there have been only three temporary error codes, which despite extended DSN encodings still are often misinterpreted by software. 450 - is interpreted as Mailbox Busy 451 - is interpreted as a server error in processing 452 - is interpreted as a temporary space problem on the server But another situation exists which is beyond the control of the server and potentially the client, but which may be expected to be corrected without hands-on correction at either client or server. To follow standard posi- tional encoding, this should be 454 as a non- specific transient error which may be further defined with a d.s.n extended encoding. Examples: 454 4.4.3 Reverse lookup service unreachable 454 4.1.8 Cannot validate senders domain 454 4.1.4 Found both SRV and MX record for sender 454 4.4.2 Forward lookup on relay-to host failed 454 4.4.4 Unable to route to relay-to host But this 454 code is for conditions beyond the control of the service giving the response, not local failure. For example: 450 4.4.0 Pass-thru destination unreachable 450 4.4.1 Destination host not answering 451 4.7.0 Manditory filtering facility unavailable 450 4.4.5 Delivery services congestion 452 4.5.3 Too many recipients for single delivery. 550 5.5.3 Exceeds site policy for single message recipient count. Thus, the 454 indicates a temporary condition that is not truly a server failure, but a failure of the supporting infrastructure. Until this code is adopted into the basic ESMTP protocol, it MAY be returned in response to end-of-data . end of data to DRCP and MUST NOT be returned in response to ERCP. 2.7 Recap of ADAT based verbs AADDAATT (or X-ADAT) may have zero-to-one parameters. That one parameter (if present) is an ASCII string represent- ing an integer count advisory of the number of intended recipients. DDRRCCPP TTOO:: with the RCPT TO: defined in RFC2821. Any server performing this ADAT protocol exten- sion MUST accept the same extensions to a DRCP which it would accept in the equivalent RCPT verb. EERRCCPP (or X-ERCP) may have zero-to-one parameters. That one parameter (if present) is an ASCII string represent- ing an integer count of the number of DRCP recipients that the client believes has been accepted by the server. If the count is provided and the server's count of accepted recipients does not match that number, the server MUST return a 554 response, usually with a 5.5.0 (or optionally 5.5.3) extended status code. This return indicates aborted delivery to all recipients. 3. Typical sessions The following are given as typical and atypical session illustrations: 3.1 Successful Single Recipient R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: EHLO client.example.com R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya R: 250-250-ENHANCEDSTATUSCODES R: 250-EXPN R: 250-VERB R: 250-8BITMIME R: 250-SIZE R: 250-DSN R: 250-ONEX R: 250-XUSR R: 250-X-ADAT R: 250 HELP S: MAIL FROM: R: 250 2.1.0 ... Sender ok S: X-ADAT R: 354 Enter mail, end with "." on a line by itself S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: From: Louis User S: To: Joe Recip S: Subject: Example Message S: S: This is a sample advanced-data transmission message. S: . R: 355 2.7.0 Provisionally Accepted. Specify Recipients. S: X-DRCP TO: R: 250 2.0.0 fAINFLR00446 Message accepted for delivery S: X-ERCP R: 250 2.2.0 Successfully accepted for delivery to 1 recipient(s). S: QUIT R: 221 2.0.0 mail.example.com closing connection 3.2 Unsuccessful Single Recipient R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: EHLO client.example.com R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya R: 250-250-ENHANCEDSTATUSCODES R: 250-EXPN R: 250-VERB R: 250-8BITMIME R: 250-SIZE R: 250-DSN R: 250-ONEX R: 250-XUSR R: 250-X-ADAT R: 250 HELP S: MAIL FROM: R: 250 2.1.0 ... Sender ok S: X-ADAT 1 R: 354 Enter mail, end with "." on a line by itself S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: From: Louis User S: To: Joe Recip S: Subject: Example Message Rejection S: MIME-Version: 1.0 S: Content-Type: multipart/mixed; BOUNDARY="0-231256789123AB=#993" S: S: --0-231256789123AB=#993 S: Content-Type: TEXT/plain; CHARSET=US-ASCII S: S: This is a sample advanced-data transmission message with S: prohibited content. S: S: --0-231256789123AB=#993-- S: . R: 355 2.7.0 Provisionally Accepted. Specify Recipients. S: X-DRCP TO: R: 554 5.7.1 delivery rejected by filter S: X-ERCP R: 250 2.2.0 Successfully accepted for delivery to 0 recipient(s). S: QUIT R: 221 2.0.0 mail.example.com closing connection 3.3 Protectively Filtered - Site Prohibited R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: EHLO client.example.com R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya R: 250-250-ENHANCEDSTATUSCODES R: 250-EXPN R: 250-VERB R: 250-8BITMIME R: 250-SIZE R: 250-DSN R: 250-ONEX R: 250-XUSR R: 250-X-ADAT R: 250 HELP S: MAIL FROM: R: 250 2.1.0 ... Sender ok S: X-ADAT 1 R: 354 Enter mail, end with "." on a line by itself S: From: Louis User S: Subject: Example Message Rejection S: X-MSMail-Priority: Normal S: X-Priority: 3 S: X-Mailer: Microsoft Outlook Express 5.00.2919.6600 S: MIME-Version: 1.0 S: Content-Type: multipart/mixed; S: boundary="----=_NextPart_000_00B7_010B9FBF.A7AFBF00" S: Content-Transfer-Encoding: 7bit S: Message-Id: <20010919045807.809B7280E6@lethal.example.com> S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: To: undisclosed-recipients:; S: S: This is a multi-part message in MIME format. S: S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00 S: Content-Type: text/plain; charset=ISO-8859-1 S: Content-Transfer-Encoding: 7bit S: S: The amount indicated in the invoice as per instructions contained S: therein. Good will be forwarded immediately upon receipt of payment. S: We thank you for your interest in our products and take this S: opportunity to send our best regards. S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00 S: Content-Type: application/octet-stream; name="CFGWIZ32.EXE" S: Content-Transfer-Encoding: base64 S: Content-Disposition: attachment; filename="CFGWIZ32.EXE" S: S: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQA ... S: B0AGEAcgB0ACAAeQBvAHUAcgAgAHMAeQBzAHQAZQBtACAAYgBlAGYAbwA= S: S: S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00-- S: . R: 554 5.7.1 Prohibited content detected. Do not re-attempt delivery! S: QUIT R: 221 2.0.0 mail.example.com closing connection 3.4 Content-Filtered for Specified Recipients R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST) S: EHLO client.example.com R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya R: 250-250-ENHANCEDSTATUSCODES R: 250-EXPN R: 250-VERB R: 250-8BITMIME R: 250-SIZE R: 250-DSN R: 250-ONEX R: 250-XUSR R: 250-X-ADAT R: 250 HELP S: MAIL FROM: R: 250 2.1.0 ... Sender ok S: X-ADAT 1 R: 354 Enter mail, end with "." on a line by itself S: From: Louis User S: Subject: Example Message Rejection S: X-Priority: 1 S: MIME-Version: 1.0 S: Content-Type: text/html S: Content-Transfer-Encoding: 7bit S: Message-Id: <200104290024359.SM00856@spamdomain.example.com> S: S: S: S: S: S: S: S: SERVICIO DE ENVIO DE EMAIL Le ofrecemos realizar nosotros S: el envio de lo que quiera promocionar S: S: S: S: S: ... S: S: . R: 355 2.7.0 Provisionally Accepted. Specify Recipients. S: X-DRCP TO: R: 554 5.7.1 delivery rejected by filter S: X-DRCP TO: R: 250 2.0.0 ... Ok S: X-ERCP R: 250 2.2.0 Successfully accepted for delivery to 1 recipient(s). S: QUIT R: 221 2.0.0 mail.example.com closing connection 4. Send/Response map This section is intended as a reference extending section 4.3.2 of RFC2821. CONNECTION ESTABLISHMENT S: 220 F: 421 E: 554 EHLO or HELO S: 250 E: 504, 550 MAIL S: 250 E: 552, 451, 452, 550, 553, 503 ADAT S: 354 -> data -> S: 355 F: 552, 554, 421, 451, 452, 454 E: 502, 552, 421, 451, 452, 454, 550, 553, 503 DRCP TO: S: 250, 251 F: 550, 551, 552, 553, 450, 451, 452 E: 500, 501, 503, 504, 554, 421, 454 ERCP S: 250 F: 500, 501, 554, 421 5. Domain indication of ADAT support Documents and standards specifying Domain Name Service MX records, and those specifying SRV (Service Provider) sup- port in the Domain Name Service leave a gap for implemen- tation of "non-standard" ports for additional service provisions. Any RFC2821 compliant ESMTP server running on the default MX port (25) or the "submission" service port (587) MAY advertise ADAT support in its EHLO 250 response group. In addition a domain may advertise which servers support ADAT by appending the ADAT verb to the service name, with a dash (ASCII "-") in a SRV record, such as "esmtp-adat" for public delivery, or "submission- adat". "Submission" ports on advertised addresses may be expected to require STARTTLS with client certification, or SMTP-AUTH [RFC2554] or similar extensions. Clients intending to use ADAT with authorization MUST authorize (and/or STARTTLS) before issuing any MAIL verbs which will be used with an ADAT directive. The entire transac- tion then procedes under that authorization (and likely encrypted tunnel). Filtering gateways which communicate with delivery services via SMTP would normally safeguard that with the STARTTLS [RFC2487] extension, as well. 6. Source Route Filters and other Filters A client accepting the invitaiton to use the ADAT/DRCP/ERCP protocol accepts other restrictions upon delivery imposed by the gateway filter. There may be no information as to what other mailsystem the filter is a gateway to. The output of the gateway may also be (for example) STARTTLS based ESMTP to destination delivery hosts. RFC2821 extends RFC1123 source routing specification to indicate that a server MAY ignore the routes. ADAT servers should be presumed to ignore the routes. RFC2821 lists #-literals (section F.4) as deprecated. DRCP verb processors MUST reject all addressees specified by an integer host number, just as RFC2821 specifies rejection. 7. Manditory Disclaimers The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Infor- mation on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full license is granted to The Internet Society as if this document were created as a work for hire for the ISOC, except that such grant shall not deminish the right of the original author to publish and distribute the work. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, pro- vided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or refer- ences to the Internet Society or other Internet organiza- tions, except as needed for the purpose of developing Internet standards in which case the procedures for copy- rights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions to and through The Internet Soci- ety granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns, nor by the author. This document and the information contained herein is provided on an "AS IS" basis and the author and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 8. Security Considerations Security issues are not fully discussed in this memo. Mention of elevated security uses of the [E]SMTP protocol is for consideration of interoperability. It is the belief of the author that use as defined above in the initial draft will have no security significant consider- ations which are not already present in ESMTP negotia- tions which do not utilize the ADAT/DRCP/ERCP extension, but "delay checks" until end-of-data. 9. Author Contact Comments may be addressed to A. References STD0060/RFC2920 SMTP Service Extension for Command Pipelining STD0010/RFC0821 Simple Mail Transfer Protocol RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages RFC2852 Deliver By SMTP Service Extension RFC2821 Simple Mail Transfer Protocol RFC2645 On-Demand Mail Relay (ODMR) SMTP Wth Dynamic IP RFC2554 SMTP Service Extension for Authentication BCP0030 Anti-Spam Recommendations for SMTP MTAs RFC2487 SMTP Service Extension for Secure SMTP over TLS RFC2476 Message Submission RFC2442 The Batch SMTP Media Type RFC2197 SMTP Service Extension for Command Pipelining RFC2034 SMTP Service Extension for Returning Enhanced Error Codes RFC2033 Local Mail Transfer Protocol RFC1893 Enhanced Mail System Status Codes RFC1891 SMTP Service Extension for Delivery Status Notifications STD0010/RFC1870 SMTP Service Extension for Message Size Declaration STD0010/RFC1869 SMTP Service Extensions RFC1854 SMTP Service Extension for Command Pipelining RFC1846 SMTP 521 Reply Code RFC1845 SMTP Service Extension for Checkpoint/Restart RFC1652 SMTP Service Extension for 8bit-MIMEtransport RFC1405 Mapping between X.400(1984/1988) and Mail-11