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 © 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.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  SMTP State Machine
3.  SMTP Service Keyword and Command
4.  SMTP Client/Server HEAD Implementation
    4.1.  SMTP Server Implementation
    4.2.  SMTP Client Implementation
5.  Examples
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgements
9.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Introduction

The main reason for a HEAD command is the increasing need to depend on PAYLOAD (Resnick, P., “Internet Message Format,” April 2001.) [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 (Resnick, P., “Internet Message Format,” April 2001.) [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] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.). 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

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 (Freed, N., “SMTP Service Extension for Command Pipelining,” October 1995.) [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 <CRLF>.<CRLF>
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 <CRLF>.<CRLF> 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 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

         S: serverdomain.com, welcome ESMTP v2.0
         C: EHLO mail.clientdomain.com
         S: 250-HEAD
         S: 250-HELP
         C: MAIL FROM:<jqpublic@emaildomain.com>
         S: 250 User Ok
         C: RCPT TO:<localuser@serverdomain.com>
         S: 250 User Ok
         C: HEAD
         S: 354 Start Header input; end with <CRLF>.<CRLF>
            [header block]
            .
         S: 250 Header Accepted. Please Continue with DATA
         C: DATA
         S: 354 Start Body input; end with <CRLF>.<CRLF>
            [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

9. Normative References

Author's Address

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 © 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.