Compressed Data Extension for SMTP
draft-levine-smtp-compress-00

Abstract

SMTP messages can be quite large. This extension specifies a method to transfer SMTP messages in a compressed form.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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 Internet-Draft will expire on August 14, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Open issues
• 2. Introduction
• 3. Definitions
• 4. Compressed data service extension
• 5. SMTP reply codes
• 6. Use of compressed data
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Inforormative References
• Author's Address

1. Open issues

[[ Please remove this before publication, although if there's anything left here, it's probably not ready to publish ]]

• Is it worth making provision for multiple compression schemes? After 20 years, there still isn't anything much better than DEFLATE and zlib.
• If a server supports both COMPRESS and CHUNKING [RFC3030], can you mix compressed and uncompressed chunks of data? I don't see why not, but ugh.
• Do we need new 5xx codes for bad compressed data, or can we use 554 for bad data and 552 for too big?

2. Introduction

SMTP messages can be quite large, particuarly when they include MIME parts representing documents or images. Since CPU performance has historically increased faster than network speed, sending data in compressed form is likely to be faster than in uncompressed form, even allowing for compression and decompression at each end. For binary material sent in base64 form, compression will likely reduce the size of the material to the size of the original material, or perhaps less if the original material was compressible. If an SMTP session transfers several similar messages, the compressed form of the second and subsequent messages will likely be smaller as wll.

This specification uses the zlib [RFC1950] compression scheme, which is widely available and is known to work well on textual material.

3. Definitions

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 [RFC2119].

Syntax descriptions use Augmented BNF (ABNF)[RFC5234].

The ABNF "SP" and "CRLF" are used as in [RFC5321].

4. Compressed data service extension

The name of the SMTP service extension is Compressed data. Its EHLO keyword is "COMPRESS".

 ABNF:

cdat-cmd   ::= "CDAT" SP chunk-size
         [ SP reset-marker ] [ SP end-marker ] CRLF
chunk-size ::= 1*DIGIT
reset-marker ::= "RESET"
end-marker ::= "LAST"

A new SMTP verb, CDAT, specifies transfer of compressed data. It takes one mandatory argument, the chunk size which is the number of octets of compressed data that follows. The optional reset-marker specifies that the compression engine's context was reset, as described further below. The optional end-marker specifies that this chunk is the last chunk of the message. The compressed data is sent immediately after the CRLF.

5. SMTP reply codes

The SMTP server replies 250 to a successful CDAT command. It replies 503 to a CDAT command that attempts to send data after a CDAT command with the end-marker. It replies with an appropriate 5xx code if a chunk of data could not be accepted, due to failed decompression or other reasons. It replies with code 503 to any attempts to send more chunks after a rejected chunk.

6. Use of compressed data

Each chunk MUST contain one or more complete byte-aligned blocks of compressed data. A block of compressed data MUST NOT be split between two chunks.

Normally, all of the chunks of compressed data in an SMTP session are treated as a single stream of data through the compression and decompression engines, with the engines' internal state preserved from one chunk to the next, including chunks in different mail messages. This means that the RESET (RSET) SMTP command MUST NOT reset the compression state. The reset-marker on a chunk means that the engine was reset to its initial state before compressing the chunk, so the decompressor has to restart from the initial state as well.

In most cases the best compression results will be obtained by not using reset-markers, but there may be situations where a sending host is operationally unable to maintain the compression context between messages. The compression state after a chunk of data is rejected by an SMTP-receiver is undefined, so a subsequent message in the same sesion MUST have the reset-marker.

7. IANA Considerations

IANA is requested to add this entry to the "SMTP Service Extensions" registry.