Network Working Group H. Santos Internet-Draft Santronics Software, Inc. Expires: August 24, 2006 February 20, 2006 SMTP Service Extension for Command HEAD draft-santos-smtphead-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SMTP HEAD command is a new SMTP service extension offering the ability for SMTP clients and servers to split the email header into two separate parts; the header and content during the transaction process. The purpose is to cleanly separate the payload of the message to extract the header information in order to perform low overhead, fast payload validation concepts prior to transmitting the entire DATA payload. Santos Expires August 24, 2006 [Page 1] Internet-Draft SMTPHEAD February 2006 This document outlines the SMTP service extension HEAD and its implementation for extended SMTP server and client operations. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SMTP State Machine . . . . . . . . . . . . . . . . . . . . . . 3 3. SMTP Service Keyword and Command . . . . . . . . . . . . . . . 4 4. SMTP Client/Server HEAD Implementation . . . . . . . . . . . . 4 4.1. SMTP Server Implementation . . . . . . . . . . . . . . . . 4 4.2. SMTP Client Implementation . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Santos Expires August 24, 2006 [Page 2] Internet-Draft SMTPHEAD February 2006 1. Introduction The main reason for a HEAD command is the increasing need to depend on PAYLOAD [RFC2822] information before making a SMTP level acceptance or rejection decision. The design goal of the HEAD command is to cleanly separate the payload of the message to extract the header information in order to perform fast PAYLOAD [RFC2822] validation concepts. With new emerging email security standard proposals already in place or pending, there will be a need to address detailed operational issues using an open-ended payload transmission concept: The HEAD command addresses: - high potential for wasted, high bandwidth and overhead, - high potential for hacker and spammer high payload attacks, - high potential for network floods and connections drops, - high potential to lower delivery reliability, - increasing potential liability issues. [TBD Address possible comment that the overhead of an open-ended transmission of the payload is negliable and thus a non-issue] 2. SMTP State Machine The standard SMTP [RFC2821]. state machine consist of the basic following command or states: EHLO or HELO MAIL FROM: RCPT TO: DATA QUIT Implementing the new HEAD command will add a new state between RCPT TO: and DATA: EHLO MAIL FROM: RCPT TO: HEAD DATA QUIT Santos Expires August 24, 2006 [Page 3] Internet-Draft SMTPHEAD February 2006 3. SMTP Service Keyword and Command HEAD is a new ESMTP keyword and command. It is a keyword as a response to EHLO command. EHLO response Format: 250-HEAD [REQ] [future options] If the HEAD keyword is present as part of the EHLO response, the HEAD command is supported by the SMTP server, and the command is OPTIONAL for the SMTP client. If the option REQ is provided, the HEAD command is supported by the SMTP server and it is REQUIRED to be used by the client. This can be considered to be part of a migration plan for future enforcement and also be local policy based depending on the client domain name or connecting IP address classification. 4. SMTP Client/Server HEAD Implementation 4.1. SMTP Server Implementation The SMTP server MAY add support for the HEAD command by first exposing HEAD service support using the HEAD keyword in the EHLO response. If the SMTP server also supports the SMTP service extension PIPELINING [RFC1854], it MUST handle HEAD support in the same matter as if it was another state in the SMTP state machine and piping flow of commands and responses. SMTP Server HEAD command response codes: 354 Start Header input; end with . 25x Header Accepted. Please Continue with DATA 554 Header not accepted: [reason] When the SMTP client issues the HEAD command, the SMTP server responds with a 354 response code to signify the start of the header block transfer. The block MUST end with a . delimiter. When the SMTP client has completed the header block transfer, the SMTP server may respond with a positive 250 code to signify the header has been accepted by the server. If the header is not acceptable, the server SHOULD respond with a 554 negative response Santos Expires August 24, 2006 [Page 4] Internet-Draft SMTPHEAD February 2006 code. 4.2. SMTP Client Implementation The SMTP client MAY use the HEAD command if the SMTP server exposed the HEAD keyword in the response to the EHLO command. If the SMTP server exposes the HEAD REQ keyword, the SMTP client MUST use the HEAD command to transfer the header. The HEAD command follows the RCPT TO: and meant to break up the DATA command into two parts: HEAD transfer of email message header. DATA transfer of email message content. The SMTP client state machine flow is based on the SMTP server HEAD command Response: 354 -> Send Header -> Wait for Server Response 25x -> DATA 554 -> QUIT or RSET During the HEAD state, the SMTP server obtains payload header (HEAD) information to perform payload acceptability. If the HEAD command is used, the client MUST transfer the entire email message header with this command and wait for for a server response. The client MUST not attempt to resend the header as part of data sent with DATA command. The server "MAY" wish to perform duplicate or resent header comparison testing. This is considered out of scope and implementation dependent. However, if such testing is performed, a permanent negative response code MUST be used when a header comparison fails. 5. Examples Santos Expires August 24, 2006 [Page 5] Internet-Draft SMTPHEAD February 2006 S: serverdomain.com, welcome ESMTP v2.0 C: EHLO mail.clientdomain.com S: 250-HEAD S: 250-HELP C: MAIL FROM: S: 250 User Ok C: RCPT TO: S: 250 User Ok C: HEAD S: 354 Start Header input; end with . [header block] . S: 250 Header Accepted. Please Continue with DATA C: DATA S: 354 Start Body input; end with . [message body] . S: 250 Message Accepted for Delivery C: Quit S: 250 Goodbye 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD 8. Acknowledgements The following individuals contributed input and guidance in the production of this proposal and document: William Elan Scott Kitterman Santos Expires August 24, 2006 [Page 6] Internet-Draft SMTPHEAD February 2006 9. Normative References [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, July 1994. [RFC1854] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Santos Expires August 24, 2006 [Page 7] Internet-Draft SMTPHEAD February 2006 Author's Address Hector Santos Santronics Software, Inc. 15600 SW 158 ST Suite #306 Homestead, Florida, FL 33033 United States of America Email: hsantos@isdg.net URI: http://www.isdg.net Santos Expires August 24, 2006 [Page 8] Internet-Draft SMTPHEAD February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Santos Expires August 24, 2006 [Page 9]