Network Working GroupH. Santos
Internet-DraftSantronics Software, Inc.
Expires: August 24, 2006February 20, 2006

SMTP Service Extension for Command HEAD


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

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on August 24, 2006.

Copyright Notice

Copyright © The Internet Society (2006).


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:


Implementing the new HEAD command will add a new state between RCPT TO: and DATA:



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:, welcome ESMTP v2.0
         C: EHLO
         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 <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



8. Acknowledgements

The following individuals contributed input and guidance in the production of this proposal and document:

William Elan
Scott Kitterman


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 (TXT, HTML, XML).
[RFC2821] Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001.
[RFC2822] Resnick, P., “Internet Message Format,” RFC 2822, April 2001.


Author's Address

  Hector Santos
  Santronics Software, Inc.
  15600 SW 158 ST Suite #306
  Homestead, Florida, FL 33033
  United States of America


Intellectual Property Statement

Disclaimer of Validity

Copyright Statement