Re: [Shutup] [ietf-smtp] Compressing SMTP streams

"John Levine" <johnl@taugh.com> Fri, 29 January 2016 18:07 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C11A8AFB for <shutup@ietfa.amsl.com>; Fri, 29 Jan 2016 10:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.264
X-Spam-Level: **
X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_27=0.6, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n6T5P8jx7De for <shutup@ietfa.amsl.com>; Fri, 29 Jan 2016 10:07:37 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E951A906A for <shutup@ietf.org>; Fri, 29 Jan 2016 10:07:36 -0800 (PST)
Received: (qmail 94779 invoked from network); 29 Jan 2016 18:07:35 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Jan 2016 18:07:35 -0000
Date: 29 Jan 2016 18:07:13 -0000
Message-ID: <20160129180713.51570.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: ietf-smtp@ietf.org, shutup@ietf.org
In-Reply-To: <56AB9AE4.7020503@alameth.org>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/LupwUHsgCIGg6Va5qgvrodmjubE>
Cc: csg@alameth.org
Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 18:07:38 -0000

>Compression has been removed completely from TLS v1.3, the outcome of 
>the room consensus at IETF-89.

Bummer.

Well, in that case, here's a straw man proposal.

The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
followed by a space-separated list of compression schemes, currently
consisting only of DEFLATE (RFC 1951.)

There's one new command, COMPRESS which takes as an argument the type
of compression to be used.  If you want to do both STARTTLS and
COMPRESS, the results of doing COMPRESS before STARTTLS are
aggessively undefined.

The responses to COMPRESS are:

500 compress not supported
501 compression scheme unknown
220 go ahead

After a 220 response, subsequent traffic is compressed.  It's up to
each end to ensure that there's a compression block boundary every
time the transmission direction changes, i.e., after each command or
response, or if pipelining after each pipelined group.  If the
compress command fails, the client can at its option continue an
uncompressed session or give up.

Example

S: 220 mx.example smail2 ESMTP

C: EHLO client.example

S: 250-mx.example
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE

C: STARTTLS

S: 220 go ahead

<TLS negotiation>

C: EHLO client.example

S: 250-mx.example
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE

C: COMPRESS DEFLATE
S: 220 go ahead

<subsequent traffic is compressed>
 ... blah blah ...

C: QUIT

S: 221 sayonara

R's,
John